mvp-scoping

MVP 范围界定

适用场景

当创始人或 PM 有一个想法或完整的功能规格，并需要将其提炼为值得构建的最小版本时，启用此流程。触发语句包括“我们的 MVP 是什么”“我们应该砍掉什么”“把范围缩小”“我们先构建什么”“我们只有 4 周”或“帮我确定要包含哪些内容的优先级”。当团队正受到范围蔓延困扰，需要明确划分必备项与锦上添花项时，也启用此流程。

所需上下文

• 来自 startup-context： 公司阶段、团队规模、资金储备／时间压力、现有产品（如有）、技术栈和限制。
• 来自用户： 完整的功能愿景或规格、目标用户群、待验证的核心假设、可用时间和资源，以及任何不可妥协的要求（合规、安全、合同承诺）。

工作流

1. 陈述假设 — 明确 MVP 旨在了解或证明什么。格式：“我们相信，如果提供[能力]，[用户群]就会[行为]；当[可衡量信号]出现时，我们就知道这个判断是正确的。”
2. 列出所有候选功能 — 枚举完整愿景中的每项功能、能力和要求。
3. 应用 MoSCoW 优先级排序法 — 将每项内容归类为必备、应该有、可以有或暂不考虑。
4. 识别风险 — 针对每项必备内容，识别技术、市场和执行风险。标记风险较高、可能需要先进行技术验证或制作原型的必备项。
5. 划定范围边界 — 明确划定界限。界限以上的内容全部纳入 v1 发布；界限以下的内容则明确说明何时构建。
6. 估算并验证 — 粗略估算必备项的工作量。如果其工作量超出可用时间 20% 以上，则对必备项强制排序，并将优先级最低的项降级。
7. 编写 MVP 规格 — 产出简洁的范围文档，明确列出包含项、排除项和延期项。

输出格式

假设陈述

用一句话说明 MVP 将验证什么，以及如何衡量成功。

MoSCoW 分类

必备（v1 — 必须发布，否则产品无法成立）

功能	理由	风险级别	工作量估算
功能名称	为什么不能砍掉	低／中／高	T 恤尺码或天数

应该有（v1.1 — 发布后 2-4 周内上线）

使用相同的表格格式。这些内容能显著改善产品，但并非验证核心假设所必需。

可以有（v1.2+ — 有数据支持时再发布）

使用相同的表格格式。这些增强项取决于 v1 的学习成果。

暂不考虑（不属于本产品／本季度范围）

列出排除项，并简要说明每项的理由。

风险登记表

风险	类别	可能性	影响	缓解措施
描述	技术／市场／执行	高／中／低	高／中／低	降低风险的行动

MVP 范围概要

用简洁的段落描述 v1 的功能、目标用户，以及明确不包含的内容。

成功标准

明确的指标和阈值，用于判断 MVP 是否验证了该假设。

框架与最佳实践

• MoSCoW 优先级排序。
  • 必须具备： 缺少这项，产品就无法运行，或无法验证假设。要果断采用这项标准。如果超过 40% 的功能都属于必须具备，说明你的标准太低了。
  • 应该具备： 很重要，但产品可以不具备这项就发布。用户会注意到缺少这项，但可以找到变通方法。
  • 可以具备： 有了更好。只有在时间允许，且完全不影响必须具备的功能时才纳入。
  • 不会具备： 明确列为本周期范围之外。明确列出这些内容可以防止范围蔓延。
• “纸杯蛋糕，而非一层蛋糕”原则。 MVP 是一个完整但规模小的体验，而不是一个不完整的大型体验。纸杯蛋糕本身就是一份完整的甜点。没有糖霜的蛋糕层则是一个尚未完成的项目。
• 以加快学习为目标。 MVP 的任务是尽快验证假设。每项功能都必须是测试所必需的，否则就应移除。
• 先手动，再自动化。 如果某个流程可以为前 50 位用户手动完成，就不要在 MVP 中为它构建自动化功能。礼宾式 MVP 和绿野仙踪式 MVP 都是有效的方案。
• 聚焦一个用户细分群体。 试图服务多个细分群体的 MVP，往往无法很好地服务其中任何一个。选择痛点最强烈、销售周期最短的群体。
• 强制进行艰难对话。 如果团队无法就必须具备的功能达成一致，就问：“如果我们只能构建 3 项功能，会选哪 3 项？”从零开始逐项增加，而不是从所有功能开始再逐项删减。
• 延期不等于删除。 维护一个延期事项待办列表，并明确触发条件：“当指标 Y 达到阈值 Z 时，构建功能 X。”这能让利益相关者放心，知道他们的需求已被听取。
• 优先处理风险最高的事项。 先构建风险最高的必须具备功能。如果失败，你就能及早且低成本地吸取教训。如果成功，其他事项的风险都会更低。
• 范围蔓延信号。 留意这些说法：“既然都做到这一步了”“顺便再做……也很容易”“用户会期待……”“竞争对手都有……”。每当听到这类说法，都要回应：“这会改变我们的假设吗？”

相关技能

• prd-writing — 确定 MVP 范围后，为必须具备的功能编写 PRD。
• roadmap-planning — 将应该具备和可以具备的事项放入路线图的「下一步」和「以后」阶段。
• user-research-synthesis — 利用客户洞察验证哪些功能确实必须具备，哪些只是被假定为必须具备。

示例

示例 1：确定新产品 MVP 的范围

用户：“我们正在构建一款帮助自由职业者发送发票、跟踪时间、管理开支、处理税务和发送合同的工具。我们有 6 周时间和 2 名工程师。”

良好输出摘录：

假设： 我们认为，年收入为 $50K-$150K 的自由职业者，如果能使用简单的发票构建器并跟踪付款，就会在第一个月内至少发送 3 张发票；如果 40% 的注册用户达到这一门槛，就说明我们的判断正确。

必须具备： 创建发票、跟踪付款状态、通过电子邮件发送。 应该具备： 时间跟踪（关联到发票）、定期发票。 本周期不会具备： 开支管理、税务计算、合同管理。

删减理由： 时间跟踪和开支管理属于相邻工作流，但不是验证核心发票假设的必要条件。税务和合同是伪装成产品功能的独立产品。

示例 2：缩减现有功能的范围

用户：“我们的分析仪表板 PRD 包含 15 种图表类型、自定义日期范围、导出为 PDF/CSV、定时报告和实时数据。工程团队说需要 3 个月。我们需要在 6 周内完成。”

良好输出应当将 15 种图表类型归为 4-5 种必须具备的图表，覆盖 80% 的使用场景；将定时报告和实时数据延期；保留 CSV 导出但删去 PDF 导出；并指出自定义日期范围属于必须具备，因为每次用户访谈都提到了它。