第3章：MVP验证方案设计原则
MVP 验证方案的核心在于“以最小的成本获取最大的学习信息”。本章围绕三条互补原则——最小化实验范围、可度量成功标准、快速迭代周期——展开课程，确保每次验证都能产生可决策的数据，而非模糊的结论。
3.1 适用场景
- 需要对产品假设（如用户需求、功能价值、转化路径）进行真实市场验证的阶段。
- 团队资源（时间、预算、人力）有限，无法承载大规模并行实验。
- 产品处于探索期或转型期，需要快速判断方向是否可行。
- 评分模型需要输入“已验证假设”作为权重依据，而非仅依赖主观评分。
3.2 前置条件
| 条件 | 说明 |
|---|---|
| 明确的假设 | 已将产品构想转化为可验证的假设陈述，例如“用户愿意为每日提醒功能支付 3 元/月” |
| 最小可交付原型 | 能够支撑实验的最小功能集合，含低保真原型、单页面工具或人工服务闭环 |
| 可度量的指标预设 | 已定义好核心指标（转化率、留存率、NPS 等）及其成功阈值 |
| 实验周期约定 | 团队与干系人已就实验起止时间、迭代节奏达成一致 |
3.3 操作步骤
- 定义假设边界
把待验证的假设拆解为“最少需要几个变量”才能得出可信结论。每增加一个变量，实验范围就扩大一倍，解读难度也翻倍。 - 选择最小实验载体
从“最简陋但能给出答案”的载体开始：邮件原型 → 登陆页 → 人工模拟 → 单一功能版本。不追求完美，只追求“足够回答假设”。 - 设定可度量的成功标准
用数字定义“通过”与“不通过”。例如：在 3 周内，点击率 ≥ 15% 且付费转化 ≥ 3% 视为通过。 - 执行实验并记录原始数据
严格按照预设周期运行。记录越原始越好，避免后期处理偏差。 - 对照标准判断结果
将实际数据与成功标准对比，得出“通过 / 不通过 / 需修改假设”的结论。 - 快速迭代或终止
通过则扩大实验范围；不通过则回归分析原因，调整假设或放弃。
🔑 关键原则：如果实验周期超过 4 周，说明实验范围可能过大，应拆分为多个更小的子实验。
3.4 输入输出物
| 物项 | 输入 | 输出 |
|---|---|---|
| 假设清单 | 已验证的假设清单 | 优先级排序后的待验证假设列表 |
| 原型/模拟方案 | 低保真原型、流程说明 | 可运行的实验环境（含埋点） |
| 指标定义文档 | 成功标准字段表 | 已量化的判定规则（含阈值） |
| 实验日志 | 每日原始数据、截图 | 结论报告 & 迭代建议 |
3.5 责任边界
- 产品经理：负责定义假设、设定成功标准、撰写实验方案。
- 设计师/开发：负责搭建最小实验载体（原型或轻量代码），确保埋点完整。
- 数据分析师：负责数据采集、清洗、对照标准输出结论。
- 决策者：在实验结束后 24 小时内给出“继续 / 调整 / 放弃”的指令。
⚠️ 常见逾界：产品经理不应在实验期间修改假设或指标，否则实验失去对照意义。
3.6 记录材料
- 实验设计清单（含假设、变量、指标、周期）
- 每日原始数据表（时间戳、行为、数量）
- 结论报告（实际值 vs 阈值、偏差分析、下一步行动）
- 复盘纪要（遇阻原因、改进点、最佳实践）
💡 建议使用统一模板存储每次实验的记录材料，便于后期汇总为评分模型的学习因子。
3.7 异常处理
| 异常情形 | 处理方式 |
|---|---|
| 实验样本量不足 | 延长实验周期（不超过原周期的 50%）或切换更高触达渠道 |
| 埋点数据丢失 | 启用备用人工日志（记录截图、客服反馈），同时修复埋点 |
| 外部环境突变 | 暂停实验并记录事件原因，待环境稳定后重新启动 |
| 用户反馈严重偏离预期 | 立即停止实验，组织定性访谈，调整假设后重跑 |
3.8 验收标准
- 每个假设均通过“最小实验载体”完成验证。
- 成功标准在实验启动前已明确记录，且未在实验期间修改。
- 实际数据与阈值的对比结果清晰可读，不存在“无法判断”的灰色状态。
- 从实验启动到输出结论的时间 ≤ 原定周期的 120%。
- 记录材料完整，可供第三方回溯并复现结论。