核心问题

如何判断一个功能是否值得承担工程代价？

真实场景

一个客户提出定制需求。销售很急，PM 也觉得不能丢单。但工程师说这会破坏现有模型，需要重构权限系统。

这时不能只问“能不能做”，要问“值不值得做”。

常见误区

坏判断是：

客户要，所以就必须做。

客户需求重要，但不是每个客户需求都值得改造核心系统。

工程视角

工程代价需要被业务价值覆盖：

  • 能带来多少收入？
  • 影响多少用户？
  • 是否支持战略方向？
  • 是否减少长期运营成本？
  • 是否会污染通用产品能力？
  • 是否只是一次性定制？

PM 可以怎么做

PM 要把价值说具体：

  • 不是“很重要”，而是“影响多少收入/留存/效率”。
  • 不是“客户需要”，而是“这个需求是否可产品化”。
  • 不是“尽快做”，而是“为什么值得插队”。

Atlas Action

在需求评审中加入一句：

这个需求值得我们承担哪些工程代价？

如果说不出代价，就还没真正判断价值。

小结

商业价值不是情绪强度，而是能否合理覆盖工程成本。

PM 要让“重要”变得可讨论。