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

2017-05-22 13:42:00

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

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

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

_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倍地去发布产品的方法吗？可能不会，。相反地，他们只看到产品少了什么功能，尽管这些产品缺陷在他们队友看来都显而易见。

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

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

制定优先级是一门手艺

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

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

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

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

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

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

Ruthless Prioritization

All high functioning teams must prioritize. Not once a month, not once a week — but rigorously, and ruthlessly.

_BY Brandon Chu_

Prioritization means doing the things that are most important first. If you build products, it means doing the things that create the most customer value first.

In my experience, the craft of making prioritization decisions is one of the most difficult skills to impart on teams because of how complex those decisions can become, and while it’s usually a core responsibility of product managers, I’ve found that the best teams are the ones where every one is maniacally prioritizing towards the same goal, and doing so in a way that’s consistent with each other.

This post is about a framework to think about prioritization.

A Framework for Prioritization

Prioritization in product management can be broken down into two scopes:

1. Prioritization between projects — this is about determining what project your team should do next.

2. Prioritizing work within a project —this is about how efficiently you can execute a project.

As we’ll see, the way we should tackle each of these scopes is very different. The reason is because they are each driving at different types of decisions.

When prioritizing between projects, you have to make one big decision:_what will my team invest in next?_The right way to approach this turns out to be like completing a puzzle. Apply a rigorous process to find all the pieces, and the answer is in how they all fit together.

When prioritizing work within a project, you have to make the same decision hundreds of times:_is this absolutely necessary to do? _The right way to approach this is by accepting the chaotic nature of building products, and then develop a ruthless mindset to make quick decisions about what’s absolutely necessary.

Prioritizing between projects

A rigorous process to solve the puzzle: What will my team invest in next?

Answering this question may require rigour, but the process isn’t complicated:

1. Estimate return on investment for each project

2. Apply three constraints: dependencies, timelines, and team composition

3. Put the puzzle together — sequence projects based ROI + constraints

I’m going to assume most of these concepts aren’t new to readers, so we’re going to go through them pretty quickly.

1. Estimate Return on Investment

The basis for all project prioritization is return on investment (ROI), which is measured as the amount of customer value your team creates for a unit of time. Your goal with prioritization _is to _always be doing the work that maximizes customer value created over time.__

In order to prioritize between projects, you need to estimate two data points:

1. the amount of customer value that will be produced

2. the amount of time it will take to finish the project

Once you have this data for each project, you can simply compare them all and then voilà— you have your priorities.

Mechanically this is what you’re trying to do

Of course, it’s notoriously difficult to estimate both impact and effort, but assuming you have an equal chance of being wrong each time you estimate, then as a comparative exercise calculating ROI is a legitimate method of project prioritization.

Pro-tip: double the effort and halve the impact of any estimates, and you’ll be much closer to reality.

2. Apply Constraints

Since life isn’t as orderly as a spreadsheet, there are also _constraints _that you need to factor into your prioritization decisions. The core constraints you have to deal with are dependencies, timelines, and team composition.

Dependencies

A dependency is created when a unit of work needs to be complete in order for another unit of work to progressed.

Say you’re on the mobile team and you want to create a seamless one-tap payments button for customers on their phones. You’ve identified this is the highest ROI project, so you want to do it asap.

However, to do that, your company actually needs to have the ability to accept payments in the first place, which another team is working on now. The dependency on the other team finishing means you can’t really do anything yet, so the correct prioritization decision is to delay the one-tap feature and do your next highest ROI project.

Dependencies are everywhere when building products, and it gets worse the more successful your product becomes, as scale creates more complex systems. In larger companies, understanding and working around dependencies are often the most vital dimensions to prioritizing.

As an aside, most people think startups are fast because they work harder and are more ambitious. The truth is that most of the speed difference comes from having far less dependencies (and few customers to upset if something screws up), so it’s just easier to get stuff done.

Reverse Dependencies

There are times when you have a project that will really help other teams to achieve their goals. You are the dependency in this case.

If you’re optimizing for the company’s ROI above your product’s— which you should be — you’ll now need to assess the _cumulative ROI _of not just your project, but the dependent projects that you unblock in order to make the correct prioritization decision for your team.

