2.3.2 真实案例对比
让我们通过几个真实案例，看看「功能堆砌」和「减法思维」的区别。
反面案例：14 功能待办清单的失败
项目背景
小李想做一个待办清单工具，帮助自己管理工作事项。
他的第一版规划包含以下功能：
- 任务分类
- 优先级标签
- 截止日期提醒
- 重复任务
- 子任务拆解
- 标签系统
- 日历视图
- 看板视图
- 统计报表
- 多设备同步
- 团队协作
- 评论功能
- 暗黑模式
- 桌面小组件
发生了什么
- 第 1 周：搭建项目框架，实现了基础的添加任务功能
- 第 2-4 周：开始做任务分类和标签，遇到数据结构问题，反复修改
- 第 5-8 周：日历视图和看板视图开发，UI 调整花了大量时间
- 第 9-12 周：多设备同步需要后端，学习后端知识，进度缓慢
- 第 12 周后：心态崩溃，项目搁置
结果
- 断断续续做了 3 个月，功能还没完成一半
- 每个功能都是半成品，充满 bug
- 自己试用后发现：「这比我现在用的便签纸还麻烦」
- 项目放弃
问题分析
| 问题 | 具体表现 |
|---|---|
| 没有核心假设 | 不知道在验证什么，只是在「做功能」 |
| 功能太多 | 14 个功能分散了精力，没有一个做好 |
| 没有验证节点 | 3 个月后才发现方向可能有问题 |
| 完美主义 | 每个功能都想做到完美，反而什么都没完成 |
正面案例：「只需一个按钮」的习惯打卡
项目背景
另一个人想做一个习惯养成工具。
她的核心假设是：人们坚持不了习惯，是因为记录太麻烦。如果记录只需要点一下按钮，坚持率会提高。
她的 MVP
只有三个元素：
- 一个习惯名称（比如「喝水」）
- 一个大按钮（点击 = 今天完成了）
- 一个连续天数显示
没有统计图表，没有提醒功能，没有社交分享，没有成就系统。
发生了什么
- 第 1 天：用 AI 生成了这个简单页面
- 第 2-7 天：自己试用，发现确实比之前用的 App 更容易坚持
- 第 2 周：发给 5 个朋友试用，收到反馈
- 第 3 周：根据反馈加了「多个习惯」功能
- 第 4 周：加了简单的周统计
结果
- 1 个月内验证了核心假设：「简单确实能提高坚持率」
- 收集了真实用户反馈，知道下一步该做什么
- 项目持续迭代，现在有 50 多个朋友在用
更多场景的案例对比
数据分析场景
| 方面 | 失败做法 | 成功做法 |
|---|---|---|
| 目标 | 做一份「全面」的销售分析报告 | 回答老板的一个问题：「哪个渠道 ROI 最高？」 |
| 内容 | 50 个图表，覆盖所有指标 | 1 张对比图 + 3 句结论 |
| 时间 | 花了 2 周，老板没时间看完 | 花了 2 小时，老板当天就做了决策 |
| 价值 | 「辛苦了，放这儿吧」 | 「这个分析很有用，下次再做一个 XX」 |
自动化脚本场景
| 方面 | 失败做法 | 成功做法 |
|---|---|---|
| 目标 | 做一个「万能」Excel 处理工具 | 自动化「每周五汇总 5 个部门数据」这一件事 |
| 功能 | 支持各种格式、各种操作 | 只做这一个特定任务 |
| 时间 | 做了 1 个月，还在加功能 | 2 小时搞定，每周省 3 小时 |
| 维护 | 代码复杂，改一个地方坏另一个 | 代码简单，自己能维护 |
给家人做工具场景
| 方面 | 失败做法 | 成功做法 |
|---|---|---|
| 目标 | 给爸妈做一个「完美」的吃药提醒 App | 让爸妈不忘吃药 |
| 设计 | 精美 UI、多种提醒方式、用药记录 | 大字、一个「吃了」按钮 |
| 结果 | 爸妈觉得太复杂，不愿意用 | 爸妈每天都在用 |
| 关键差异 | 按自己的审美设计 | 按爸妈的使用能力设计 |
失败项目 vs 成功项目的特征对比
| 特征 | 失败项目 | 成功项目 |
|---|---|---|
| 核心假设 | 模糊或没有 | 清晰明确 |
| 功能数量 | 越多越好 | 只做必须的 |
| 验证周期 | 很长，甚至没有 | 很短，快速迭代 |
| 成功标准 | 「功能都做完了」 | 「假设被验证了」 |
| 用户参与 | 做完再给用户看 | 尽早让用户参与 |
| 对待反馈 | 防御性：「他们不懂」 | 开放性：「他们的反馈很有价值」 |
本节要点
通过这些案例，你应该能看出区别：
- 失败项目往往死于「功能太多」，而不是「功能太少」
- 成功项目的共同点是「聚焦」和「快速验证」
- 减法思维的核心是：先验证假设，再考虑扩展
接下来，我们深入拆解 MVP 的三个关键词，帮你建立更清晰的判断标准。