1. MVP场景概念与课程适用边界
1.1 什么是MVP场景
MVP场景是指能够用最小可行产品（Minimum Viable Product）进行验证的一次完整用户交互片段。它不是需求条目，而是一个从触发到结果的可测试闭环。
| 维度 | 典型特征 | 非典型特征 |
|---|---|---|
| 粒度 | 单个用户意图 + 闭环 | 大需求拆解前的原稿 |
| 验证目标 | 明确的假设检验 | 模糊的产品想法 |
| 交付物 | 可运行的最小交互版本 | PRD、原型、设计稿 |
| 产出证据 | 用户行为/数据/反馈 | 团队内部评审结论 |
关键判断标准：如果该交互不能独立产生用户反馈数据（点击、留存、转化、NPS），则不是MVP场景。
1.2 课程目标
- 掌握从业务需求中识别和提取MVP场景的方法。
- 学会对MVP场景进行优先级排序（基于风险-价值矩阵）。
- 输出标准化的MVP场景描述卡和排序交付物。
- 降低因“做错验证方向”导致的开发资源浪费≥40%。
1.3 适用角色
| 角色 | 核心职责 | 与本课程的关系 |
|---|---|---|
| 产品经理 | 需求分析、场景定义 | 直接使用全部方法 |
| 技术经理 | 研发排期、可行性评估 | 评估场景实现成本 |
| 业务负责人 | 决策验证方向 | 确认场景商业假设 |
| 测试/QA | 验收MVP交付物 | 理解验证闭环标准 |
| 创业者/创新团队 | 快速验证产品方向 | 完整操作课程模板 |
1.4 前置知识要求
- 敏捷开发基础：了解Scrum/Kanban中用户故事、Sprint的概念。
- 需求分析方法：能使用用户画像、用户故事地图进行粗粒度的需求梳理。
- 基础数据指标：理解转化率、留存率、月活跃用户的含义。
- 项目管理常识：能区分里程碑、交付物和产出。
🎯 前置自查：如果你还不能用一句话说清“用户为什么需要这个功能”，建议先补齐用户故事地图技能。
1.5 课程适用的工作场景
- 0→1 新产品验证：只有一个核心假设，需要快速试错。
- 成熟产品功能扩展：已有存量用户，但新功能方向不确定。
- 内部工具/流程自动化：用户是组织内部角色，验证成本敏感。
- 数据驱动优化回合：已有大量行为数据，需要选择哪个环节做MVP实验。
1.6 输入与输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 文档 | 初始需求列表、用户旅程图 | MVP场景描述卡（标准化文档） |
| 决策 | 业务假设列表 | 优先级排序矩阵（风险-价值坐标图） |
| 验收 | 团队开发产能信息 | MVP场景交付验收清单 |
1.7 责任边界
- 产品经理：负责场景提取的准确性、场景描述卡的完整性。
- 技术负责人：负责场景的技术可行性评估，提供开发工作量估算。
- 业务决策者：负责最终优先级裁决，对“不做”的场景承担责任。
⚠️ 误区提醒：MVP场景提取不是产品经理一个人的任务。没有技术可行性评估的场景卡，在排序阶段会被直接标记为“高风险”，最终大概率被搁置。
1.8 记录材料要求
- 每张MVP场景卡必须记录：场景编号、业务假设、验证指标、最低功能清单。
- 优先级排序结果必须附带风险-价值解释，禁止仅排序无理由。
- 所有材料使用统一的模板（本课程第5章提供），禁止个性化格式。
1.9 异常处理规则
| 异常情况 | 处理策略 |
|---|---|
| 场景提取后无法对应任何用户行为指标 | 退回到用户故事地图，补充用户行为触点 |
| 出现2个以上场景优先级得分相同 | 启用“最小交付代价优先”规则，比较开发人天 |
| 业务方临时新增场景 | 冻结已排序结果，新场景进入下一轮筛选 |
1.10 验收标准
- 所有业务需求都被拆解为可独立测试的MVP场景，无遗留。
- 每个场景都至少有一条量化的验证指标（如：完成率 > 60%）。
- 优先级排序结果中，前3个场景的累计验证投入 ≤ 可用资源的 30%。
- 课程团队内所有角色（PM、RD、业务）均确认场景定义无误。