Written by on

Prioritizing product backlogs is a key responsibility of product managers. It's essential that the most important backlog items are done first, so customers, users and the business have the highest benefit. There are a number of methods on how to prioritize a product backlog, which fit different situations. In this article, I aim to introduce a couple of approaches I find useful and how to best apply them.

I try to be as methodology agnostic as possible. Independently where on the Agile <-> Waterfall spectrum a product is being developed, maintaining a product backlog and prioritizing its items is essential. I structure this article into two sections: Prioritizing for mature products and prioritizing for new products. While there are certainly overlaps, the methodology I suggest to use approaches that allow prioritization on a finer granularity for mature products, simply because otherwise there would only be super high important items in the backlog.

Prioritize for mature products

Prioritizing for a mature product is my day-to-day job, so I focus on my own view to this subject. Additionally, I give some advice on how to handle requirements from high-profile individuals.

When prioritizing for mature products, I assume:
- All features that are essential for the business are already delivered.
- There's a clear picture of business goals and problems you want to address with the features.
- The development team is established and experienced on the product.

Backlog item scoring

With "Backlog item scoring" I mean that analyzing each backlog item for a number of attributes and assigning a score to each attribute. Then you apply a function that aggregates the individual scores into a single, overall score. There are a number of frameworks, but in here I'd like to describe what works best for me. For an alternative approach, see e.g. the Weighted Shortest Job First method.

The method I use is to prioritize by Importance to Business, Frequency of use and Ease of Development. I only suggest to use this method when:
- Working on established products.
- There are clear business goals and priorities.

This is the method I use when prioritizing PRDs. How it works:
- Assign a score of 1 - 5 to each Importance to Business, Frequency of use and Ease of Development.
- Add those numbers up.
- Voila, the backlog item with the highest overall score should be done first.

With this method:
- I'll identify quick wins that have a big impact using little development resources (everything >13).
- I'm able to remove or push back backlog items with a low score (everything < 4).
- I get a reasonable estimate on the sequence in which the remaining backlog items should be developed.
- I keep it simple and don't lose myself in too many details or complicated formulas. It's also intuitive and easy to understand for team members or stakeholders unfamiliar with it.

Sounds simple, right? But there are a few things to consider.

Importance to Business

I rate this score depending on how much the backlog item's key KPI is in the current focus of the business. For example, if a backlog item's main KPI is an order conversion rate increase, but the business focus is with customer satisfaction, I'd give a low score. On the other hand, if e.g. the backlog item's KPI is user retention and the business goal is to increase user stickiness, I'd give a high score.
Using this score, I force myself to think in the perspective of the business and not only from user perspective.
Urgency also plays into this score. For example, if the business is spending a lot of money on customer service because the call-in rate is very high, you might want to deliver features aimed at lowering the call-in rate and increasing customer satisfaction as quickly as possible.
In order for this score to be accurate, you need to have a good idea of how you want to measure the backlog item's impact. If you don't have that, first focus on finding the key KPI, then go back to prioritizing.
For large PRDs, Epics or large individual stories I use an "Importance to Business" score. For small PRDs that are part of a larger initiative or user stories that are part of an Epic I use an "Importance to User" score. That's because the business metric of user stories within an epic is usually the same, so their score would also be the same. However, the value to the user might well be different. However, it's important not to directly compare an "Importance to Business" backlog item with an "Importance to User" backlog item. Those should be two separate prioritization cycles.

Frequency of Use

Frequency of use is the estimation of the ratio of overall visitors to the number of visitors interacting with or using the features in backlog item. A score of 5 means that all users (that I count into "overall users") will interact with the backlog item. A score of 1 means rarely anybody will use it.
How you count the overall visitors depends on the situation. You want a realistic number which does not include users that are visiting a completely different area. However, you might also not limit the "overall" visitors to just the pages that the new features are on, because this would be too narrow a picture.
I usually take all visitors that are within the process or funnel in which the new features live. For example, if I'm preparing for a new flight duration filter on the flight list pages on Trip.com, I'd count all visitors inside the main sales funnel as "overall visitors", including users that land on the order write-up/fill-in page and might never see the new filter. So i score according to the overall impact of the new feature to the functional area of your product.

Ease of Development

The easier it is to develop, the higher the score should be. This metric combines to key factors: effort and risk. Effort is the time required for architecture design, implementation, integration, testing and documentation. Risk is the potential for delays because of uncertainties or unforeseen events, for example because you're integrating complex 3rd-party APIs for which there's only spotty documentation.
Now, in order to get a reasonable estimate here, I need to involve our development team. For them to be able to size a backlog item, I need a reasonably good explanation of what the outcome should be. Such a description of the scope is not something that I necessarily have readily available for all backlog items. I usually do it like this:
- Provide a precise scope for backlog items that are likely to enter development within the next 2 month.
- Ask the development team to do a high-level, preliminary analysis for all backlog items after. In doubt, the lowest Ease of Development score is chosen with which the development team is comfortable.
That approach is a bit redundant, because in order to know what will be done in the next 2 month, I already need some kind of ordered list. In practice however, I can get a good idea of what's most important using the Usefulness and Frequency of Use scores.

