06-mvp-validation

name	06-mvp-validation
description	设计并执行 MVP 验证实验。当用户说"MVP"、"最小可行产品"、"快速验证"、"原型测试"时使用。

MVP Validation

何时使用

• 需要验证产品假设或新功能方向
• 需要用最小成本测试市场反应
• 需要设计 MVP 并定义验证标准
• 需要决定一个功能是否值得全量开发

工作流程

Step 1: 明确验证假设

把模糊的想法变成可验证的假设：

• "我们相信 [目标用户] 有 [这个问题]"
• "如果我们提供 [这个方案]，将看到 [这个指标变化]"
• 定义成功/失败的明确标准

Step 2: 选择 MVP 类型

用最小成本验证核心假设：

• 落地页 MVP：测试需求是否存在
• 绿野仙踪 MVP：人工模拟，验证体验
• 单功能 MVP：只做核心功能，快速上线
• 众筹 MVP：测试付费意愿

Step 3: 执行验证

快速构建并投放 MVP：

• 时间压缩到 1-2 周
• 只衡量核心假设相关的指标
• 收集定性 + 定量数据

Step 4: 决策：继续/转向/放弃

基于预设标准做决策：

• 达标 → 加大投入全量开发
• 信号不明 → 调整方案再测
• 明确不达标 → 果断放弃，转向下一个假设

关键原则

原则	说明
一个 MVP 验证一个假设	不要一个 MVP 试图证明所有事情
定义失败 > 定义成功	上线前先说清楚"什么情况算失败"
时间盒	给 MVP 设定固定时间窗口（2-4周），到期必须决策
数据 + 定性	数字说明有没有变化，访谈说明为什么有/没有变化
接受沉没	MVP 证明假设错误是最好的结果之一

落地模板

# MVP 实验计划：[产品/功能名称]

## 1. 核心假设
用一句话描述要验证的假设：
> 我们相信 [目标用户] 在 [场景] 下，愿意使用 [解决方案] 来解决 [问题]，
> 因为 [价值主张]。

### 假设拆解
| 子假设 | 风险等级 | 本次MVP验证？ |
|--------|---------|-------------|
| 问题确实存在 | 高/中/低 | ✅/❌ |
| 目标用户愿意尝试 | | |
| 解决方案能解决问题 | | |
| 用户愿意为此付费 | | |
| 我们有能力交付 | | |

**本次 MVP 聚焦验证：** [选一个最高风险的子假设]

## 2. 实验设计
### MVP 形态
- [ ] 落地页测试（Fake Door）：只做页面，测量点击/注册
- [ ] 手动服务（Wizard of Oz）：界面是产品，后台是人工
- [ ] 原型测试（Prototype）：可点击原型 + 用户访谈
- [ ] 最小功能版本（Functional MVP）：核心功能可用
- [ ] 众筹/预售：先收钱看需求

### MVP 包含什么
| 必须有 | 不需要 | 如果有时间 |
|--------|--------|-----------|
| [核心功能] | [优化/美化] | [增值功能] |

### MVP 不包含什么（明确排除）
- [x] 不做用户系统（用邀请码）
- [x] 不做支付（手动对账）
- [x] 不做推送通知
- [...]

## 3. 成功/失败标准（上线前确定！）
| 指标 | 成功线 | 失败线 | 灰色地带处理 |
|------|--------|--------|-------------|
| [核心指标，如注册转化率] | ≥ X% | < Y% | 如果在Y-X之间，[追加N次用户访谈] |
| [次要指标] | | | |

### 明确的决策规则
- 如果成功 → [全量开发，预计周期...]
- 如果失败 → [放弃 / pivot到... / 修改假设重新测试]
- 如果灰色 → [具体的追加验证方案]

## 4. 时间盒
- 开发时间：[X 天/周]
- 运行时间：[Y 天/周]
- 决策日期：[具体日期]——到期必须做决策
- 负责人：[谁来做最终判断]

## 5. 学习记录（实验结束后填写）
### 数据结果
| 指标 | 预期 | 实际 | 判断 |
|------|------|------|------|
| | | | 成功/失败/灰色 |

### 用户反馈（定性）
- 正面：[...]
- 负面：[...]
- 意外发现：[...]

### 结论
- 假设被验证/被推翻/不确定
- 下一步行动：[...]
- 学到了什么：[...]

参考资料

详细理论基础、原则解析和推荐书目见 references/knowledge.md。