All high functioning teams must prioritize. Not once a month, not once a week — but rigorously, and ruthlessly.
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 everyone 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:
Prioritization between projects— this is about determining what project your team should do next.
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
回答这个问题可能需要严谨，但过程并不复杂：
1.估算每个项目的投资回报率（ROI）
2.遵循三个限制条件：依赖关系、时间线和团队构成
3.把拼图拼合在一起 - 基于ROI 和限制条件将项目顺序排好
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.
所有项目优先顺序的基础都是投资回报率（ROI），衡量标准是您的团队成员在单位时间内创造的用户价值。目标是：正在做的工作永远是（当前所有工作中）能最大限度地创造用户价值的工作。
为了确定项目之间的优先顺序，您需要估算两个数据点：
1）将产生的用户价值总量
2）完成项目所需的时间
一旦你有了这个数据对每一个项目，你可以简单地比较所有这些，然后就万事大吉了 -你有你的优先级。
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 progress.
为了推进另一项工作，必须先完成一个工作，这时就产生了依赖关系。
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.
然而，要做到这一点，贵公司首先需要有能力接受付款，而另一个团队正在开展这项工作。对其他团队的依赖意味着你现在还无法做任何事情，所以正确的优先排序决策是延迟付款单击功能并执行下一个ROI最高的项目。
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 fewer dependencies, 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.
时间线是一个典型的限制条件，我们都曾经历过。一个情况尤其严重的时间线是：在最高ROI功能发布之前，您的初创公司已经耗尽现金并死亡。
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.
并非所有的团队都是平等的，有时候团队中特定人员的组成意味着你需要对于先做哪个项目做出不同的优先级判断。
一个例子就是团队里全部是新人，就像一群实习生一样（并非对实习生有不敬之意，50％的软件都是由他们创造的）。
在这种情况下，即使项目的投资回报率最高，你也应该提防这是一个对用户来说有很大风险的项目。相反，你通常会优先考虑推进一个不涉及任何关键代码或用户体验旅程的项目，因为这样做导致不良结果的程度会下降。
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.
通过先发布一些小功能来帮助新手队伍小试牛刀。一旦他们在自己的实践中积累了一些产品特点，他们就可以参与更复杂的项目。
待续