Whenever I see teams working to unblock other teams they earn a lot of respect from me, and it signals maturity in their product thinking. These teams are the unsung heroes of product companies, and are the ones who provide the most leverage for a company.

Timelines

Timelines are the canonical constraint, one we’ve all experienced. A particularly serious one is when your startup will run out of cash and die before the highest ROI feature will ship.

When this happens, the correct prioritization decision of course is to do the highest ROI project that is achievable within the timeframe.

Team composition

Not all teams are equal, and sometimes the composition of the specific people on your team means that you will need to make different prioritization decisions about which project to take on.

An example is having a team that is full of brand new people to the company, like a gaggle of interns (no disrespect to interns, 50% of all software is built by them).

In these situations you should be wary of prioritizing a project that has a lot of risks to customers,_even if it’s the highest ROI._Instead, you’ll often be better off prioritizing a project that doesn’t touch any critical code or user experience journeys, because then the magnitude of a bad outcomes are diminished.

Help newbie teams get their feet wet first by shipping small wins. Once they have a few production features under their belt, they can progress towards more complex projects.

Prioritizing between projects: Complete the puzzle and get to work

I’m trivializing the amount of work it takes to gather all the information above, but once you have it all, you just have put the pieces together.

Prioritizing work within a project

A ruthless mindset to determine: Is this absolutely necessary to do?

The nature of prioritization is different during the execution of a project. It’s chaotic. Decisions are needed everyday, and you don’t have time analyze each one as deeply as we did when prioritizing between projects. It’s also a more emotional time for a team, as real customers are going to be impacted, and their reputation may feel on the line.

The only way to combat the speed and chaos of building products is to develop a ruthless mindset , one that is constantly aware of the work a team is doing and challenges them on the necessity of that work.

Having a ruthless mindset means accepting reality. It’s a realization that you will have to make hard choices every day on where to focus. It’s a realization that shipping the perfect product is an illusion, and that trade-offs are always required to ship.

Having a ruthless mindset is about the will to ship. Stakeholder and customer expectations create enormous pressure on teams, and as a result they are often afraid to ship. They start sweating tiny issues so much that they’re frozen into inaction. They start losing sight of what matters, customer value created over time, and start trying to be perfect.

In reality, the chaotic nature of prioritizing work within a project means that defining a process around it is foolhardy. A more productive strategy is to help teams internalize product development concepts that aid them in ruthlessly answering_“is this absolutely necessary?”._Here are the one’s we’ll cover in the remainder of this post:

1. Building prioritization systems

2. Using product assumptions to make quality vs. speed trade offs

3. The Time Value of Shipping

1. Building prioritization systems

All software is a liability. It has bugs now, and it will develop more over time. When faced with a new bug, if your team can’t quickly figure out if they should fix it or not, their ability to focus on the most important work will be constantly disrupted.

You can’t afford to have a prioritization meeting every time a bug pops up, so one of the highest leverage things you can do is to create a system that determines when to fix bugs or when to move on.

Here’s an example of one that I’ve found productive for my teams:

The X axis represents the frequency that a bug affects users, and the Y axis represents the severity of that bug. A red dot is a bug.

To use this system, work with your team to define what level of severity is too severe(in this case, that users can’t pay) and which level of frequency is too frequent(in this case, 5% of users affected). Then, agree on a set of actions given which zone the bug falls, with at least one of those actions being put in the backlog and do nothing.

If you invest in this, your team will be a bug triaging machine, and the chance of someone working on a low value bug will be systematically removed.

2. Using product assumptions to make quality vs. speed trade offs

You’ll often hear about shitty code written by founders in the early days of a product. As the company became successful, this code created nightmares for new engineers joining the team.

Were the founders poor programmers? Maybe. But more likely than not, they didn’t care much about code quality at the time because the product was unlikely to succeed. Instead, they cared about speed and validating their idea.

In order to ship, every team invariably makes some sacrifices to quality. Teams have to choose when enough is enough, and that comes down to a prioritization decision about what is essential to the quality of a product.

Here’s a useful way to guide yourself to the right spot on the spectrum of speed vs. quality: base it around your product assumptions _._Product assumptions are fundamental beliefs that you hold about a customer problem, or the solution you’re building for them.

A simple example from the early days of Facebook would have been the problem assumption that people want to connect with each other online. Once that problem was validated, they then thought of product ideas like _being able to add another user as a friend,_which is a solution assumption about how to solve that problem.

