第二章 划定MVP范围的前置条件
适用场景
本阶段适用于产品团队已初步完成产品定义，准备进入最简可行产品（MVP）范围划定环节。在执行RICE模型打分之前，必须确认以下四项前置条件均已成熟，否则后续的优先级排序和功能取舍将失去依据，导致MVP范围偏离核心用户价值或开发资源浪费。
前置条件详述
下列四个条件是开展本章工作的基础，缺一不可。每个条件都有明确的检查要点。
| 前置条件 |
核心要求 |
可交付物示例 |
| 产品愿景明确 |
团队能用一句话描述产品长期目标与价值主张，并达成一致理解 |
愿景声明文档、电梯演讲稿 |
| 用户画像清晰 |
至少有一份已验证的用户画像，包含目标用户角色、核心痛点、使用场景 |
用户画像卡片、Persona表格 |
| 已有候选功能清单 |
通过需求收集、竞品分析或用户调研产出的功能列表，每个功能有简短描述 |
功能清单表（含序号、功能名称、描述、来源） |
| 团队共识准备 |
产品经理、设计师、技术负责人及相关干系人对MVP目标和评估规则已有初步认知 |
启动会议记录、共识确认邮件 |
操作步骤：逐项检查并确认前置条件
- 召开前置条件对齐会议 — 组织产品经理、设计师、技术负责人、测试代表参加，时长控制在30分钟内。
- 检查产品愿景 — 请产品经理朗读愿景声明，所有人依次用一句话复述，确认无歧义。
- 检查用户画像 — 展示画像卡片，逐角色确认痛点与场景是否覆盖核心用户群。
- 检查候选功能清单 — 逐一核对功能来源和描述，标记“待补充”项并限时补全。
- 检查团队共识 — 询问每位成员对MVP边界、评估流程是否有疑问，记录并解答。
- 生成检查报告 — 输出前置条件检查表（通过/未通过），若全部通过则进入下一节，否则进入异常处理。
输入输出物
| 类型 |
输入物 |
输出物 |
| 文档 |
产品愿景声明、用户画像卡片、候选功能清单 |
前置条件检查报告（含各条件状态） |
| 会议记录 |
无 |
对齐会议纪要（签名、日期、疑虑项） |
| 工具 |
团队共识检查清单 |
标记更新的候选功能清单（带“待补充”标识） |
责任边界
| 角色 |
责任 |
| 产品经理 |
主导愿景、画像、功能清单的完整性；组织对齐会议；生成检查报告 |
| 技术负责人 |
确认功能清单的技术可行性初步判断；提出资源约束 |
| 设计师 |
确认用户画像中交互场景的合理性；补充可用性需求 |
| 测试代表 |
从测试视角提出功能清单中的验证盲区 |
| 项目/Scrum Master |
监督流程推进，确保所有条件在规定时间内验证完成 |
记录材料
- 前置条件检查报告模板（表格形式，含条件名称、检查时间、检查人、结论、备注）
- 对齐会议纪要模板（日期、参与人、发言摘要、待办项）
- 团队共识确认单（每位成员签字或钉钉/飞书签名）
- 功能清单状态跟踪表（Excel或在线文档，含“待补充”“已确认”列）
异常处理
| 异常情形 |
处理流程 |
| 产品愿景存在分歧 |
暂停MVP划定，组织愿景工作坊，使用“电梯演讲”框架统一描述；最多2小时深度讨论，仍未达成则升级至业务负责人裁决。 |
| 用户画像缺失或过时 |
安排1~2天用户访谈或问卷补采数据，快速生成至少一位核心用户画像；在会议纪要中标记为“临时前置条件-本周内完成”。 |
| 候选功能清单不完整 |
开启48小时功能征集窗口，可结合邮件/协作工具收集；对已明确的功能先行打分，待补充功能以后续轮次纳入。 |
| 团队共识不足（成员质疑评估标准） |
产品经理重新宣讲RICE模型的四要素（覆盖面、影响力、信心、努力），用实际案例演示一次打分；若仍存在抗拒，则授权技术负责人和设计师各推荐3个候选功能作为最小范围示范。 |
验收标准
- ✅ 所有四项前置条件均被打上“通过”标签（不可有“待补充”状态进入下一步）。
- ✅ 对齐会议纪要中无未解决的异议（所有疑虑项至少关闭或升级）。
- ✅ 候选功能清单已更新到最新版本，且列明每个功能的来源与状态。
- ✅ 团队共识确认单已得到所有核心角色签名（或等效的电子确认）。
- ✅ 前置条件检查报告已归档到项目知识库，可供后续追溯。
💡 最佳实践： 前置条件检查最好在RICE模型打分的前一周完成，预留时间处理异常。如果四个条件中有任意一项被判定为“未通过”，不要强行进入下一步，先启动异常处理流程中的补救措施。忽视前置条件直接打分将导致MVP范围严重偏离用户真实需求。