第1章 MVP核心定义与本质：最小可行产品、核心假设、差异化原则
本章为全课程奠定概念根基。在资源受限的真实环境中，团队必须在启动完整开发前，用最低成本验证产品方向是否成立。本章围绕最小可行产品、核心假设与差异化原则三个支柱，建立统一的定义框架与决策语言，使后续评估方法与迭代策略有据可依。
1.1 适用场景
以下场景中，团队必须首先对齐MVP定义与本质，否则后续评估与迭代将缺乏统一基准：
- 新产品立项：从零开始构建产品时，需要确定第一版发布的最小功能边界。
- 业务方向转型：现有产品面临增长瓶颈或市场变化，需验证新假设。
- 资源严重受限：人力、资金或时间窗口不足，必须做减法以加速验证。
- 内部孵化/创新项目：需要快速向决策层证明概念可行性。
- 竞品压力下紧急响应：在对手抢先发布前，用MVP抢占认知先机。
1.2 前置条件
- 团队已明确产品的愿景与战略目标（至少有一页愿景文档或电梯演讲）。
- 已收集至少一份用户初步洞察（访谈记录、问卷摘要或二手研究报告）。
- 项目发起人理解MVP不等于粗糙版本，接受分阶段交付的节奏。
- 产品经理具备假设拆分与优先级排序的基本能力。
1.3 操作步骤
- 提取核心假设清单
从愿景文档与用户洞察中，列出所有不确定的断言。按“用户—问题—方案—价值”四层归类，为每个假设标注置信度（低/中/高）。 - 应用差异化原则筛选MVP功能
对每个潜在功能，依次问三个问题：① 是否直接验证高优先级假设？② 去掉是否导致验证失败？③ 是否存在更轻量的替代方式？
只有三问都指向“必须保留”的功能才进入MVP范围。 - 定义最小可行产品边界
根据筛选结果编写MVP定义文档，明确包含功能、不包含功能、成功标准（验证指标）与放弃条件。
💡 操作要点：步骤2是核心决策环节。团队应使用“假设验证优先级矩阵”对功能进行打分，避免凭直觉或权力博弈决定范围。
1.4 输入与输出
| 类型 | 名称 | 说明 | 格式/载体 |
|---|---|---|---|
| 输入 | 产品愿景文档 | 目标用户、核心价值、差异化定位 | PDF / 协作页面 |
| 输入 | 用户洞察摘要 | 至少 5 份用户访谈或问卷分析 | 结构化文档 |
| 输入 | 竞品边界分析 | 关键竞品功能与市场反馈对比 | 表格 / 看板 |
| 输出 | MVP定义文档 | 功能列表、验证指标、放弃条件 | Markdown / Confluence |
| 输出 | 核心假设清单 | 所有假设及置信度评级 | 电子表格 |
| 输出 | 差异化原则检查表 | 用于拦截非必要功能的快速校验工具 | 单页清单 |
1.5 责任边界
- 产品经理：主导假设提取与MVP定义，负责编写文档并组织评审。
- 技术负责人：评估MVP功能的技术可行性与实现成本，参与减法决策。
- 设计负责人：确保MVP交互闭环可用，但不过度雕琢视觉细节。
- 项目发起人/决策层：审批MVP定义文档，承诺在验证周期内不随意增减范围。
- 所有成员：遵守“假设驱动”决策文化，避免在MVP阶段加入“锦上添花”功能。
⚠️ 关键提醒：产品经理是MVP定义的第一责任人，必须对“哪些功能不做”保留最终解释权；技术与设计角色提供输入，但不替代产品决策。
1.6 记录材料
- 核心假设清单（电子表格）：包含假设描述、置信度、验证方法、预期指标。
- MVP功能看板（Jira / Trello / 飞书）：区分“包含”“不包含”“待定”三列，每项标注关联假设ID。
- 评审会议纪要：记录每次MVP边界讨论的关键论点与决议。
- 差异化原则检查表（物理或数字卡片）：团队在冲刺规划时逐项核对，防止范围蔓延。
1.7 异常处理
| 异常情形 | 可能原因 | 处理方式 |
|---|---|---|
| 团队无法就“最小”范围达成一致 | 缺少统一的假设优先级排序标准 | 立即引入“验证影响 vs 实现成本”四象限打分法，重新排序假设 |
| 决策层反复要求增加功能 | 对MVP策略理解不足，担心产品“太简陋” | 用本章SVG框架图对齐认知，重申“假设验证优先于功能完整” |
| 用户洞察过于模糊，无法提炼假设 | 原始调研深度不够或样本偏差 | 暂停定义，补做 3-5 轮定向用户访谈，聚焦“痛点场景” |
| 竞品已发布类似功能，团队焦虑 | 外部压力导致失去减法定力 | 回归核心假设，确认自身差异化切入点；MVP只需验证假设，不需覆盖所有竞品功能 |
1.8 验收标准
完成本章学习与实践后，团队或学员应能通过以下检查项验证是否掌握了MVP核心定义与本质：
- ✅ 能从产品愿景中提取至少 3 条可验证的核心假设，并按置信度排序。
- ✅ 能使用差异化原则（聚焦关键、减法优先、验证驱动）筛选出 MVP 功能集。
- ✅ 能独立编写一份 MVP 定义文档，包含功能边界、成功指标与放弃条件。
- ✅ 能向利益相关者清晰解释“MVP ≠ 半成品”，并引用本章框架图辅助说明。
- ✅ 能识别团队中常见的 MVP 范围蔓延信号，并按照异常处理表采取纠正措施。