MVP 范围

明确定义 MVP 的进与出——测试核心假设的最小东西。

为什么

MVP 范围是产品开发中最被滥用和最少定义的术语。"建个 MVP"没有定义范围就变成"一个月内能建的都建"。正经的 MVP 范围是测试你单一最危险假设的最小功能集——通常是"他们会用/付吗？"。其他都出。这很痛因为意味着砍掉你知道用户最终会要的功能，但包含它们会延迟告诉你是否该建它们的学习。4 周测核心假设的 MVP 胜过 4 月建全愿景的 MVP——你早 3 个月学到转型还是继续。

何时使用

在契合打分通过后、任何工程之前。1-2 天辩论 + 定义。构建前锁范围。

如何做

1. 陈述 MVP 测试的单一假设
   - 不是"建 changelog 工具"——"开发者会付 $15/月自动生成 changelog"
   - MVP 中一切须服务测试此假设

2. 列你为全产品想象的所有功能
   - 自由头脑风暴——这是愿景不是 MVP
   - 分组：核心（测假设）、支撑（核心工作所需）、未来（现在不）

3. 仅当功能过 3 测试才移入 MVP
   - 没这功能假设会失败吗？（否则未来）
   - 没这功能能测假设吗？（是则未来）
   - 核心循环需要它才能运作吗？（否则未来）

4. 定义 MVP 的核心循环
   - 测试假设的最小用户动作序列
   - 例："连仓库 → 推提交 → 看生成 changelog → 复制"
   - 每步必须在；无步可跳!跳

5. 明确定义出什么
   - 写"不在 MVP"清单：无认证（用魔法链接）、无团队、无集成、无设置页
   - 这清单比进清单更重要——防范围蔓延

6. 设时间盒
   - 单人最多 4-6 周，团队 2-3
   - 放不下就再砍——时间盒逼诚实面对范围

示例

产品：AI changelog 生成器。
假设："独立开发者会付 $15/月从 git 提交自动生成 changelog。"

全愿景功能（20）：
  AI 生成、git 集成、自定义模板、团队分享、Slack/Discord 发布、
  语义版本、发布说明样式、多仓、changelog 托管、AI 语气调整、导出 PDF、API、webhook、!webhook、自定义品牌...

MVP 范围（过 3 测试）：
  - GitHub OAuth（核心循环需要）✓
  - 连一个仓库 ✓
  - 从提交生成 changelog（假设测试）✓
  - 复制到剪贴板（用输出需要）✓
  - Stripe $15/月结账（假设测试）✓

!Stripe $15/月结账（假设测试）✓

明确不在 MVP：
  - 无自定义模板（用一个好默认）
  - 无团队分享、无 Slack 发布、无多仓
  - 无 API、无 webhook、无 PDF 导出
  - 无设置页（全硬编码配置）

时间盒：单人 3 周。
核心循环：连仓库 → 推 → 看 changelog → 复制 →（付 $15 继续用）

常见问题

⚠把 MVP 定义为全产品的小版——MVP 是假设测试不是功能子集；不测假设的功能无论多小都出。
⚠因"容易加"而含功能——易功能仍花时间、增表面积、分散核心循环注意力；保持在外。
⚠无明确出清单——无书面"不在 MVP"清单，构建时范围蔓延因每个功能都显得小且合理。
⚠无时间盒——无截止日 MVP 膨胀填满所有可用时间，你比本可以更晚学到。

最佳实践

✓列功能前把假设写成可测陈述——"开发者会付 $15/月"可测；"开发者会喜欢"不可。
✓出清单比进清单更重要——构建时每天复查；如果在建出清单上的东西，停。
✓设硬时间盒并砍范围以适应——按时发更小 MVP 比晚发更大好（你更早学）。
✓把核心循环定义为用户动作序列——如果缺任何动作，循环断且假设无法测!循环断且假设无法测。