---

不带情感因素的产品优先级排序

所有高效运作的团队都必须处理好优先级问题。不管是每月一次，甚至是每周一次——这个过程严谨且理性。

 by  Brandon Chu      翻译：Kevin嚼薯片

优先级意味着优先去做最重要的事情。如果你是创造产品，这意味着优先去做能创造最大用户价值的事情。

在我的经验里，优先级的决策能力是最难给团队传授的技能之一，因为那些决策往往非常复杂，不过这通常是产品经理的核心责任，我发现在好的团队里每一个人都会依照优先级忘我地朝目标前进，并能始终如一地坚持下去。

这篇文章将讲述如何构建一个优先级模型。

优先级模型

产品管理中的优先级分两种：

1. 项目之间的优先级——这是关于如何确定团队的下一个项目。

2.项目内工作之间的优先级——这是关于如何有效地执行一个项目。

我们会看到，这两种的处理方法是非常不同的。因为它们分别关注在不同层面上的决策。

当在处理项目之间的优先级时，你必须做出的重要决定是：下一个值得我们团队去投资的项目是什么？正确的处理方法像是在完成一个拼图。使用一个严谨的流程来发现所有的碎片，找到把它们拼在一起方法。

当在处理项目内工作之间的优先级时，你必须做出数百次同样的抉择是：这个事情是否绝对有必要的去做？去处理这个事情的正确方法是接受构建产品时的混乱本质，然后形成一个理性的心态去快速判定什么事情是绝对有必要去做的。

我们的优先级模型。项目之间的优先级是一个拼图，我们通过严谨的流程去处理它。项目内工作之间的优先级是混乱的，我们通过不带情感因素的心态去处理它。

项目之间的优先级

一个严谨的流程去解答这个难题：下一个值得我们团队去投资的项目是什么？

回答这个问题时需要严谨，但过程并不复杂：

1. 评估每个项目的投资回报率

2. 考虑三个限制条件：依赖性、时间表和团队构成

3. 完成拼图——根据投资回收率+约束条件把项目按顺序排好

我假设这里大多数概念对读者并不陌生，所以我们将快速过一下。

1. 评估投资回报率

所有项目的优先级都基于投资回报率（ROI），这是衡量你的团队在单位时间内创造的用户价值量。你处理优先级的目标是最大化用户价值。

为了能给项目排优先级，你需要评估两个数据点：

1. 项目将创造的用户价值量

2. 完成项目所需的时间量

一旦你有了每个项目的这两个数据，你就能简单地对比它们，然后你就有了你的优先级。

你需要去做的就是这样机械化的操作

当然，这是非常地难以评估其效果和工作量的，但是假设每次评估时你都有相同的出错几率，那么相应地这样去计算投资回报率也是确定项目优先级的合理方法。

老司机建议：对于所有评估都将工作量加倍且效果减半，你会更接近真实情况。

2. 考虑限制条件

因为现实生活不会像电子表格一样有序，而当你做优先级决策时也需考虑限制条件。你要应对的核心限制条件分别是依赖性，时间表，和团队构成。

依赖性

当为了推进一项工作而必须先去完成另一项工作时，就产生了项目依赖。

比方说你在移动团队，你希望为手机用户开发一键式付款按钮。你已经确认了这是投资回报率最高的项目，所以你想要尽快去做。

需要开发的时间；一键式支付功能；你想发布的时间点

然而，要做到这一点，你的公司需要有即时收款的能力，而这是另一个团队正在开发中的功能。依赖于其他团队去完成，意味着你不能做任何事情，所以正确的优先级决策是推迟一键式功能，并去做你下一个投资回报率最高的项目。

其他团队的收款功能；下一个投资回报率最高的项目；一键式支付功能；你能实际开始开发的时间点

开发产品时依赖关系无处不在，更糟糕的是你的产品规模越大，系统将越复杂。在大公司里，理解和围绕依赖关系去工作往往是考虑优先级时最重要的维度。

说句题外话，大多数人认为创业项目能快速上线是因为他们工作更努力、野心更大。但速度的不同往往是源于更少的依赖关系（而且更少用户会去关心产品好坏），所以它是更容易完成的东西。

反向依赖关系

有时候你有一个真正可以帮助其他团队实现他们目标的项目。在这种情况下你就是依赖项目。

如果公司的投资回报率比优化你的产品更加重要的话——事实上也应该是这样——你现在需要评估的不仅仅是你的项目的累计投资回报率，还有你所推进的依赖项目，从而为你的团队去做正确的优先级决策。

能推进其他项目的项目；你推进的项目；单纯是你产品的最高投资回报率项目；合计大于单独的投资回报率

每当我看到团队为推进其他团队而工作时，他们会赢得我的尊重，这表示他们产品思维的成熟度。这些团队是产品公司的无名英雄，是公司的中流砥柱。

时间表

时间表是一个我们都经历过的典型限制条件。严重时，你将花完创业资金，并在获得足够的收益前死掉。