Usage context

The "Importance to Business, Frequency of use, Ease of Development" indicators work well for me as I'm working on an established product. Rarely is there a backlog item that is an "absolute must" in the sense that we would lose substantial business if we didn't do it. The same goes for the usefulness of new features. The spectrum between "least useful" and "most useful" is far lower than if I were working on a completely new product.
I wouldn't use this method when ordering and prioritizing backlog items of a new or immature product. For those scenarios, see the methods further down this article.

What about HiPPOs?

HiPPO stands for "highest paid person's opinion" and generally describes situations where prioritization is driven top-down by the opinions of senior management or a similar levels, rather than by user behavior, analytics data or business metrics. The downsides to this style are that it takes away ownership from the product team, thus eliminating engagement. It may harm the business because valuing (even a very experienced person's) opinion over data will rarely lead to better results than a data-driven approach. It will lead to very hierarchical structures that discourage creativity and encourage conformity. Still, I sometimes run into such a situation. I first try to:

1) understand the context, because there might be factors that I'm not aware of. If so, I try to propose alternative solutions that might fit better into the overall product backlog.
2) argument the importance of the proposed feature using the scoring above.
3) try to quantify the fallout that would bring because we delay other backlog items. See here for a sample.

If all that doesn't work and I'm stuck with developing a HiPPO feature, I take this approach:

1) Boil the requirement down to the absolute minimum.
2) From this minimum, try to extend into an important product, so that the original HiPPO item is only a small part of another, important and urgent, backlog item.

Prioritizing for new products

When prioritizing backlog items for a new or immature product, I do not advise to use a "Importance to Business, Frequency of use and Ease of Development" or similar classification, simply because importance to business and frequency of use might be very high for all backlog items in such a stage. Here are a couple of methods that are more suitable for new products.

The Walking Skeleton

"The walking skeleton" methods, described in detail by Jeff Patton , views the product you want to build first as a skeleton to which only the most essential parts are attached (so that it can "walk"). The "backbone" of the skeleton is the user journey. "Arms, legs, chest etc." are attached to their respective parts within the user journey. The result is a story map that is not linear but hierarchical. It communicates nicely which are the most essential features for each part of the user journey.
I like this approach because it puts the user into the center. The user journey is something that every team member needs to understand and that every team member needs to discuss and challenge. However, if the user journey is not constantly visible, there's a risk it becomes a document that's "living dead" in someone's dropbox, rather than being a living artifact. With the walking skeleton, a product owner ensures that the user journey is always visible and transparent.

Prioritize by value (MoSCoW)

One of the simplest methods when starting out is a "Must, Should, Could, Won't" (MoSCoW) prioritization of features. It's intuitive and simple to understand, regardless of whether everybody on the team has a background in agile software development or not. Especially the separation between "Must and Should" is hugely important when starting out, because it helps the team explore and agree on what is the minimum viable product.
The risk with this approach is that you'll end up with most backlog items as "Must", some "Shoulds" and rarely any "Could" and "Won't". If in such a situation, first see if there's any way to reduce the number of "Musts" by re-iterating through the user journey. If there still are mostly "Musts" in your backlog, try to decrease prioritization granularity, e.g. by using SAFe’s Weighted Shortest Job First method, or the Walking Skeleton.

Prioritization Matrix

A prioritization matrix aims to prioritize by weighing development cost and risk versus customer value. This is a quick, simple and intuitive method for assigning a priority to backlog items without being too simplistic. For each backlog item, you assign:

Development Cost and Risk: Low or High?
Customer Value: Low or High?

Backlog items with high customer value and low development cost come to the top. Items with low customer value and high development cost move to the bottom or are thrown out.
For the items in between, high customer value and high development effort gets a higher priority than items with low customer value and low development effort.

Prioritization Poker

Useful for initial workshops, especially with stakeholders who won't be part of the product team (e.g. customers, management). For this method to work, participants should be standing around the backlog, the backlog being e.g. pinned to a whiteboard. For each backlog item, workshop participants silently vote a score of 1 to 5 where 5 means "absolutely essential" and 1 means "really unimportant". After everybody has made up their mind, they attach a post-it with their score to the backlog item. This method accomplishes two goals:
- Establish consensus on the most and least important features.
- Facilitate discussion for backlog items with a wide range of scores.

This method is not suitable if there already is an existing backlog, or if the key stakeholder don't participate in the voting process.

Conclusion

In conclusion, when deciding what kind of prioritization approach to use, the maturity of the product, the project stage and the discussion context all need to be factored in. After that's all clear, my opinion is that the method to choose priority needs to be a healthy mix of using hard metrics and being able to communicate the result in an intuitive and easy to understand way. At the end of the day, no prioritization, regardless of the method, should be assumed to be 100% correct and immutable. Rather, the prioritization method should aim to structure discussion and decision making, and encourage constructive and directed criticism.