2.3.3 MVP 的真正含义
现在让我们深入拆解 MVP 的三个关键词，建立更清晰的判断标准。
三个关键词深度解读
M = Minimum（最小）
| 错误理解 | 正确理解 |
|---|---|
| 功能数量最少 | 投入成本最少 |
| 砍掉「不重要」的功能 | 砍掉「不能验证假设」的功能 |
| 做一个「简陋版」 | 做一个「聚焦版」 |
关键洞见：「最小」的对象是你的投入（时间、精力、金钱），不是功能列表。
例子：
- Dropbox 的 MVP 是一个视频，投入最小
- 习惯打卡的 MVP 是一个按钮，投入最小
- 你的 MVP 应该是能验证假设的最小投入形式
V = Viable（可行）
| 错误理解 | 正确理解 |
|---|---|
| 能跑起来、不报错 | 能验证核心假设 |
| 技术上可行 | 商业/价值上可行 |
| 「它能工作」 | 「它能证明或否定我的假设」 |
关键洞见：「可行」不是技术概念，而是验证概念。
例子：
- 一个能完美运行但没人用的 App，不是「可行」的
- 一个有 bug 但能验证用户确实需要这个功能的原型，是「可行」的
- 判断标准不是「它跑得好不好」，而是「它能不能告诉我假设对不对」
P = Product（产品）
| 错误理解 | 正确理解 |
|---|---|
| 完整的软件/App | 能给用户价值的东西 |
| 必须是代码 | 可以是任何形式 |
| 必须能「发布」 | 只要能验证就行 |
关键洞见：「产品」可以是任何能交付价值的东西。
例子：
- 一个手绘的界面草图（验证用户是否理解你的设计）
- 一个 Excel 表格（验证你的数据分析逻辑是否有效）
- 一段人工执行的流程（验证这个流程是否真的能解决问题）
- 一个落地页（验证用户是否愿意注册）
MVP 的本质：一个实验
理解了这三个词，你会发现 MVP 的本质是：
用最小的投入，验证核心假设，交付最小的价值。
它不是一个「产品」，而是一个「实验」。
实验的目的是获取信息：
- 我的假设对吗？
- 用户真的需要这个吗？
- 这个方向值得继续投入吗？
核心假设的重要性
MVP 存在的意义是验证假设。那么，什么是核心假设？
核心假设是你做这件事的基本前提。如果这个假设不成立，整个项目就没有价值。
核心假设模板
我假设：
[某类用户] 存在 [某个问题/需求]，
他们愿意使用 [我的解决方案] 来 [完成某个任务]，
因为它比现有方案 [更快/更简单/更便宜/更有效]。示例
待办清单项目：
我假设：
职场人士存在「怕遗漏重要事项」的问题，
他们愿意使用一个极简待办工具来管理每日任务，
因为它比便签纸/手机备忘录更容易坚持使用。数据分析项目：
我假设：
销售团队存在「不知道哪个渠道效果好」的问题，
他们愿意看一份渠道 ROI 对比分析来做决策，
因为它比凭感觉判断更准确。自动化脚本项目：
我假设：
财务人员存在「每周手动汇总 Excel」的痛点，
他们愿意使用一个自动化脚本来完成这个任务，
因为它比手动操作更快且不易出错。验证标准：怎么知道假设成立了？
有了假设，还需要定义验证标准。否则你永远不知道假设是否成立。
验证标准模板
如果：
- [具体数量] 个用户
- 在 [具体时间段] 内
- 完成了 [具体行为]
则说明假设成立，值得继续投入。示例
待办清单项目：
如果：
- 5 个朋友
- 在 2 周内
- 每天都打开并添加/完成任务
则说明「极简待办」确实比便签纸更容易坚持。数据分析项目：
如果：
- 老板/销售主管
- 在看完报告后
- 根据分析结论做了决策
则说明这个分析确实有业务价值。常见误区
误区 1：功能多 = 用户满意
现实：用户满意度与功能数量没有正相关。
根据产品研究数据：
- 用户实际使用的功能通常不到产品总功能的 20%
- 功能越多，学习成本越高，放弃率越高
- 「少而精」的产品往往比「多而杂」的产品口碑更好
误区 2：先做完再验证
现实：越晚验证，纠错成本越高。
- 第 1 周发现方向错误：损失 1 周
- 第 12 周发现方向错误：损失 12 周
- 上线后发现方向错误：可能损失全部投入
误区 3：MVP 就是做得差一点
现实：MVP 是聚焦，不是敷衍。
- 错误：每个功能都做 60 分
- 正确：只做 3 个功能，每个做 90 分
本节要点
你现在对 MVP 应该有了更清晰的理解：
- Minimum：最小投入，不是最少功能
- Viable：能验证假设，不只是能运行
- Product：能交付价值，不限于软件形式
- MVP 是实验，核心任务是验证假设
- 必须有明确的假设和验证标准
接下来，我们学习具体的方法：如何从 20 个功能砍到 3 个。