2.3.1 重新定义 MVP
一个熟悉的场景
还记得第一节里的小李吗？他在学习了「任务视角」后，重新审视了自己的待办清单项目。
这次，他明确了核心任务：帮助职场人士不遗漏重要的事情。
然后他又犯了另一个错误。
他打开 AI 工具，输入：
"我要做一个帮职场人士不遗漏事情的待办清单。需要这些功能：添加任务、完成任务、查看任务、任务分类、优先级标签、截止日期提醒、重复任务、子任务拆解……"
他列了 14 个功能。
三个月后，项目又一次搁浅了。
问题出在哪？
小李这次已经想清楚了「要解决什么问题」，但他陷入了另一个陷阱：功能堆砌。
他把「解决问题可能需要的所有功能」都列了出来，然后试图一次性全部实现。
这是一个非常常见的错误。
传统 MVP 的误区
你可能听说过 MVP 这个词。很多人对它的理解是：
MVP = 功能数量最少的版本
按照这个理解，小李可能会这样想：
- 原来计划 14 个功能，那我砍到 7 个，这就是 MVP 了吧？
这是错的。
MVP 不是「功能最少」，而是「能验证核心假设的最小投入」。
MVP 的正确定义
MVP 的三个字母分别代表：
| 字母 | 单词 | 错误理解 | 正确理解 |
|---|---|---|---|
| M | Minimum（最小） | 功能数量最少 | 投入成本最少 |
| V | Viable（可行） | 能跑起来 | 能验证假设 |
| P | Product（产品） | 完整的软件 | 能给用户价值的东西 |
关键洞见：MVP 是一个实验，不是一个产品。
它的目的不是「做一个完整的东西」，而是「用最小的投入，验证你的核心假设是否成立」。
一个经典案例：Dropbox
2007 年，Drew Houston 想做一个云端文件同步工具。
他面临一个问题：这个产品需要大量开发工作，但他不确定用户是否真的需要它。
他的解决方案：不写一行代码，先做一个 3 分钟的演示视频。
视频展示了「文件自动同步到云端」的效果（其实是假的），然后放到网上。
结果：一夜之间，等待名单从 5,000 人涨到 75,000 人。
这个视频就是 Dropbox 的 MVP。它验证了核心假设：「人们确实需要一个简单的文件同步工具」。
这对你意味着什么
在开始动手之前，问自己一个问题：
我的核心假设是什么？用什么最小的方式可以验证它？
对于小李的待办清单项目：
- 核心假设：职场人士愿意用一个极简工具来管理每日待办，而不是用便签纸或手机备忘录
- 最小验证方式：一个只有「添加-完成-查看」三个功能的页面
如果这三个功能都留不住用户，加再多功能也没用。
如果这三个功能能留住用户，说明假设成立，可以继续迭代。
多场景应用
减法思维不只适用于「做产品」：
| 场景 | 核心假设示例 | MVP 形式 |
|---|---|---|
| 数据分析报告 | 老板最关心的是销售转化率 | 先做一张转化率趋势图，看老板反馈 |
| 自动化脚本 | Excel 汇总是最耗时的重复工作 | 先自动化一个部门的汇总，验证效果 |
| 给爸妈做吃药提醒 | 他们能看懂大字和简单按钮 | 一个只有「吃了」按钮的页面 |
本节要点
你现在已经理解了 MVP 的真正含义：
- MVP 是实验，不是产品
- 它的目的是验证假设，不是取悦用户
- 「最小」指的是投入成本，不是功能数量
接下来，我们通过真实案例，看看「做减法」和「堆功能」的项目有什么不同。