How to Prioritize the Backlog When Everything is Important

On my first day as a product manager, I was greeted with my greatest dream and worst nightmare: a giant un-prioritized backlog of 500+ issues. 

This massive list included everything from follow-up tasks for previous releases to broad ideas about product direction; from clearly-defined and discrete user stories, to verbatim feedback from customers. 

It was my job to make sense of it all. 

It was hard to even know where to start. 

Luckily, I stepped into the role after a while at the company, so although the backlog was new to me, the overall product line, our strategy as a company, and the available data I could use to make decisions were all familiar. 

I knew the factors that mattered for our team were reaching the most users, and making the most of our limited resources as a small team. So, I settled on the RICE framework for backlog prioritization, pulled everything into a spreadsheet, and got to work. 

For any product manager, tackling an unfamiliar backlog for the first time can be daunting, and the key to success is finding a framework that works for your particular situation. 

Since not all frameworks are well-suited for all scenarios, the more tools in your toolkit, the better you’ll be able to adapt. 

With that in mind, let’s dive into 9 approaches for prioritization: 

Let’s learn what makes them special so you can decide which one is right for you.

First Principles is the idea of breaking down something complex into its simplest, smallest parts, like taking a cell and breaking it down into molecules. We often talk about breaking down user stories into the smallest tasks, but the same idea can apply to prioritization frameworks. 

If you’re just getting started, an intricate formula might add too much process to an already complex situation. Instead, try a technique that relies on finding a few fundamental truths, rather than detailed, precise or multi-dimensional criteria.

Even Over Statements is a prioritization technique that relies on making explicit trade-offs between two or more great options.

To use this technique: 

Then, you can use that basic heuristic to decide between any set of issues. 

At Parabol, we once used this exact strategy, choosing adoption even over revenue. As a result, we delayed acting on any ideas that were meant to drive revenue, and ruthlessly focused on ideas that could increase adoption. Our retrospective demo is one of the things that came out of that strategy. 

This technique can work well as a starting point for deep strategy work, particularly when you can’t or don’t want to bring a lot of quantitative data to the party. Since you’re explicitly choosing to say no to an array of good things, this prioritization technique forces you to find clarity and focus – and likely move ahead in a clear and strong direction. 

However, success here greatly depends on creating good even over statements. If your trade-offs are between qualitatively different things, or they’re not actually difficult trade-offs (ex: growth over decline), then you won’t get very far. 

Prioritizing by team values means deciding what to work on based on the intuition and ideals of the team. 

For teams that have a lot of experience and autonomy, prioritizing on values is both straight-forward and effective. Team members will have a built-in intuition about what matters, and when pointed at the backlog, they’ll be able to clear it fairly quickly. 

To do this, you could simply have a conversation together over the backlog, delegate a team member to do a first pass and follow up with group discussion, vote on which issues matter most, or run a collaborative process like Sprint Poker to bring the team’s collective intelligence to bear. 

This technique can also work well when there’s a big focus on team bonding. By talking over issues one-by-one, the team can better understand each other’s perspectives and deepen their rapport. 

However, if the team isn’t very experienced with the product area or the company, prioritization by team values may fall flat. 

Teams need to build up their intuition, before they can deploy it. 

When teams are just starting with agile or if they’re doing a sort of hybrid model, they’ll often have a deadline for a larger feature or a goal. 

To reach that goal, there are specific user stories that must be completed – often ones that depend on one another in a, well, waterfall pattern. That’s the critical path. If your team is in a position where there are goals with deadlines, you might choose to put critical path items at the top of your queue. 

In our team’s agile rhythm, we lean on critical path prioritization when we’re close to finishing something. For example, in late November of last year, we knew our goal was to start getting feedback on Sprint Poker ASAP, so we prioritized the issues that blocked us from being able to show the feature to fresh eyes. 

When you’re faced with a large, unordered backlog, it’s hard to say if item #5 is in the right spot. But you can probably figure out if #5 should be higher or lower than item #6. 

The practice of comparing each item to just one other item, and making individual decisions about which is higher priority, is called stack ranking.

Typically, a product manager will do this prioritization by themselves, because it requires meticulous review and can be kind of tedious. If the backlog isn’t too long (less than 50 items), this is a great place to start. 

Stack Ranking also works well for maintaining a backlog. To maintain our backlog, Jordan (our CEO & product manager) will review new issues, and compare them to the existing prioritized backlog, to see where in the stack they rank.

However, because Stack Ranking relies on just one person, keep in mind that much depends on that person’s perspective and willingness to bring others into the process. If they’re unaware of the value of some user stories or have a bias against them for whatever reason, those issues will likely get missed, even if they’re important. 

Where the first-principles approaches focus on what fundamental values drive prioritization, sometimes you need something even simpler. Rather than a fundamental value, you want a basic number. 

