老板有一个功能需求提到我这里，非常合理，我完成设计后提给技术，技术回复说这个功能和其他功能的耦合比较深，牵扯很广，开发成本其实不低，更没法 MVP。
我和技术商量下来，性价比最高的方案，是等到某个系统重构的时候，把老板需求打包进去，一口气完成一系列需求。
我这么回复，老板肯定不舒服，但也不好说什么。毕竟这个功能合理但优先级不高，每个月排期了（他认可的）更重要的任务，研发资源紧张也是公认的事实。我也告知了他，大概在什么时间段重构这个系统。
后来我走了，还没来得及重构。继任者飞几把快地把老板需求落地。我大吃一惊，问技术，你当时可不是这么跟我说的？
技术说，继任者用的不是我们商量好的合理化方案，而是一套过渡方案。过渡方案也能实现老板需求，但重构系统时无法复用，得整个推翻重做，浪费了两周的工作量。他死催死催，我也就只能这么做了。
现在大家可能更理解什么叫向上管理了。
这件事发在微博，很多人评论说，哄老板开心也很重要啊。如果老板不信任不支持你，怎么去做更有价值的事情呢？
我叹了口气，接着聊比单纯的产品设计/运营更深一个 level 的事情。
有次我接到一个老板需求，我评估优先级是 7 分。老板催得急，我两把就把设计运营方案定了下来，但这个功能和某个子系统的耦合度非常深，牵扯千丝万缕，研发成本比较高。
于是我拆成了一期和二期，一期先上线跑通流程，很多必要的体验留到二期去优化。
一期很快上线，数据符合预期，老板也很满意，我也发现了一些之前遗漏的细节，打包在二期去修复。但这时老板开始关注别的需求，研发也会优先做老板需求，二期排不上期。
排不上期有什么损失呢？数据上没有大的损失，但某些高渗透率的交互体验比较糟糕。原本一期只是跑通流程，快速验证设计方向是没问题的，二期再紧跟着优化体验。结果老板注意力转移了——他又不用这个功能，感知不到体验缺陷。
这时就很尴尬。老板注意力不在这里，排不上期，你现在跟他讲也没用，他听不进去。但哪一天他自己偶然用到这个功能，产品部门肯定要背锅。
这就是产品部门埋下的一颗雷。
还好，直到我离职，雷也没爆。以后即便爆了，前同事也可以往我身上推锅。
类似的情况极多，需求池的规划排期并不仅仅是 “哄老板开心”。如果处理不好，不仅代码是屎山，产品细节也是屎山。
联系到 “向上管理” 的案例，这颗雷的优先级在我的评估里是 6 分，毕竟是高渗透率的体验损失；而一开始提到的老板需求，优先级是 4 分，是一个低渗透率（但老板在意）的功能。
在我的需求池里，6789 优先级的需求排得满满当当，以至于 6 分的需求根本插不进去。研发资源一直极度紧张，全靠我统筹腾挪。高优先级的需求里，很多本身就是老板需求，很多是不做就要出事的高风险需求，很多是其他部门拼了命也要挤进来的需求（否则就找老板投诉），还有我自己冲业绩的需求——做不出业绩我迟早完蛋。
然后你是不是能理解我一开始的判断，把 4 分（满分 10 分）的低渗透率的老板需求给压了下来，给一个性价比更高的延迟执行方案？
即便是老板需求，我也要划分权重，积极执行高优先级，消极执行低优先级，并不是拼命舔老板这么简单。我也不愿意给技术压力，压榨程序员的加班时间，而是我来承担压力，统筹腾挪全局需求。
如果老板要什么给什么，我管理的产品运营部门还好，研发部门就要常态 996 了。而我觉得，该拼的时候就得拼，但不至于为了哄老板开心的 4-6 分需求，逼着程序员 996。
所以研发部门一直都很喜欢我。
至于老板喜不喜欢我，取决于他眼里我有什么重大贡献。比如产品与运营部门的高效率运转算不算贡献？重大新业务的高质量探索算不算贡献？实际上，如果业绩过硬，我在公司里能横着走。只可惜低增长时代已经找不到高增长机遇。
内容来自“用思考交换思考”的 PM 思辨社区「犬校」。©2017-2023
