【推荐】产品经理必须掌握的10种优先级决策技术详解---番外篇：优先级既是一个技术问题，也是一个政治问题

其实早就想写这个番外篇了，但是总怕打击各位产品经理的热情，毕竟我对自己的定位是“一个技术流的产品经理”，想着只要把我们工作中涉及到的各种产品管理技术分享出来就能够有力的促进大家的工作，但现实一次次告诉我，只懂管理技术是做不好产品管理工作的，企业这个江湖依然要讲人情世故，而众多的人情世故综合在一起就形成了我们不得不面对的办公室政治问题。

即使不去考虑那些勾心斗角的破事，就算是在正常的产品管理工作中，我们也依然不得不面临类似的问题。

就拿已经讲过的12种优先级技术来说，从商业级到功能级全有，我们理想的认为只要用好某种技术就能分析出大家都认可的结果，但真是那样吗？先看下图：

作为产品经理，在面对市场部门的时候，他们告诉你的优先级思路一定是这样的话（左侧），而在面对工程部门的时候，他们告诉你的优先级思路一定是这样的话（右侧），而最终的你，只能在他们针锋相对的所形成的灰色地带画圈圈。

总之，一方提出的优先级思路一定是另一方的问题。

我们所认为的选择优先级方案很难，获得企业认可不难的观念在此刻被瞬间击碎，原来正好是相反的。

何故呢？

因为对于：

工程部门来说：他们认为优先级就是“为了完成最重要的工作而承诺做更好的事情”。这就意味者他们必须要拒绝每个利益相关者提出的绝大多数要求，并坚持任何新的承诺都会迫使他们放弃现有的承诺。

市场部门来说：他们认为优先级就是“获得我们需要做的所有事情的承诺”。这就意味着他们希望重点客户和高层次的需求理应得到批准，因为在他们看来，需求是按顺序处理的。

这种情况存在于大大小小各种各样的企业中：一个希望有更多产品，功能和机会的市场团队，面对着一个忙于处理过多承诺和对现有资源感到明显不足开发团队。

这显然不是市场和开发交流不畅的问题，而是世界观的根本性不同。

产品经理呢？

无疑只能处于两者的灰色地带去拉近他们两者的世界观，但太难了，而这个时候，我们所使用的各种优先级技术也就显的过于无力了，毕竟没有一种优先级技术能够兼顾到所有利益相关者的维度。

那我们该如何做呢？

如果我说“无解”，各位是不是会感到很沮丧，我先说说为什么我认为“无解。

1、要求产品团队集体确定一长串事情的优先次序本身就是反个人利益的

优先级说到底，本质上就是评估谁先谁后的过程，其实在“谁“的后面加上”利益“就更准确了。

工程部门去优先开发销售A提出的需求就一定会延后开发销售B提出的需求，A满意了，但B会认为为什么不先开发我的，我认为我的需求优先级更高。

一般遇到这种问题，产品经理会通过两种方法来解决，一种就是把优先级排序权交给具体执行团队让他们自己去做，一种就是让产品团队的全体成员投票决定。

前者似乎可以理解，谁主张谁举证，但是问题是最后不还得汇总到产品经理这边，既然不论谁做产品经理都免不了挨骂，那干嘛费那事呢？

后者似乎是把问题摆在了桌面上，但我觉得依然行不通：

1）前面提到，每个执行团队都会从自己的角度来看待不同的优先事务：

客户支持部门希望 100%+ 的精力放在错误修复和工作流程改进上；

销售部门希望本周最大交易的需求能得到 150% 以上的工程支持，因为下周还将有新的交易；

市场营销部门需要令人兴奋、值得推广的新功能，以提高渠道商的兴趣；

财务和运营部门重点关注降低成本和提高内部效率；

法务部有 110 项必须完成的合规修复工作；

……

但无论你怎样解释，也很难获得全部的认同，因为没有一个部门觉得他们从你那里获得了足够的重视和支持。

全员投票最终就是一场辩论大会，而最终却不会有胜方。

2）没有一个单一的衡量标准

如果标准单一且统一，那么，一切都好说，这就是工程部门在开发产品前为什么要统一开发规范、模型和平台的原因，但是产品不行，你手里有高层提出的5个战略目标，其中分解出48个具体项目，然后又有6个维度以及要执行的13项计划，而这些涉及销售，市场，研发，工程，推广，客服等等，目标涉及短期收入，长期利润，产品质量，需求发现，客户满意度等等。

你一个产品经理，如何来处理呢？毕竟人类的大脑无法同时处理超过7件左右的事情，而我们常常面对的是要把70件事情排序出优先级。

3）难以评估的细节

优先级评估技术并不难，难的是所涉及的每个维度背后的支持材料的质量，以及对每个结果的详细解释。

产品经理一定知道“增加OTA“为什么优先级是P1，但是工程部门却不一定真正清楚，你给他们看背景文档，放心，他们是不会细看的，因为太多了，这还仅仅是一个产品，如果是10个，20个产品呢，难道你能指望工程部门把这么多产品的优先级结果文档都看一遍来理解你的想法？

结果就是，他们都会根据相同的优先级列表想象出不同的项目范围。

最后高层一看，这怎么行，于是亲自下场把能带来某个时期最高回报率的事务钦定成最高优先级，但结果很有可能是一个季度后，会发现系统BUG一堆、架构脆弱不堪、仪器设备支持不够、产品无序扩张等问题。

2、产品经理的解释往往没有效果

当一个人认准自己的标准的时候，那么，无论对方如何解释，都会被认为是在狡辩。

很多产品经理应该有这样的体会，你向市场部门解释为什么基础系统重要，需要优先级最高的时候，他们会和你说，“现在看起来没啥问题啊”，至于后面是否会出现问题，他们会简单的用一句话-车到山前必有路-来让你在风中凌乱，同样，当你向工程部门解释为什么需要优先完成自动化仪表盘的时候，他们也会和你说，“现在的列表数据呈现就挺好的啊”，他们是很少站在客户的真实使用水平和习惯去思考的，他们总认为他们习惯的就一定也是客户习惯的。

而你无论怎么去解释为什么优先级要这样排，即使他们点头表示同意，但心里多半是这样想的：他不是不能，而是不想。

3、完全基于技术的优先级管理思路显然不行

现在我必须承认，这个世界上没有纯技术能解决的事情，因为技术是人发明的，而又要通过技术去解决人的事，这就很哲学了。

看看优先级技术，都多少种了，我估计我会分享20种左右，其实仔细想想每种技术的设计，哪个不是为了尽量避免人的干扰，但事实呢，技术本身可以不干扰，但在实操上呢？

可能很多朋友会和我一样，在一种技术上不断琢磨如何增加能够兼顾多种利益的维度和标准，2维度变成4维度，4维度变成8维度，还得增加权重，增加评估项，增加更多的参与者。

但是结果呢，客户的需求是无限的，同样，满足客户需求的这帮子人的想法也是无限的，而我们的计算量则越来越大，分析时间越来越长，背景资料越多越多，开的会也越来越密集，解释的内容也越来越深，但效果呢，却是越来越不好。

这就是我们在做优先级管理的时候遇到的真实情况，有时候我就会想，这些技术都多余，干脆随性而来算了。

但现实又告诉我们，尽管处理各种利益关系下的优先级很难，但几乎所有成长起来的企业也都无法脱离管理技术（不仅仅限于优先级管理技术）的支持。

管理嘛，一定是80%的科学，20%的哲学，我们需要做的就是如何在20%的哲学指导下做好80%的科学的工作，一想到这儿，我就又有感觉了，似乎“无解”的问题又有“解”了！