If you think about your product, there are three situations you can be in with respect to these product assumptions:

1. The problem you’re trying to solve is an assumption

2. The solution to fulfill a known problem is an assumption

3. Neither are assumptions (you know exactly what’s needed and why)

When you find yourself on the left side of this spectrum, you have an assumption about a customer problem but you don’t know if it’s real. In this situation, you should be cutting corners to ship something as fast as possible, which minimizes the risk that you’ll be trying to solving a problem that doesn’t exist.

On the right end of the spectrum, if there is high confidence in what problem you’re solving and how to build the right solution, then you should maximize quality because you know that feature will be successful and will need to scale well into the future.

You’ll often see companies split teams into those that “experiment” and those that do “core” work. In my opinion, organizational structures like this reflect the inability for most teams to understand the product assumption spectrum, and be able to switch gears towards speed or quality.

3. The Time Value of Shipping

Software only creates value for customers once it’s shipped.

As such, we should be able to place a value on shipping something faster to customers. This is a concept I wrote about a while ago called The Time Value of Shipping.

As an example, a difficult choice product teams often face is whether or not to ship a feature early to 80% of the customer base, while delaying the feature for the last 20%. This choice typically arises when building the final 20% requires a lot of niche functionality, which takes double the time to build (as the first 80%).

Let’s break down this choice:

Looking at the diagram, we see that the 80% of customers are enjoying an additional period of getting value in option # 1, whereas in option # 2 they have to wait. So is it obvious to choose # 1? Not exactly, it’s still a hard choice for the team because:

1. The 20% of customers that the feature doesn’t work for will definitely _recognize your choice to not support them,and they’ll be pissed. To them, it’s worse than if you gave them nothing at all._

2. The 80% of customers that the feature does work for _don’t actually perceive the extra value _they received from getting the feature early.

The irony of these two effects is that you will actually have _more pissed off customers _by making the decision to provide _more customer value over time to them._Strange times we live in.

Despite the above, when faced with this choice I usually encourage teams to be ruthless and ship it. Here’s why:

1. If customers knew the full context and could make the decision for us, the strong majority would want us ship it.

2. In the long run, if a team consistently follows this strategy, the number of times a customer will fall on the good side of that 80%|20% will even out, and as a result, relative to a company that always waits for 100%, customers will get exponentially more value over time as the effect of constantly getting features earlier compounds.

Placing a value on shipping faster to customers is one of those concepts that is easy to understand, but hard to act on because of pain that comes with it. Ruthless prioritizers will see through this, and act in the best interests of customers.

Prioritizing work within a project: Ruthless mindsets are unnatural

The concepts we’ve covered are only what experience has taught me are worth internalizing. There are more, and you tweak these with your own based on your experiences.

Sadly, most teams in the industry aren’t incentivized to be ruthless prioritizers, despite it being a core meme of product companies.

For example, in larger organizations, teams are shipping features all the time and most employees don’t even hear about a launch until customers do. In that environment, do you think employees can see that their teammates managed to ship 3x faster than others in their place would have? Likely not. Instead, they only see what’s missing in the product, even though all those shortcomings were _consciously accepted _by their teammates.

In contrast, a perfectly polished product tends to receive a lot of praise internally. Too bad it took two years to ship. Too bad we rarely think about all the customers that churned because they never though it would come.

Challenge your team to be better. Challenge them to be ruthless.

Prioritization is a craft

Your team’s time is the most precious resource a company has at it’s disposal, and if part of your job is to direct that time, you need to become great at it. It’s a craft, and one that you can deliberately get better at with practice.

I’d like to leave you with one last truth about prioritization: there is always a way to accomplish your goal faster than you currently plan to.

Always. You just have to find it. You just have to ask, “_How can we do this in half the time?”at the end of that planning meeting,_and miraculously — the team will find a way.

After years of shipping products, I have yet to come across a situation where a team was unable to figure out how to create the same customer value with less time invested. I also have never come across a situation where a team ended up prioritizing things perfectly, which reinforces the same idea.

If you accept that there’s always a way, the only logical thing to do is to be ruthlessly and rigorously prioritizing, whether you’re executing a project now, or you’re deciding which project to take on next.

Even if your project is an entire country.