第1章：MVP核心认知——定义、与完整产品区别、商业验证目的
01 适用场景
本章是《MVP定义与范围判定实操》的认知基石，适用于以下场景：
- 团队初次引入MVP理念，需要统一对“最小可行”的认知标准。
- 产品经理与开发团队对齐：在启动新功能或新项目前，消除“MVP=半成品”的误解。
- 创业项目早期验证：用最低成本测试核心商业假设，避免资源浪费。
- 企业数字化转型：快速交付最小闭环，获取真实业务反馈后再迭代。
- 课程学习者：作为本SOP课程的第一章节，为后续范围判定实操建立理论前提。
02 前置条件
进入本章学习前，需满足以下条件：
前置要求
- 已了解敏捷开发与精益创业的基本概念（例如迭代、反馈循环）。
- 具备基础的商业分析思维：能区分“功能需求”与“商业假设”。
- 已准备好参与团队讨论的角色（产品经理/技术负责人/业务方至少1人）。
- 无特殊工具要求，白板或协作工具（如Miro）即可完成本章认知对齐。
03 操作步骤（认知框架建立）
本章不以动手操作为主，而是通过以下4个认知步骤建立MVP核心认知：
- 步骤1：精确定义MVP
- MVP ≠ 功能最少的产品。
- MVP = 能够验证核心假设的最小版本（Eric Ries定义）。
- 输出：团队一致认可的口头/书面定义。
- 步骤2：对比完整产品
- 维度：范围——MVP只保留验证必需功能；完整产品包含全部计划功能。
- 维度：质量——MVP追求可用性而非完美；完整产品追求极致体验。
- 维度：交付周期——MVP周/月级；完整产品季度/年级。
- 步骤3：明确商业验证目的
- 验证用户需求是否存在（Value Hypothesis）。
- 验证用户是否愿意付费/使用（Growth Hypothesis）。
- 验证商业模式是否可持续（Cost & Revenue）。
- 步骤4：形成团队共识
- 通过案例讨论（如Dropbox的演示视频MVP）统一理解。
- 填写“MVP认知自检清单”（见下方【记录材料】）。
04 输入输出物
| 类型 | 具体内容 | 形式 |
|---|---|---|
| 输入物 | • 团队现有的产品愿景/商业画布 • 关键假设清单（若已梳理） • 用户痛点/场景描述 |
文档/白板 |
| 输出物 | • 统一后的MVP定义 • MVP与完整产品的对比表（至少3个维度） • 本产品/项目的核心商业假设列表 |
团队共识文档 |
05 责任边界
本章认知对齐过程中，各角色的责任划分：
- 产品经理：提供前期假设与用户调研结果，主持对比讨论。
- 技术负责人：从实现角度评估“最小”的可行性边界，提出技术风险。
- 业务/运营方：提供真实业务数据与市场反馈，明确验证指标。
- 决策者（如CTO/CEO）：最终确认定义与目的，避免过度设计。
06 记录材料
本章需填写以下材料并归档：
《MVP认知自检清单》（示例条目）
□ 我们是否明确本产品/功能要验证的核心假设？
□ 我们是否区分了“必须验证的功能”与“锦上添花的功能”？
□ 我们是否同意MVP不等于低质量，而是最小验证闭环？
□ 我们是否定义了成功验证的量化指标（如转化率 x%）？
□ 我们是否列出至少2个与完整产品的关键差异点？
归档方式：存入团队Wiki或项目文档库，文件名为 MVP_cognitive_checklist_<项目名>.md。
07 异常处理
本章常见异常及处理预案：
| 异常场景 | 原因 | 处理措施 |
|---|---|---|
| 团队成员对“最小”标准争论不休 | 缺乏统一的前置决策权 | 决策者当场拍板：以“验证核心假设所需功能”为准，其余一律不纳入。 |
| 业务方坚持要求“完整功能才上线” | 对MVP目的认知不足 | 重新讲解Dropbox、Zappos等经典MVP案例，强调“早交付早学习”的回报。 |
| 无法列出清晰的商业假设 | 前期用户调研缺失 | 暂停本章，执行一次简化的用户访谈或假设工作坊（建议1天内完成）。 |
08 验收标准
完成本章学习后，团队需通过以下检查：
- 验收项1：定义一致性 —— 所有核心成员能口头复述：“MVP是能够验证核心假设的最小版本，不是半成品。”
- 验收项2：对比清单 —— 输出一份MVP vs 完整产品的对比表（至少3个不同维度），且团队无原则性分歧。
- 验收项3：商业目的陈述 —— 针对当前项目，写出1～3条核心商业假设，例如：“我们发现xx用户因xx痛点会愿意购买xx服务，通过MVP验证最低付费意愿。”
- 验收项4：自检清单完成 —— 《MVP认知自检清单》中所有问题均已回答，且团队签字确认。
只有当上述4条验收项全部通过时，方可进入第2章“范围判定输入准备”。