4 Ways to Improve your Product Backlog Prioritization

We always have more things to do than time permits. Product development is no exception. We have a long list of things to do to add value to our users, organization, and things you decide to do or not do from a Product Backlog are generally key factors in product success.

What makes a Product Backlog

  • Feature enhancements
  • Exploration
  • Infrastructure update
  • Bug fixes
  • Legal and compliances
  • Modification to existing functionality
  • Reducing technical debt
  • Refactoring

As a Product Manager, you get all kinds of requests from multiple stakeholders. Each one has their reasons to believe the product team should implement their request first.

Why prioritization is important

PM’s role is to maximize value from limited development capacity

You can’t work in order of request, as it will waste critical resources on low-value-adding tasks. Prioritization helps you and the team focus on the essential items, which give you maximum value and return on investment. In comparison, things at the top of the Product Backlog are detailed while delaying detailing lower priority items.

This priority needs to be flexible so that you can modify it based on changing circumstances. The product backlog is a living list of items, where you keep reshuffling priority, adding new items, and removing completed items from the list.

While our goal is to focus effort on items that add maximum return on investment, each requestor will view the value of the request from his perspective. It is essential that you can compare each backlog item for shuffling priority. Generally below factors should be considered while comparing the value of the backlog item.

  • User, Business impact
  • Reducing Risk and Uncertainty
  • Focus on significant learnings
  • Are there any dependencies for work
  • Deadlines such as legal compliances or significant events

How to Prioritize Product Backlog

1) Opinion Based

Some people call it intuition-based. In this, multiple stakeholders gather to set priorities and discuss which should go higher, lower. Discussion is primarily on individual opinion(or so-called intuition) rather than data or hypothesis.

I call it hierarchy-based, as prioritization depends on the position of the requestor. Higher the authority, the more the weight.

2) Relative Business Value (RBV)

In this method, you compare Product Backlog Items against each other and assign them an abstract number. These numbers are meaningless if you view them in isolation. They only tell you relatively if some item is more or less valuable than other backlog items.

3) WSJF (Weighted Shortest Job First)

It is also known as CD3 (Cost of Delay Divided by Duration).

This model takes the value of a specific backlog item and its effort to build such capability to maximize Return on Investment. You will need to determine how to express the quantitative value of backlog items and ballpark estimates in terms of development capacity(generally duration) to deliver a particular backlog item.

Identifying quantitative cost in terms of Dollar value is not an easy task, as you may not know the direct impact of a particular feature in terms of dollars. It is good to use Business Points using RBV to measure the relative cost of delayed Backlog items. High-level effort should come from the development team, which will help you figure out the weight of each backlog item for prioritization.

How to improve your Backlog Prioritization for maximum impact?

Irrespective of models for product backlog prioritization, you can improve prioritized delivery using the below practices.

1) Ask “Why” and Say “No.”

As a PM, you receive requests for all sources, and one of the major skills for PM is to say No to many things rather than keep adding them in the Product Backlog. Identify what requests align with product vision and mission with impact by asking “Why” to the requester. One of the key things to focus on is how many things you say “No” to ensure you have a limited focus area for greater impact.

2) Treat defects as part of Product Backlog

I came across many teams who want to reduce their defects to zero. This is a great loss of available capacity. It is important to prevent defects by focusing on quality at the source, However, once you have delivered product backlog item and identified defects in released functionality, Defects should go back to Product Backlog and be prioritized based on impact, cost, and value of fix compared to other backlog items.

3) Avoid Technical Stories without any User value

Some teams want to create technical stories for re-design, refactoring, or creating shared services. My observation is that without the right goal and shared understanding of the value, it becomes peeling an onion, where you keep finding more work once you start your development. IT is important to avoid such backlog issues and relate such work with relevant user value items in the Product Backlog. Even in extreme cases where you can’t directly relate it to value, there should be some quantitative or qualitative hypothesis about the value of such work. If you cannot express the value of such work, then it may not be worth doing.

Sometimes you hear statements such as “it will help us make our code maintainable, so we should do this redesign immediately.” Such statements are pretty vague and could not be used for prioritization, maintainable for who? are we talking about the person who developed this, existing team members, or a new joinee? What if we don’t have any changes planned for this feature in the foreseeable future? Do we still want to invest in re-design? It is essential to share value hypothesis in quantitative or qualitative terms for such work, which would help you identify Relative business value. There is no perfect Architecture, design, or code, and Our goal is to use optimal solutions for maximum RoI. Do not focus on the short-term; otherwise, you may accrue technical debt.

The goal is to have manageable technical debt while constantly adding value for users.

4) the Wrong hypothesis is better than no Hypothesis

All Product backlog items should have some value hypothesis written, preferably quantitative terms(if not at least qualitative). It is pretty easy to take about the value of something; however, once we start typing it, our brain naturally helps us critique that thinking and explore a different perspective. I would encourage all to provide their hypothesis based on available knowledge and gut feeling. This will force the requester to see the big picture and help you eliminate backlog items where you can’t come up with a hypothesis.

By following these changes in how you approach product backlog prioritization, you can improve your impact and RoI from available resources while delivering maximum value to users and the organization.



Product Developer | Agilist | Coach | Learner | I write about Product development, leadership and innovation

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Prakash Inani

Product Developer | Agilist | Coach | Learner | I write about Product development, leadership and innovation