投资回报率最高的项目；你获取收益的时候；你破产的日子

为避免这种情况发生，正确的优先级决策是在预定时间内去做那些可以上线并且投资回报率最高的项目。

在破产前最可做的项目；投资回报率最高的项目；你获取收益和继续生存的时候；你破产的日子

团队构成

并不是所有的团队都是相同的，如你团队有特定构成时，你需要做出不同的优先级决策。

假设，公司的团队成员完全是新手，像一群实习生（没有不尊重实习生的意思，一般情况下50%的软件都是由他们创造出来的）。

在这种情况下你应该避免安排风险大的项目，即使那是最高投资回报率的项目。相反，你应安排那些不用接触关键代码或用户体验主流程的项目，因为这样能让风险产生的几率降到最低。

没有依赖的“简单”项目；获得用户价值和团队经验；真正困难且高投资回报率最高的项目；你的团队有更多经验的时候

通过一些小的成功案例，让新手团队先上手。一旦他们有了一些产品功能经验时，他们就可以执行更复杂的项目了。

项目之间的优先级：完成拼图以及开始工作

我把上面这些收集信息所需的工作详细地列出来，一旦你有了这些信息，你只需它们放在一起考量即可。

0.列出所有可能的项目，1.评估各个项目的投资回报率，2.考虑约束条件，3.结合约束条件排列出投资回报率最高的项目

项目内工作之间的优先级

用一个理性的心态来确定：这是绝对必要去做的事情吗?

优先级属性在项目执行过程中是不同的。它是混乱的。需要每天去决策，你甚至没有时间像项目间优先级一样去深入地分析。这也是团队内部成员最不理性的时候，涉及到真正的用户时，他们的声誉可能被毁于一旦。

创建产品时，唯一能与速度和混乱去抗衡的方法是建立一个理性的心态，这能持续提醒团队成员当前工作任务以及给他们挑战。

有一个理性的心态意味着接受现实。现实就是你每天都得分配好你的注意力。现实就是发布一个完美的产品是没可能的，在这个过程中需要权衡和取舍。

拥有一个理性的心态代表着前进的决心。利益相关者和用户的期望会给团队造成巨大的压力，导致他们害怕前进。导致他们过于担心小错误而停滞不前。导致他们开始忽略重要的事情和用户价值 ，并开始去尝试追求完美。

实际上，围绕优先级混乱的项目去定计划是不理智的。而去帮助团队成员内化产品开发理念往往是更有成效的策略，帮助他们理性地去问“这是绝对必须做的事情吗？”。在这篇文章的接下来的部分我们将介绍：

1. 建立优先级系统

2. 基于产品设想去衡量质量与速度

3. 发布时间点的价值

1. 建立优先级系统

所有的软件都是不完美的。它现在有缺陷，它开发会超时。当面对一个新的bug时，如果你的团队不能迅速判定出他们能否修复，他们工作的注意力将不停地被打断。

你不可能在每次弹出一个bug的时候去开一个优先级讨论会议，所以你能做的最有效的事情是建立一个能确定何时修复bug、何时继续前进的系统。

这里有一个我富有成效的例子：

错误的严重度（纵坐标）；影响用户的频率（横坐标）；下一个小版本修复（第一象限&第三象限）；立即修复（第二象限）；记录下来（第四象限）

X轴代表bug影响用户的频率，Y轴表示bug的严重性，红点代表一个bug。

使用这个系统，与你的团队成员共同制定严重的程度（如例子里的用户不能支付），以及频繁的程度（如例子里的5%的用户受到了影响）。然后对bug所在区域的处理方法达成一致，其中至少有一个处理方法是记录下来且暂不做任何处理。

如果你多花时间在这上面，你的团队将变成一个bug分类机器，而那些处理低价值bug的几率将因这个系统而被大大降低。

2.基于产品设想去衡量质量与速度

你会经常听说产品早期创建者的代码写得都是垃圾的说法。随着公司越来越成功，这些代码将称为那些新入职到团队的工程师的噩梦。

产品早期创建者都是水平差的程序员吗？也许是。但更有可能的是他们并不在乎当时的代码质量，因为产品未必能成功。相反，他们更在乎的是速度和去验证他们的想法。

为了上线，每一个团队总会牺牲一些质量。团队成员必须决定该适可而止的时间点，这可总结为一个对产品基本质量要求的优先级决策。

这里有一个方法来指导你掌握速度与质量之间的平衡：基于你的产品设想来考量。产品设想是你获取用户问题或为用户提供解决方案的基础。

一个简单的例子来自早期Facebook，他们假设人们想在网上相互联系。这个假设一经证实，他们就开始想出像可以添加其他用户作为朋友的点子，这是一个关于解决方案设想。

在考量你的产品时，对于这些产品设想分三种情况：

1. 你正在尝试去解决的问题是一个设想

2. 解决一个已知问题的方案是一个设想

3. 以上都不是设想（你明确知道需求和原因）

