Trade-offs: How Great PMs Decide What Not to Build

微信扫一扫，分享给好友

关闭

Lenny's Newsletter的一篇文章指出：衡量产品经理水平的，不是他们做成了多少功能，而是他们拒绝了多少需求。取舍（trade-off）才是产品工作的核心。

为什么取舍这么难

难在信息不完整。你永远无法100%确定哪个需求更重要，所以每个取舍都伴随着风险和辩论。难在利益冲突。销售要签单功能，老板要战略布局，用户要免费功能，每一方都有道理。

三个实战取舍框架

框架一：反事实测试

问一个尖锐的问题：如果我们不做这个功能，六个月后会发生什么？如果答案是「没什么大不了」，那它就不值得做。这个测试能快速过滤掉大部分「锦上添花」型需求。

框架二：不可逆性分级

把决策分为可逆和不可逆两类。可逆决策（如改一个按钮文案）快速做、小步试；不可逆决策（如更换技术架构、砍掉产品线）慢下来、充分辩论。多数团队的问题是用同一种节奏对待两类决策。

框架三：机会成本显性化

每接受一个需求，就明确写出它的机会成本：「做A意味着B延后一个月」。让所有需求方看到取舍的真实代价，很多「高优先级」会自动降级。

说不的艺术

直接说「不」往往会激化矛盾。文中给出的技巧是：用「什么条件下会做」替代「不做」。比如「这个需求很有价值，但当转化率提升类需求的ROI高于它时，我们暂时不会排期」——这把对抗变成了透明的规则讨论。

写给团队的建议

• 把「我们不做的事」写进公开文档，减少重复辩论
• 每次取舍决策留档，包括当时的依据，便于复盘
• 定期回顾被拒绝的需求，检验判断是否准确

结语

产品经理的稀缺资源从来不是开发人力，而是团队注意力和战略聚焦。学会体面而坚定地说不，是每个PM的必修课。

---

> 本文由 GPMU 编译自 Lenny's Newsletter，原文链接：https://www.lennysnewsletter.com。编译内容已获改编，转载请注明出处。