2. MVP基础概念：定义、核心理念、与完整产品的区别

2.1 适用场景

本章内容在以下场景中必须前置导入，确保团队对MVP的认知起点一致：

• 新团队启动敏捷产品开发：团队成员来自不同背景，需统一对MVP的理解。
• 产品规划阶段界定范围：在划定初始版本功能边界前，先建立概念共识。
• 跨部门对齐评审：业务、设计、开发、测试等角色共同学习，减少因定义模糊导致的协作摩擦。
• 导入决策树工具前：决策树的应用建立在对MVP本质的准确理解之上，本章是后续章节的认知地基。

2.2 前置条件

2.3 操作步骤

按照以下5个认知步骤建立MVP概念体系，每一步都有明确的交付物。

1. 学习MVP定义，标记核心关键词

   标准定义：MVP（Minimum Viable Product，最小可行产品）是指通过最少的功能投入，交付能够验证核心用户假设并获取真实反馈的产品版本。

   从定义中提取四个关键词：最小（不做多余功能）、可行（能独立运行）、验证（对准假设）、反馈（驱动迭代）。

2. 拆解核心理念，建立理解框架

   MVP不是“偷工减料”，而是“精准投入”。以下框架图展示了支撑MVP的五大核心理念，请结合图形理解每个理念的定位与相互关系。

   💡 理解提示：五个理念并非独立存在，而是形成一个闭环——用户价值驱动决定功能取舍，最小可行功能保证快速交付，快速验证假设提供学习依据，迭代优化改进推动产品进化，最终实现降低产品风险。

3. 对比完整产品，识别关键差异

   MVP与完整产品的差异不仅体现在功能数量上，更体现在目标、策略和质量标准上。下表从6个核心维度进行对比：

   对比维度	MVP	完整产品
   核心目标	验证假设，获取学习反馈	全面满足用户需求，实现商业目标
   功能范围	仅包含验证核心假设所需的最少功能	包含完整功能集及增值服务
   用户群体	早期采纳者 / 种子用户	全部目标用户群体
   完成度	达到“可验证”的最小完成度	达到高可用、高可靠、高体验标准
   迭代策略	快速发布，小步快跑，持续优化	按版本计划发布，周期较长
   风险水平	低风险，允许快速试错和转向	高风险，需充分验证后才可大规模投入

4. 分析案例，验证概念理解

   案例：某团队计划开发一款“在线协作白板”产品。MVP版本只包含“画笔”“文字”“画布共享”三项功能，目标验证“远程团队是否能通过简易白板完成 brainstorming”。完整产品则需增加“模板库”“版本历史”“评论批注”“集成第三方工具”等能力。

   通过案例可以看出：MVP版本聚焦核心假设验证，完整产品聚焦全面用户体验。

5. 总结归纳，形成认知模型

   用自己的语言复述以下公式：

   MVP = 最小可行功能集 × 核心假设验证 × 真实用户反馈

   并能够向团队解释：MVP不是“做一半就交付”，而是“用最少的功能完成一次完整的学习循环”。

2.4 输入输出物

2.5 责任边界

2.6 记录材料

本章学习过程中需要留存以下记录，作为后续章节的引用基础：

1. MVP定义理解卡（包含：定义原文、个人复述、4个关键词的解释）
2. 核心理念对照表（理念名称 + 一句话描述 + 对自己项目的启发）
3. 差异分析工作单（MVP vs 完整产品，至少6个维度，含本章未提及的自选维度）
4. 案例学习笔记（记录案例中哪些功能属于MVP，哪些属于完整产品）

2.7 异常处理

处理流程：当团队出现上述任一误区时，立即暂停当前讨论，返回本章“操作步骤”第2步重新拆解核心理念，并使用对比表格校准认知。

2.8 验收标准

完成本章学习后，学员或团队必须通过以下五项验证，方可进入下一章：