第 3 课：MVP 思维与减法原则
模块一：产品思维基础 | 第 3 课
课前思考
小李想清楚了他的极简待办清单：目标用户是像他自己一样的职场人，痛点是便签纸容易丢，优势是极致简单。
然后他打开 AI 工具，输入："我要做一个帮职场人士不遗漏重要事情的待办清单。需要这些功能：添加任务、完成任务、查看任务、任务分类、优先级标签、截止日期提醒、重复任务、子任务拆解、团队协作、数据统计……"
他列了 14 个功能。三个月后，项目又一次搁浅了。
问题出在哪？不是方向错了，而是他想一次性做完所有事。
MVP 是什么：重新理解三个字母
很多人听说过 MVP 这个词，但普遍存在理解偏差。最常见的错误理解是：
MVP = 功能最少的版本
这是完全错误的。 按照这个理解，你会把 14 个功能砍到 7 个，然后说"这是我的 MVP"。大错特错。
MVP 不是"功能最少"，而是能验证核心假设的最小投入。让我们拆开三个字母重新理解：
M = Minimum（最小）
| 错误理解 | 正确理解 |
|---|---|
| 功能数量最少 | 投入成本（时间、精力、金钱）最少 |
| 砍掉"不重要"的功能 | 砍掉"不能验证假设"的功能 |
| 做一个"简陋版" | 做一个"聚焦版" |
核心洞见："最小"的对象是你的投入，不是功能列表。
V = Viable（可行）
| 错误理解 | 正确理解 |
|---|---|
| 技术上能跑起来、不报错 | 能验证核心假设是对还是错 |
| "它能工作" | "它能证明或否定我的判断" |
核心洞见："可行"不是技术概念，而是验证概念。一个能完美运行但没人用的 App，不是 MVP，是垃圾。一个有 bug 但能验证用户确实需要这个功能的原型，是好 MVP。
P = Product（产品）
| 错误理解 | 正确理解 |
|---|---|
| 完整的软件/App | 能给用户交付价值的东西 |
| 必须是代码 | 可以是任何形式 |
| 必须能"发布" | 只要能验证就行 |
核心洞见："产品"可以是任何能交付价值的东西。Dropbox 的 MVP 是一个 3 分钟演示视频。某外卖平台的 MVP 是一个微信群人工接单。一个手绘界面草图可以是 MVP。一个 Excel 表格可以是 MVP。一段人工执行的流程可以是 MVP。
MVP 的本质：一个实验
综合起来，MVP 的本质是：
用最小的投入，验证核心假设，交付最小的价值。
它不是一个"产品"，而是一个"实验"。实验的目的是获取信息——我的判断对吗？用户真的需要吗？这个方向值得继续投入吗？
如何定义你的核心假设
MVP 的目的是验证假设。所以，在做 MVP 之前，你必须先定义清楚核心假设：
我假设：
[某类用户] 存在 [某个问题]，
他们愿意使用 [我的解决方案] 来 [完成某个任务]，
因为它比现有方案 [更快/更简单/更便宜/更有效]。举个例子——小李的待办清单：
我假设：
28 岁的职场人小李们存在"怕遗漏重要事项"的问题，
他们愿意使用一个极简待办工具来管理每日任务，
因为它比便签纸更容易回顾和坚持使用。如果你的核心假设被验证是错的，整个项目就没有继续投入的价值。这就是为什么要先验证假设——在投入大量时间之前，用最小的成本确认方向没错。
砍功能的方法：三个灵魂问题
假设你现在手上有 14 个想做的功能。怎么砍到 3-5 个？问每一个功能三个问题：
问题一：没有这个功能，产品还能用吗？
| 功能 | 没有它能用吗？ | 结论 |
|---|---|---|
| 添加任务 | 不能 | 核心功能 |
| 完成任务 | 不能 | 核心功能 |
| 查看任务列表 | 不能 | 核心功能 |
| 任务分类 | 能（先不分类也行） | 非核心 |
| 暗黑模式 | 能（不影响使用） | 非核心 |
| 统计报表 | 能（知道完成了就行） | 非核心 |
问题二：这个功能能验证我的核心假设吗？
假设你的核心假设是"极简待办比便签纸更容易坚持使用"：
| 功能 | 能验证假设吗？ | 理由 |
|---|---|---|
| 一键添加任务 | 能 | 测试"极简"是否真的更容易用 |
| 打卡日历 | 不确定 | 可能有用，但不是验证"极简"的关键 |
| 社交分享 | 不能 | 这是增长功能，不是验证功能 |
问题三：用户第一次使用就需要这个功能吗？
- 第一次使用就需要 → P0（必须立即做）
- 用了一段时间才需要 → P1（下个版本做）
- 锦上添花 → P2（有时间再说）
核心原则：新用户只关心"这个东西能帮我做什么"，不关心"这个产品以后会有多强大"。MVP 阶段聚焦于让用户进来并体验到核心价值。排行榜、成就系统、社交功能是让用户"留下来"的，不是让用户"进来"的。
P0/P1/P2 优先级框架
把三个问题的结果汇总：
| 优先级 | 定义 | 行动 | 示例 |
|---|---|---|---|
| P0 | 没有就无法验证核心价值 | MVP 必须包含 | 添加任务、勾选完成 |
| P1 | 重要但可以后续迭代 | V2 再做 | 任务分类、提醒 |
| P2 | 锦上添花 | 有时间再说 | 暗黑模式、统计分析 |
铁律：P0 功能不超过 5 个。 如果超出了，说明你还没想清楚核心价值是什么。继续砍。
不做清单：比要做清单更重要
大多数人只列"要做清单"，很少有人列"不做清单"。但不做清单可能比要做清单更重要。
为什么你需要不做清单
1. 明确边界。 当你告诉 AI "帮我做一个待办清单"，AI 可能会问：要不要加日历同步？要不要支持团队协作？如果你没有明确边界，很容易被这些问题带偏。
2. 抵抗诱惑。 做项目的过程中，你会不断产生新想法："如果加一个 XX 功能会不会更好？""竞品都有 XX，我是不是也该有？"不做清单是你的防线——这些功能我已经想过了，决定不做，理由在这里。
3. 专业化沟通。 当别人问"为什么没做 XX 功能"时，你可以说："这个功能在我的不做清单里，原因是 X。我会在条件 Y 满足时重新考虑。"这比"还没来得及做"专业得多。
不做清单模板
# 不做清单（V1 版本）
## 不做的功能
| 功能 | 不做的理由 | 何时重新考虑 |
|------|-----------|-------------|
| 多设备同步 | 需要后端，大幅增加复杂度 | 核心功能验证成功后 |
| 团队协作 | 不是个人工具的核心价值 | 有明确团队需求时 |
| 统计报表 | 对验证"极简好用"没有帮助 | 用户留存稳定后 |
## 不考虑的用户群
| 用户群 | 不考虑的理由 |
|--------|-------------|
| 大型企业团队 | 需求复杂，与个人工具定位不符 |
## 不追求的指标
| 指标 | 不追求的理由 | 替代关注点 |
|------|-------------|-----------|
| 日活用户数 | MVP阶段验证价值更重要 | 核心功能使用频率 |当你能清晰地说出"不做什么"时，你对"要做什么"的理解才真正到位。
AI 时代的 MVP：更快、更便宜、更多形态
AI 极大降低了 MVP 的构建成本。过去的 MVP 可能还是需要一个工程师花一两周写代码，现在你可能只需要和 AI 对话几轮就能产出一个可用的原型。
不同场景下的 MVP 形式参考：
| 项目类型 | MVP 形式 | 验证目标 |
|---|---|---|
| 软件应用 | AI 生成单功能页面 | 用户是否愿意使用 |
| 数据分析 | 手工制作的图表 | 决策者是否觉得有用 |
| 自动化 | 手动执行的流程 | 流程是否解决问题 |
| 服务产品 | 人工模拟的服务 | 用户是否愿意付费 |
| 内容产品 | 一篇测试文章 | 用户是否愿意分享 |
不管什么形式，问同一个问题：这个假设能不能用更简单的方式验证？
本课实践
用你现在正在思考的产品想法，完成以下三项练习：
- 写出核心假设。 用假设模板完整写出来。
- 列出 P0/P1/P2。 把你所有想做的功能按优先级分类，P0 不超过 5 个。
- 写不做清单。 列出至少 5 个明确不做的功能，并给出不做的理由。
如果发现 P0 超过 5 个或者不做清单写不出来——回去重新审视你的核心假设。
下一步
MVP 思维告诉你"做什么"和"不做什么"。但你还不知道用户是否真的需要。这就需要下一课的核心技能——用户访谈，学会与真实用户对话，从他们口中获取真实的反馈。