范围裁剪
何时使用此技能
当你需要：
- •定义 MVP 范围
- •裁剪项目功能
- •控制范围蔓延
- •在有限时间内交付价值
核心原则
1. 时间预算优先
先设定愿意投入的最大时间，再设计符合预算的方案版本。
2. MVP 是验证工具
MVP 是测试假设的最小版本，而非低质量的产品。
3. 可爱优于可行
追求"最小可爱产品"而非仅仅"最小可行产品"。
专家洞察
Ryan Singer
"我们反其道而行之，问的是：在真正完成某件事之前，我们愿意花费的最长时间是多少？我们如何提出一个能在业务愿意投入的时间内完成的想法？"
核心洞察：不要估算功能需要多长时间，而是设定固定的时间预算（appetite），然后设计一个符合预算的解决方案版本。
如何应用：
- •为任何项目设定最大时间限制（如六周）以保持可见性和控制
- •调整解决方案的范围而非截止日期来确保交付
Eric Ries
"MVP 简单来说就是，对于我们试图测试的任何假设，获得验证所需的最有效方式是什么？"
核心洞察：MVP 是针对特定假设的验证工具，而非只是产品的低质量版本。
如何应用：
- •首先识别核心假设
- •确定获得验证的最有效方式
- •控制犯错的风险
Jason Fried
"我们用的是 appetite（意愿预算）。我们对任何单个功能的 appetite 最多是六周。本质上这就是我们愿意花的预算。我只愿意在任何功能上花六周。所以我们必须找出最简单、最有效的版本来在这个时间内完成..."
核心洞察：使用固定的时间预算（appetite）而非估算，迫使团队找到功能最简单、最有效的版本。
如何应用：
- •为任何功能开发设定六周的硬性上限
- •把时间当作要花的预算而非要估算的截止日期
- •限制团队规模为两人（一名设计师，一名程序员）以保持专注
Anton Osika
"我喜欢用的很多术语是强调我们应该追求的是构建一个最小可爱产品，然后构建可爱产品，再构建绝对可爱产品。所以我把这个术语带到了公司名称里。"
核心洞察：将焦点从"最小可行产品"转移到"最小可爱产品"，确保初始版本能在情感上与用户产生共鸣。
如何应用：
- •在早期版本中追求"可爱性"而非仅仅"可行性"
- •从最小可爱迭代到绝对可爱
Crystal W
"这真的是一种绿野仙踪体验。我们不需要构建任何东西。我和一群实习生协调，我们能够验证订阅服务中预期的一些价值主张和转化率。"
核心洞察：使用手动的"绿野仙踪"测试来在投入工程资源前验证产品价值主张。
如何应用：
- •使用 WhatsApp 群组手动模拟自动化功能
- •使用简单的应用内消息覆盖在现有屏幕上测试引导流程
- •使用 Typeform 进行快速功能验证如性格测试
常见错误
- •先有解决方案再找问题
- •用估算而非预算来规划时间
- •MVP 只追求"能用"而忽视"可爱"
- •在验证价值前就投入大量工程资源
关键战术
| 战术 | 说明 |
|---|---|
| 六周预算 | 任何功能最多六周，强制精简 |
| 绿野仙踪测试 | 人工模拟功能来快速验证 |
| 假设优先 | 先明确要验证的假设再定义 MVP |
| 范围弹性 | 固定时间，调整范围 |
相关技能
- •[[01-北极星指标-north-star-metrics|北极星指标]]
- •[[02-产品愿景-product-vision|产品愿景]]
- •[[03-路线图优先级-roadmap-prioritization|路线图优先级]]
- •[[04-OKR目标设定-okrs-goals|OKR目标设定]]