第2章 适用场景判断与前置条件

2.1 什么阶段适合做MVP测试

MVP测试并非适用于产品的所有阶段，其最佳窗口集中在以下四个阶段：

• 产品构想期——仅有核心假设与初步概念，尚未投入开发资源，此时MVP测试用于验证市场是否需要该功能或方案。
• 功能探索期——已有最小可用版本，但关键功能或交互路径仍在探索中，MVP测试可快速验证功能可行性与用户接受度。
• 增长瓶颈期——产品已上线但留存、转化等指标停滞，通过MVP测试验证新的增长假设（如新的获客渠道、定价策略）。
• 技术方案选型期——存在多种技术路径或实现方式，用MVP测试对比不同方案对用户关键行为的影响。

2.2 什么场景需要机会评分

机会评分（Opportunity Scoring）用于定量评估多个候选假设或方案的投资优先级，适合以下场景：

• 资源约束场景——开发、设计、运营资源有限，需从多条假设中选出ROI最高的前1-2条。
• 多假设并行期——同时提出超过3条候选假设，且每条都有一定的用户调研或数据支撑，无法通过直觉快速决策。
• 利益相关方分歧场景——产品、技术、业务方对优先级意见不一致，需要统一、可复现的评分框架来对齐决策。
• 版本路线规划——季度或年度路线图制定前，对已积累的用户痛点和机会点进行系统化打分与排序。

2.3 前置条件清单

条件类别	具体条件	说明
已有假设	假设陈述（问题-方案-价值）	必须是一条可被证伪的因果假设，例如“用户因结算流程过长而放弃下单”。
用户原型	目标用户画像 + 典型行为场景	包含用户角色、核心行为节点、使用环境，用于确定测试对象的招募标准。
验证指标	核心北极星指标 + 关键行为指标	必须定义通过/未通过阈值，如“完成率≥60%视为假设通过”。

2.4 不适用场景警示

2.5 操作步骤

1. 阶段类型确认——对照2.1节判断当前阶段是否属于四个适用窗口之一。如不在，直接进入“不适用场景警示”并终止流程。
2. 场景需求匹配——若处于适用窗口，进一步判断是否存在“多假设冲突/资源约束/利益分歧”，以决定是否启用机会评分。
3. 前置条件自检清单——逐项检查假设、用户原型、验证指标是否具备。任一项缺失则回退至假设构建或用户研究阶段。
4. 决策分流——满足全部前置条件后，根据阶段和场景选择“仅MVP测试”或“机会评分+排序后再次排MVP测试”。

2.6 输入输出物

方向	内容	交付形式
输入	候选假设列表（≥1条）、用户原型描述（≥1组）、验证指标阈值文档	.md或Wiki页面
输出	适用场景判断结论、前置条件自检结果、决策分流记录	决策日志（含判断依据与时间戳）

2.7 责任边界

• 产品经理——负责假设陈述与验证指标定义，承担前置条件自检结果的第一背书责任。
• 用户研究员——提供用户原型与典型场景描述，协助判断假设备选用户的招募可行性。
• 数据分析师——验证指标的计算口径与阈值可行性提供专业意见。
• 决策评审人（EM/总监级）——最终确认是否进入MVP测试阶段，尤其在不适用场景边缘时行使“否决权”。

2.8 记录材料

适用场景判断记录表
项目名称：____________________ 日期：__________ 判断人：__________

阶段类型：□产品构想期 □功能探索期 □增长瓶颈期 □技术选型期 □其他
是否属于适用窗口：□是 □否
若否，原因：__________________________

场景需求：□多假设冲突 □资源约束 □利益分歧 □无（仅做单假设验证）

前置条件自检：
  已有假设 □具备 □缺失（说明：______）
  用户原型 □具备 □缺失（说明：______）
  验证指标 □具备 □缺失（说明：______）

决策结论：□进入MVP测试 □先机会评分再排序 □不适用，终止

2.9 异常处理

异常场景	处理措施
前置条件“已有假设”缺失	回退至假设生成工作坊，输出假设陈述后再重新进入本章节点
用户原型与验证指标全部具备，但阶段类型模糊	由产品经理+技术负责人+业务方三方评估，2/3以上一致同意则视为适用
团队倾向做MVP测试但资源不到位	启用“机会评分”对假设中的高置信项做优先级排序，集中资源测试Top1
验证指标阈值设置过高/过低（测试失败率100%或0%）	由数据分析师介入调整阈值至历史同类假设或行业基准值，重新自检

2.10 验收标准

• 适用场景判断结果明确记录在决策日志中，判断依据可回溯。
• 前置条件清单三项全数通过，且每条条件均有可查阅的支撑材料（假设文档/原型卡片/指标定义文档）。
• 若启用机会评分，评分结果及排序记录已纳入决策日志，且与MVP测试设计环节有明确衔接。
• 不适用场景警示节点如被触发，必须附有“终止原因”说明，并由决策评审人签字确认。