质量和速度的取舍是产品设想的作用（标题）；你正在尝试去解决的问题是一个设想（左）；问题已知但解决方案是一个设想（中）；没有设想你知道要创建什么以及要解决的问题是什么（右）；速度为主（左下）；质量为主（右下）

当你发现你处于图表的左侧时，你有一个关于用户问题的设想但你不知道是不是真有其事。这种情况下，你应该尽快舍弃非核心部分，最大程度地减少你是在解决一个不存在的问题的风险。

在图表的右侧，如果对正在处理的问题和解决方案都很有信心，你应该最大程度地提升质量，因为产品功能将成为成功的关键，也需要考虑未来做更好的扩展。

常常看到一些公司将团队分为负责“实验性”工作和负责“核心”工作。在我看来，这样的组织结构反映了大多数团队的没有理解产品设想图表，从而无法去控制速度和质量。

3. 发布时间点的价值

软件只有发布了才能为用户产生价值。

开发所花费的时间；用户真正获得价值的时间；发布日期

因此，我们应该更快地发布而让用户获取价值。这里我不久前写过一个理论称为发布时间点的价值。

举例，产品团队经常面对的一个选择难题是更早地发布80%用户基础功能，还是为了剩下的20%去延迟发布。这个选择普遍出现在最后20%需求需要花费双倍的时间（相比前80%）才能完成的大量细分功能。

让我们来拆分一下这个选择：

选项1-为80%快速发布，之后再完成剩下的20%；选项2-等到100%解决后再发布

从这个图我们可以看到选项1中80%的用户会获得额外的价值期，而在选项2中他们必须等待。所以这明显地就去选择选项1吗？不完全是，这仍然是团队的一个艰难选择，因为：

1. 对于功能不支持的那20%的用户会毫无疑问地认为你的选择并没有考虑到他们，因此而愤怒。对于他们来说，这甚至比你不给他们任何功能更要严重。

2. 对于功能支持的那80%的用户实际上并不能擦觉到因为提早获取对应功能所得到的额外价值。

讽刺的是这两个结果都因你选择了在过程中提供更多用户价值反而惹怒了更多用户。我们活在一个奇怪的时代。

尽管如此，当面对这个选择时我通常鼓励团队成员去理性分析和尽早发布。原因如下:

1. 如果用户得知完整事实并能为我们做决定的话，绝大部分都会希望我们尽早发布。

2. 从长远来看，如果团队始终遵循这一策略，多次之后用户都会被包含在这80%中 | 20%会走掉，这与那些总是等待100%才发布的公司相比，持续地增强功能会让用户价值获得指数式的增长。

快速发布能让用户获取更多价值是最容易理解的概念之一，但因这带着丢失用户的痛苦而难以推行。通过这个理性的优先级排序将帮你看透这个问题，并让用户的利益最大化。

项目之间的优先级：不带情感因素心态是违背人性的

我们覆盖的概念仅仅是自身经验告诉我是什么价值内化。在这个基础之上，你应根据你自身的经验去作调整。

遗憾的是，理性的优先级排序方法在业内不被大多数团队所赞同，尽管它是一个产品公司的核心模块。

例如，在大型的组织中，团队成员总是不停在发布功能，直到用户正式使用前大多数员工甚至都不知道发布了这些功能，在这种情况下，你认为员工们能看到他们能比竞争对手快3倍地去发布产品的方法吗？可能不会，。相反地，他们只看到产品少了什么功能，尽管这些产品缺陷在他们队友看来都显而易见。

相比之下，一个完美的产品在公司内部往往会收到很多赞美。但糟糕的是它用了两年才发布。糟糕的是我们极少考虑那些已经对失去希望并备受困扰的用户。

让你的团队接受挑战从而做得更好。让他们接受挑战从而变得不带这些情感因素。

制定优先级是一门手艺

团队成员的时间是公司能支配的最宝贵的资源，如果这是你工作的一部分，你必须精通它。这是一门手艺，你可以通过实践去逐步精进。

我给你的最后一个关于优先级真理是：总有比你目前计划要更快达到目标的方法。

总会有的。你只需要找到它。你只需要问，“我们如何能只用一半的时间就能完成它？”当规划会议结束时，便会发生神奇的事情——团队成员找到了办法。

发布和运营产品这么多年了，我还没有遇到过一个团队无法弄清楚如何用更少的时间去创造相等的用户价值。我也还没有遇到过一个团队能完美地处理优先级的，这也同样地证明了我的想法。

不管你是正在推进一个项目，或者是正在决定下一个启动的项目，总会找到办法，而其中唯一合乎逻辑的做法就是不带情感因素和严格地去处理优先级。

即使你的项目是治理一个国家。

---

英文原文：https://medium.com/the-black-box-of-product-management/ruthless-prioritization-e4256e3520a9

get到新技能后，欢迎点击下面【赞赏支持】，给我赏点小费。

还可以继续观看我简书中其他产品运营设计类文章。阅读更多>>