Escaping the Build Trap
团队拼命发功能却越做越差——因为公司在用「发了多少」而非「解决了什么」计分，佩里说这是组织病，不是产品经理不够努力。
- 产出陷阱：公司把「发布数量」当真相，员工被迫用假指标自证进步
- 战略不是计划：是让团队自主决策的框架，越详细的路线图越像地雷
- MVP 真正的意思：最小学习成本，不是「先发个烂版本」
核心观点
01
组织把「发了多少功能」当价值替身，是因为没人愿意承认不懂客户
当公司说不清用户的真实问题时，会发明一个容易量化的指标顶替——发布数量、迭代速度。这个替身一旦被绩效和奖金绑定，全公司都会忘记它只是替身。
不理解客户问题→发明可量化替身：功能数→指标绑定绩效→全员追替身，忘了原问题
02
产品经理不是「产品的 CEO」：他们拥有为什么，不拥有做什么
把产品经理当独裁者会制造对立团队。真正的角色是带着「为什么值得做」的判断进入协作，具体做什么由整个团队一起决定。
✕ Don't
- 产品经理一人拍板功能清单
- 工程师只负责按需求写代码
✓ Do
- 产品经理讲清楚要解决的问题
- 团队一起决定用什么方式解决
03
MVP 不是「最小可行产品」，是「最小学习成本」
大多数团队把 MVP 理解成「先发一个粗糙版本」。佩里的定义完全不同：花最少的力气，搞清楚这件事到底该不该做。目的是学习，不是抢发。
| 理解方式 | 常见误读 | 佩里的定义 |
|---|---|---|
| MVP 的目的 | 尽快上线抢占市场 | 用最低成本验证该不该做 |
| 失败的意义 | 证明团队执行力不足 | 证明省下了后面更大的浪费 |
| 「Version 2」 | 早晚会补上 | 大多数团队发完 V1 就再也不回头 |
免费部分到这里。墙内还有：
剩余 2 条核心观点 · 本书与另外 4 本书的观点交锋 · 应用篇
金句摘录
「组织陷入了用产出而非结果衡量成功的怪圈。」
「好战略不是详细计划，是帮你做决策的框架。」
「MVP 是花最少的力气去学习，不是发一个凑合的产品。」
常见问题
这本书讲了什么？
团队拼命发功能却越做越差——因为公司在用「发了多少」而非「解决了什么」计分，佩里说这是组织病，不是产品经理不够努力。
适合谁读？
从核心观点看，适合想搞清楚「组织把「发了多少功能」当价值替身，是因为没人愿意承认不懂客户」这类问题的人。
最核心的一个观点是什么？
组织把「发了多少功能」当价值替身，是因为没人愿意承认不懂客户