MVP Scope Definition 🎯

MVP 范围定义。从用户故事地图中砍掉一切不必要的东西，只保留验证核心假设所必需的功能。

执行流程

第一步：汇集需求池

从前置输出中收集所有潜在需求：

📦 需求来源清单

□ 用户故事地图（user-story-mapping）的输出
□ 价值主张画布（value-proposition）的核心功能
□ 问题访谈中用户的明确请求
□ 竞品分析中「必须覆盖」的基础能力
□ Concierge MVP 中已验证有效的服务

完成标准：所有需求可见，没有遗漏来源。

第二步：MVP 的钢铁定义

引导用户理解 MVP 的真正含义：

💡 MVP ≠ 功能最少的产品

MVP = 最小可行产品
  - 最小：刚好够验证最关键假设
  - 可行：用户能用它完成核心任务
  - 产品：不是 demo，不是原型，是真实可用的

MVP 的唯一目的：用最低成本学习最有价值的信息

关键问题清单：
  ✂️ 砍掉这个功能，用户还能完成核心任务吗？ → 能就砍
  ✂️ 这个功能是用户「想要」还是「需要」？ → 「想要」先记下，下个版本
  ✂️ 这个功能有没有更简单的替代方式？ → 有就用替代

第三步：KANO 模型分类

将需求按 KANO 模型分类：

📊 KANO 需求分类

🟢 基本型需求（Must-be）— 没有用户会气疯
  ├── [需求1]
  └── [需求2]
  
  规则：只做到「刚好够用」，过度投入没有边际收益

🔵 期望型需求（Performance）— 越多越好
  ├── [需求3]
  └── [需求4]

  规则：选 1-2 个最能体现差异化的

🟣 兴奋型需求（Attractive）— 没有无所谓，有则惊喜
  └── [需求5]
  
  规则：MVP 阶段通常不做，留到 V2

⚪ 无差异需求（Indifferent）— 做不做没区别
  └── [需求6] → ✂️ 直接砍掉

完成标准：所有需求被分类，M 类 ≤ 30%，P 类选 1-2 个。

第四步：MoSCoW 优先级

📋 MoSCoW V1 优先级

🔴 Must Have（没有这些，MVP 不成立）
  - [核心用户旅程完整闭环 - Walking Skeleton]
  - [最少 1 个让用户「用了就回不去」的功能]
  - [基本的数据统计（用于验证）]

🟡 Should Have（重要但可以先不做）
  - [对体验重要但不阻塞核心任务的]
  
🟢 Could Have（有更好，没有也行）
  - [锦上添花的功能]

⚪ Won't Have（这版明确不做）
  - [明确推迟到 V2 的功能]

关键要求：Must Have 的数量 ≤ 团队能力 × 2 周。

第五步：MVP 一页纸说明

📄 MVP 一页纸

产品名称：[名称]

核心假设：
  [这个 MVP 要验证什么？]

目标用户：
  [谁是 V1 用户？首批多少人？]

核心用户旅程（3-5 步）：
  1. [步骤]
  2. [步骤]
  3. [步骤]
  4. [步骤]
  5. [目标达成]

核心功能清单（Must Have）：
  1. [功能] — 理由：[为什么不能没有]
  2. [功能] — 理由：[...]
  ...（≤ 8 个）

明确不做（Won't Have）：
  1. [功能] — 推迟到 V2 的原因：[...]
  2. [功能] — 推迟到 V2 的原因：[...]

成功标准：
  [指标] ≥ [目标值]  → 代表验证通过

预计时间：[X] 周

反模式

• ❌ Must Have 太多（超过 8 个就不是 MVP 了）
• ❌ MVP 没有验证假设的设计（变成了缩小版产品，而不是学习工具）
• ❌ 把「以后再做」的功能设计进当前架构（YAGNI 原则）
• ❌ 花太多时间「定义 MVP」而非「开始做 MVP」

推荐下一步

→ sprint-zero：启动 Sprint 0 准备工作 → sprint-planning：把 MVP 拆分为冲刺任务