MVP最小可行产品：先验证关键假设，再决定是否扩大范围
MVP 是足以帮助验证或反驳一个关键假设的早期最小版本。它的“最小”不由固定功能数或开发周期决定，而是由当前需要获得什么反馈证据决定；得到证据后，团队再决定是否调整、扩大或停止下一步探索。
- SAFe 术语表将 MVP 描述为足以证明或反驳某个假设的新解决方案的早期、最小版本。
- 最小范围应服务于当前需要获得的反馈证据，而不是被固定功能数量、周期或完成度替代。
- 完整产品开发治理、跨职能阶段协同和资源决策属于 IPD 等更宽的管理任务，不能由 MVP 概念页取代。
MVP 的核心是验证，不是压缩一切
MVP 先把待验证的关键假设说清楚，再选择刚好足以获得相关反馈的范围。反馈并不自动代表市场成功；它只是下一次讨论范围、假设和取舍时需要核对的证据之一。
它关注什么
关注关键假设、最小验证范围、反馈证据和后续迭代判断之间是否能被清楚地区分。
它不等于什么
不等于功能清单、完整原型、上线承诺、固定开发周期、预算方案、市场预测或产品成功保证。
用五个要素理解 MVP
关键假设
先表述希望理解或验证的假设，避免把“做一个 MVP”写成没有问题定义的功能任务。
最小验证范围
选择能够支持当前验证的最少能力或材料；范围随假设和证据变化，而不按通用功能数套用。
反馈证据
事先说明需要观察、讨论或核对什么反馈，并将已知事实与待验证假设区分开。
下一步取舍
根据反馈决定继续探索、修改假设、调整范围或回到更完整的产品开发流程讨论；概念页不代替实际决策。
与 IPD 的边界
IPD 可承担产品机会、需求、跨职能团队、阶段评审、资源决策和开发复盘等全链路治理；MVP 只解释一个验证任务。
开始验证前先核对什么
假设是否可说清
先说明希望理解的需求、问题或价值假设，避免先讨论实现方案而没有可验证的问题。
范围是否只服务于验证
确认每一项范围都与当前反馈需求有关；不能据此推断最终产品必须具备什么。
反馈是否有责任边界
区分谁提供反馈、哪些材料可用、哪些结论仍须由产品、技术、合规或经营责任方核对。
把概念转成待核验的验证任务
写出待验证的假设
用清晰语言记录当前希望理解什么，不将猜测写成用户、市场或经营事实。
确定最小验证范围
选择足以形成反馈对话的能力或材料，并记录暂不纳入的范围。
约定反馈与证据
说明需要收集什么反馈、由谁复核，以及哪些信息仍是不确定的。
回看假设与范围
基于可获得的反馈讨论是否修正假设或扩大探索，不把反馈直接等同于产品成功。
转入相应 Owner
完整 IPD 开发问题进入 IPD 主题页；明确课程或岗位训练需求进入相邻课程或产品经理训练页；实际立项和技术经营决定进入组织流程。
哪些情境适合先看这页
团队要统一 MVP 的讨论口径
适合在产品探索、课程学习或跨职能沟通前，先把假设、范围与反馈的概念分开。
学习负责人需要选择资源
适合区分产品验证方法、完整 IPD 开发治理、明确课程选择和产品经理岗位训练。
范围持续扩大但问题未清
适合提醒团队先回到待验证假设与反馈需要，而不是在概念页中给出产品方案。
理解 MVP 时的常见误区
把 MVP 等同于少做功能
少做功能不是目的。若不能帮助验证当前假设，即使范围很小也不一定是有价值的 MVP。
把反馈直接当作市场结论
反馈需要结合来源、情境和后续复核理解，不能被这里转换为增长、收入或成功承诺。
用 MVP 跳过完整治理
MVP 概念不替代产品立项、技术设计、数据、质量、安全、合规、知识产权或经营决策流程。
常见问题
MVP 是不是功能越少越好？
不是。MVP 的范围应足以支持当前假设的验证；是否更少取决于能否获得需要的反馈，而不是追求一个固定功能数量。
MVP 和原型有什么区别？
两者都可能用于探索，但这里只说明 MVP 的假设与反馈验证角色。具体原型形式、技术实现或交付方案需由实际团队和流程确认。
做了 MVP 就代表产品可以上线吗？
不代表。MVP 不替代完整上线准备、技术设计、质量安全、数据、合规或经营审批，反馈也不等同于上线结论。
MVP 与 IPD 管理会重复吗？
不会。MVP 解释一次受限范围的假设验证；IPD 主题页 承接产品机会、需求、跨职能协同、阶段评审和开发复盘等更完整的治理任务。
延伸学习路径
如果要把这个知识点用于组织学习或岗位能力建设，可以继续查看以下学习路径，按阶段理解主题、应用材料和成果要求。
