4. MVP定义与范围界定
适用场景
- 产品团队完成机会评分与假设清单后，需要将待验证假设转化为最小可行产品。
- 面对多个功能点子时，需要统一团队对“最小可行范围”的认知，防止需求蔓延。
- 跨角色（产品、设计、开发、测试）协作前，使用统一模板锁定阶段交付物边界。
前置条件
- 已输出《机会评分表》，确认本迭代要验证的核心假设。
- 至少完成一次用户分群，明确目标验证用户画像。
- 团队已就关键指标（如周留存率、任务完成时长）达成共识。
操作步骤
步骤一：分解用户故事与功能候选
- 将核心假设表达成“As a … I want … So that …”的用户故事。
- 列出所有可能支撑该故事的功能候选，放入功能候选池。
步骤二：应用 Must / Should / Nice 裁剪规则
| 类别 | 定义 | 裁剪动作 |
|---|---|---|
| Must | 缺少则假设完全无法验证，用户无法完成核心任务。 | 必须包含在 MVP 内，不裁剪。 |
| Should | 提升体验或效率，但缺失时仍能完成验证闭环。 | 先保留，若工期紧张可降级为 Nice 或延迟。 |
| Nice | 锦上添花，与核心验证路径无关。 | 直接移出本次 MVP 范围，放入 backlog。 |
步骤三：确定交付物边界与验收门槛
- 交付物边界：明确 MVP 形态，可能是 A/B 实验链接、交互原型、落地页或人工服务（白手套）。
- 验收门槛：设定“通过/不通过”的具体数值或行为标准。
输入输出物
| 类型 | 内容 | 格式建议 |
|---|---|---|
| 输入 | 机会评分表、用户分群画像、假设清单 | 在线文档 / 电子表格 |
| 输出 | MVP 范围定义文档（含 Must 清单、交付物边界、验收门槛） | Notion 页 / 语雀 / 项目管理系统卡片 |
责任边界
- 产品负责人：最终决策 Must 清单，确认验收门槛。
- 设计师/开发代表：评估 Should/Nice 的实现成本与工期影响。
- 验证分析师：确认验收门槛是否符合之前约定的核心指标。
记录材料
- MVP 范围定义文档必须包含：功能候选池列表、Must/Should/Nice 分类表、交付物形态说明、验收门槛定义。
- 团队评审会纪要：记录裁剪争议点与最终决策理由。
避坑要点：避免把“Should”当作“Must”塞入 MVP，导致验证周期变长；验收门槛不要写“尽量好”、“体验流畅”等模糊措辞，必须使用可测量指标。
异常处理
- Must 项目过多导致工期超出预算：重新审视核心假设，检查是否将多个假设合并到一个 MVP 中；考虑拆分验证为两个轮次。
- 团队对“Nice”仍有强烈信念：将 Nice 功能记录为“预研项”，允许在 MVP 上线后以实验方式触发，但不影响当前范围冻结。
- 验收门槛数据在实验前无法反推：先使用行业基准或竞品数据作为临时门槛，并在首轮验证后进行校准。
验收标准
- MVP 范围定义文档通过团队评审，且所有角色（产品、设计、开发、测试）签字确认。
- 交付物边界清晰，团队能准确说出“这次 MVP 不做什么”。
- 验收门槛可量化、可观测，与前置条件中的核心指标直接对应。
注意：验收门槛必须是“验证假设”的标准，而非“产品完美”的标准。例如“用户在 1 分钟内完成邀请动作”而非“用户界面像素级完美”。