Ruthless Prioritization
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:
- Estimate return on investment for each project
- Apply three constraints: dependencies, timelines, and team composition
- 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:
- the amount of customer value that will be produced
- 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.
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.
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 (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.
Show me a team that has no bugs at launch, and I’ll show you one that should have shipped a long time ago.
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:
- Building prioritization systems
- Using product assumptions to make quality vs. speed trade offs
- 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:
- The problem you’re trying to solve is an assumption
- The solution to fulfill a known problem is an assumption
- 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:
- 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.
- 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:
- If customers knew the full context and could make the decision for us, the majority of them would want us to ship it.
- 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 thought 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.
Before you go, some things to consider:
- Recommend or share this if you found it useful. It gives me 🔋 to write knowing people find value in it.
- Subscribe to The Black Box of Product Management if you want more reads like this, or if you consider submitting to it so we can share your story.
