产品 leader 的需求池与需求排期

从产品 leader 的角度，聊一聊比单纯的产品设计/运营更深一个 level 的事情。

有次我接到一个老板需求，我评估优先级是 7 分。老板催得急，我两把就把设计运营方案定了下来，但这个功能和某个子系统的耦合度非常深，牵扯千丝万缕，研发成本比较高。

于是我拆成了一期和二期，一期先上线跑通流程，很多必要的体验留到二期去优化。

一期很快上线，数据符合预期，老板满意，我也发现了一些之前遗漏的细节，打包在二期去修复。但这时老板开始关注别的需求，研发也会优先做老板需求，二期排不上期。

排不上期有什么损失呢？数据上没有大的损失，但某些高渗透率的交互体验比较糟糕。原本一期只是跑通流程，快速验证设计方向是没问题的，二期再紧跟着优化体验。结果老板注意力转移了——他又不用这个功能，感知不到体验缺陷。

这时就很尴尬。老板注意力不在这里，排不上期，你现在跟他讲也没用，他听不进去。但哪一天他自己偶然用到这个功能，产品部门肯定要背锅。

这就是产品部门埋下的一颗雷。

还好，直到我离职，雷也没爆。以后即便爆了，前同事也可以往我身上推锅。

类似的情况极多，对于产品 leader 来说，需求池的规划排期并不仅仅是 “哄老板开心”。如果处理不好，不仅代码是屎山，产品细节也是屎山。

这颗雷的优先级，在我的评估里是 6 分，毕竟是高渗透率的体验损失；而老板关注的很多琐碎需求，优先级仅仅是 4 分，是一系列低渗透率（但老板在意）的功能。琐碎归琐碎，在老旧的技术架构下，一个个解决的研发成本可不低。

在我的需求池里，6789 优先级的需求排得满满当当，以至于 6 分的需求根本插不进去。研发资源一直极度紧张，全靠我统筹腾挪。7+ 的高优先级的需求里：

• 很多本身就是老板需求
• 很多是不做就要出事的高风险需求
• 很多是其他部门拼了命也要挤进来的需求（否则就找老板投诉）
• 还有我自己冲业绩的需求——做不出业绩我迟早完蛋

这时，优先级 7+ 需求有清晰的排序逻辑，但老板的 4 分需求与雷区的 6 分需求怎样权衡，就很伤脑筋。

即便满足老板的一切需求，爆雷的时候会炸伤我，其他部门会弄死我，出不了业绩也会麻溜地滚蛋。

但不满足老板需求呢，老板又对我不满意。

所以，我通常会尽量压住老板的 4 分需求（逼急了再做），优先做 7+ 需求，承受一部分老板的不满意，也承受 6 分需求爆雷的风险。而不是很多职场八股文所说的以老板为中心。

即便是老板需求，我也要划分权重，积极执行高优先级，消极执行低优先级，并不是拼命舔老板这么简单。再说我也不愿意给技术压力，压榨程序员的加班时间，而是我来承担压力，统筹腾挪全局需求。

如果老板要什么给什么，我管理的产品运营部门还好（因为效率超高），研发部门就要常态 996 了。我觉得该拼的时候就得拼，但不至于为了哄老板开心的 4-6 分需求，逼着程序员 996。

所以研发部门一直都很喜欢我。

至于老板喜不喜欢我，取决于他眼里我有什么重大贡献。比如产品与运营部门的高效率运转算不算贡献？重大新业务的高质量探索算不算贡献？实际上，如果业绩过硬，我在公司里能横着走。只可惜低增长时代已经找不到高增长机遇。