When that’s the case, you need to pick one dimension – a quantitative measurement – and focus your attention on that one alone. 

Whether you think of effort as a length of time or the size of work, Smallest Effort First prioritization focuses entirely on ticking off the tasks that take the least amount of work.

You’ve probably done this sort of prioritization in your personal life. If you’ve ever had a free 15 minutes, and picked the smallest tasks to finish – you’ve used the smallest effort first prioritization technique. 

On a team level, this can be more difficult as you’ll need to collaboratively estimate how much effort different stories take. Once you’ve done that, you simply sort them from lowest to highest effort. 

This approach works well if you:

On the other hand, this approach does not consider value at all. That means you might find you’re delaying high-value items for a long time, because they never rise to being the smallest effort. 

In some situations, launching something more slowly could have significant costs. 

For example: 

Cost of Delay is a product backlog prioritization technique where teams evaluate the cost of doing something later, and prioritize the items with the highest cost.

Cost of Delay is a great technique for minimizing downsides, but it can be challenging to implement. Teams will need to review each item and assign an anticipated cost. Since you’re trying to predict the future and comparing dissimilar costs, this can be a headache. 

Where first-principles and one-dimension frameworks are all about simplifying prioritization, complex frameworks take the opposite approach. 

Complex frameworks seek to consider the true complexity of the situation, without being overwhelming. 

Named after former US President Dwight D. Eisenhower, the Eisenhower Matrix balances things that are important versus things that are urgent.  The idea is simple: sometimes things are on fire, and they need to be put out. Sometimes things are slowly falling into disrepair and really matter, so while they don’t need to be done today, they need to get done. 

The philosophy is that you shouldn’t only do things that are in one or the other camp. 

To apply this method to your product backlog, you would tag issues with either ‘important’ or ‘not important,’ and ‘urgent’ or ‘not urgent’. 

In a backlog refinement session, you might remove or de-prioritize unimportant, non-urgent items, then refine items that are important and non-urgent, or are important and urgent. These are the items for consideration during your next Sprint Planning meeting. If you find you have a particularly large queue of urgent items, you might need a different process to manage those – like even over statements.

The Eisenhower Matrix works really well at very large and very small scales: 

Weighted Shortest Job First is a product backlog prioritization approach that attempts to get you the biggest bang for your buck. 

Quite literally, you’ll sort your backlog based on a formula of value over effort – that is, how much value will this provide for each unit of effort? 

The formula is: 

The RICE technique mentioned in the introduction is a kind of Weighted Shortest Job First:
Here, you’re looking at three things to define value: 

And then you’re diving that value by effort. 

Weighted Shortest Job First & RICE are all about maximizing value for the same amount of effort. 

The challenges with these frameworks are all in the details. Because this is a formula, everything needs to be quantified. You may be able to get Reach from some analytics tools, but Impact and Confidence will likely be estimates. The better or worse your estimates, the better or worse your prioritization. 

In Weighted Shortest Job First, when we talk about Value, the details really matter. You need to ask yourself, what kind of value are we talking about? Is it revenue, user growth, etc? And who is that value for? Is it purchasers, end-users, developers, etc? Getting on the same page about this is critical 

Besides being rather intricate, these approaches can also be somewhat rigid. Everything comes down to numbers, and when something isn’t quantifiable or a metric is based on an opinion, that can introduce unwanted bias. 

Even with these concerns, Weighted Shortest Job First is one of the simplest holistic techniques for prioritization – it looks at both value and effort, rather than privileging one or the other. Weighted Shortest Job First works great for teams wanting to optimize their time and be really efficient with their work. With this prioritization technique, you’ll maximize value for the amount of effort you put in.

If nothing on the list suits your needs, you can always create your own formula, based on a mix of what you see above. 

This is how we prioritize our content backlog:

In our case, effort isn’t relevant because we know we’ll publish a certain number of blog posts and a certain number of resources every sprint, and within these categories, effort is pretty much the same. 

So, we focus on value, which we’ve defined primarily around supporting distribution through search and word-of-mouth. Does it speak to our core SEO topics? Are people talking about this? Do we think this will get links? 

Having this formula means our backlog of 150+ content ideas always stays on track. 

Custom formulas work well for prioritizing backlogs in situations with a lot of data and a lot of complexity. If you’re working with a lot of input on what matters from different sources (analytics, support feedback, leadership priorities, etc.), or a backlog with a lot of diversity, custom formulas can help you rise above the fray. 

On the flip side, they are of course complicated. 

A large backlog, in no particular order, won’t get shorter or more organized by itself, but now you have a set of tools to help you get it on track.

If you’re not sure which ones to dive into, our Sprint Poker meetings include Estimated Effort and Weighted Shortest Job First, so you can try those out easily. 

With all these tools now in your hands, the only thing left is to get started.