第1章 MVP核心概念与交付目标
1.1 边界定义
最小化可行产品不是“最简产品”，而是验证关键业务假设所需的最小交付单元。其边界由三个约束构成：
- 功能边界：只包含能触发目标用户行为、产生可测量反馈的功能
- 时间边界：交付周期必须短于假设失效周期
- 用户边界：面向早期采纳者而非大众市场
| 维度 | 包含（MVP范畴） | 不包含（延迟验证） |
|---|---|---|
| 功能 | 核心用户旅程 + 1～2个验证机制 | 性能优化、管理后台、多语言 |
| 质量 | 可运行、可记录行为数据 | 99.99%可用性、极致体验 |
| 用户 | 种子用户/先锋用户群 | 全量市场推广、品牌建设 |
边界检查示例：如果团队花2周实现用户注册功能但仅用于登录，而核心假设是“用户愿意为AI生成报告付费”——注册功能已超出边界，应优先做支付预览页。
1.2 分层架构
MVP交付过程可分解为三个逻辑层，层间通过假设–数据–决策控制流衔接：
- 概念层：将商业假设转化为可验证的功能需求（例：用户每日打开≥3次，留存率>15%）
- 交付层：实现最小功能集并部署到目标用户触达通道
- 验证层：采集行为数据、用户反馈，与假设阈值比对
1.3 组件职责
| 组件 | 职责 | 边界 |
|---|---|---|
| 假设定义器 | 明确一个可量化、可证伪的业务假设 | 仅输出假设声明与测量方法 |
| 功能裁剪器 | 从需求池中挑选最直接验证假设的5～10个功能 | 拒绝任何“nice-to-have”需求 |
| 反馈采集器 | 埋点、日志、问卷、会话记录 | 只采集验证假设所需的最小数据集 |
| 决策引擎 | 比较实际数据与假设阈值，输出 pivot/persevere | 不包含长期战略规划 |
1.4 数据流 / 控制流 / 信任链路
- 数据流：用户操作 → 反馈采集器 → 事件存储 → 决策引擎
- 控制流：假设定义器 → 功能裁剪器 → 交付层 → 验证层 → 决策引擎 → 下一轮假设调整
- 信任链路：每个节点必须保证可溯源（假设→功能→埋点→数据）且抗干扰（排除噪声用户、刷量行为）
# 假设记录示例（YAML 格式，非配置）
假设ID: H-001
声明: "用户在首次使用后72小时内回访率 ≥ 40%"
验证方法: "注册后72小时内登录次数 ≥ 1"
最小样本量: 200
阈值: 40%
1.5 选型权衡
| 权衡对 | 倾向MVP | 风险 |
|---|---|---|
| 功能数量 vs 交付速度 | 减少功能以2周内交付 | 功能过少导致假设无法触发 |
| 代码质量 vs 反馈速度 | 容忍技术债 | 负面体验导致用户流失，污染数据 |
| 精准定位 vs 广撒网 | 定向邀约种子用户 | 样本偏斜，假设验证失效 |
常见陷阱：团队倾向于“多做一点”以确保成功——这恰恰违背MVP本质。每增加一个非必要功能，交付周期拉长1.5倍时，假设失效概率指数级上升。
1.6 风险点
- 假设错误：核心假设本身不成立，MVP验证无效
- 最小化过度：功能集缺失关键交互节点，用户无法完成主要流程
- 反馈污染：种子用户带有偏见或非目标用户破坏数据
- 决策延迟：数据收集周期超过假设有效窗口
1.7 落地步骤
- 明确核心假设：写出“我们相信如果……则用户会……”格式的假设
- 设计验证方法：定义成功标准、测量方式、最小样本量
- 裁剪功能集：从所有需求中标记“必须验证功能”（M）和“可延迟”（D）
- 快速构建+发布：使用低代码工具或现成框架，避免从零重写
- 部署采集点：在关键事件（注册、支付、分享）处埋点
- 启动种子用户：通过邀请码或定向广告触达
- 收集数据并决策：按预定时间窗口分析，决定 pivot / persevere / kill
1.8 验收标准
| 编号 | 标准 | 可测量指标 |
|---|---|---|
| AC-1 | 功能集与核心假设一一对应 | 每个假设至少对应1个可交互功能 |
| AC-2 | 交付周期 ≤ 假设失效周期 | 从立项到发布 ≤ 3周 |
| AC-3 | 至少采集到预设最小样本量的有效数据 | 样本量 ≥ 200，且有效用户占比 > 80% |
| AC-4 | 决策引擎能输出明确结论 | 数据与假设阈值差异显著性检验 p < 0.05 |