The product backlog is an idea management tool used by a lot of product managers. It’s an organized list that contains ideas, tasks, and updates that need to be completed. How organized, defined, estimated and prioritized the product backlog is depends on the Product Owner, the Product Manager, or the Scrum Master (it varies from team to team).
The product backlog is not just a to-do list—it’s a living, breathing member of your team that should be constantly adjusting to the evolving needs and priorities of your company.
Prioritizing the backlog, in particular, is one of the biggest headaches in the life of the PM. How can you build all of those feature requests and updates, while simultaneously getting through bug fixes and technical debt with a limited amount of money, time and resources? That’s where a solid approach to backlog prioritization comes in to save the day.
It’s a lot for just one person to manage. But it doesn’t have to be this much of a nightmare as long as you figure out a reliable prioritization process.
We’ve gathered some common backlog prioritization fails, also known as anti patterns, explained why they’re a problem, and how you can fix them.
Check out our libray of 35+ roadmap templates. Access them by signing up for a free Roadmunk trial and make them your own.
Backlog prioritization pitfall 1
Too many items in the backlog are irrelevant or the PO doesn’t know how they made it in.
Why this is a problem: Your backlog shouldn’t be a notepad for everyone to jot down every random idea related to your product. It’s meant to be an intuitive and organized repository full of relevant initiatives.
Solution: Have a clear product vision—and make sure everyone lives by it (and do a little bit of cleaning up if you have to).
You might be asking yourself: what does having a clear product vision have to do with a cluttered product backlog? All of the PMs we spoke to about their backlog prioritization process emphasized the importance of having a clear product vision before doing anything else. When everyone has a deep understanding of the product vision and uses it as their guiding light, PMs can be sure that the right ideas are being formulated and included in the backlog.
Here’s a visual breakdown of the ideal product vision, as outlined by Roman Pichler:
A good product vision clearly expresses the long-term impact that you expect your product to have on your customers and your industry (there’s a lot more to a good product vision, but that’s a topic for another post). Your vision also means nothing if no one in your team is constantly thinking about it when screening for feature requests that will go on the backlog.
Having a shared understanding of the product vision is essential to building a product (something that Jeff Patton echoes in his book, User Story Mapping). The best way to do this is by gathering your team and just talking about what they think the vision means. When you hold these conversations, your goal should be to get everyone on the same page. You can do this by holding prioritization exercises—like the one we’ll describe below—that encourage everyone to quantify what’s valuable to the company.
Backlog prioritization pitfall 2:
Prioritizing based on a PM’s personal bias or irrelevant metrics.
Why this is a problem: Internally, the team feels lost or not listened to when it’s time to estimate an idea. Externally, you end up building features that don’t get the customer response you anticipated.
Solution: Use a 2x2 prioritization matrix.
It’s true that product managers need to apply their knowledge of the industry, the target audience, and the product to their prioritization process. But if you notice that there’s a relationship between lukewarm customer reactions to a feature and biased prioritization, you need to reassess a few things.
Ideally, you should have a framework that helps you prioritize backlog items and user stories based on desirability, feasibility and viability:
Desirability: How many customers want it? How badly do they want it? (Validation values)
Feasibility: Do we have the resources (time, money and effort) build it?
Viability: Will it be profitable?
One of the ways you can get the team on the same page when it comes to defining those values is by running features through a value (desirability) vs effort (feasibility) matrix, also called a quadrant or grid.
Reminder: People are notoriously bad at estimating abstracts like time and customer desirability. Besides, it’s hard to assign hard values and numbers to things like effort (how do you quantify the number of hours something will take when you can’t predict outliers that will inevitably put a wrench on those time estimates?). Just keep in mind that you will be wrong about those estimates and that it’s ok. The more estimation exercises and backlog prioritization work you do, the more you’ll get to know about how the team understands the product and if there’s anything you need to adjust in the way they think.
Value vs. Cost
Here’s a basic prioritization matrix that you can use for the next backlog prioritization meeting with your team. To get started, find a whiteboard or an application where you can draw a 4-quadrant matrix.
- On the Y axis, you’ll plot customer value. How you define what makes a feature valuable depends on your product. Do the customers need it immediately? Your company might have other definitions of value like potential revenue, so you can plot for that if you feel it’s relevant.
- On the X axis, you’ll plot the cost to develop an initiative (also known as the difficulty values). This is mostly helpful for the development team.
- On the bottom left of the chart, you’ll plot the items with the lowest values. On the top right, you’ll list the ones with the highest.
A prioritization matrix with values everyone agrees on can help you determine how much input you’re getting from inside vs. outside stakeholders when it’s time to inform backlog prioritization decisions. It also helps you estimate if the data you have on the current epics and user stories are accurate and up to date.
Holding prioritization framework exercises also helps you solve the problem of hoarding old items. In this case, “old” is defined as items that you’ll never get to within the next 3 sprints.
We created an actionable guide to creating any style of agile roadmap. Download it here
Backlog prioritization pitfall 3:
PM or PO doesn’t reach out to the public as part of the prioritization process.
Why this is a problem: You’re only getting an internal, one-dimensional look at how desirable a feature is.
Solution: Validate, validate, validate.
One of the soft skills PMs need in order to succeed is being able to do constant bias checks on themselves. Validating feature ideas with customers early on isn’t just good for the PM’s confidence levels—it also gives the product team an added layer of confidence in a feature before spending resources building it.
Product feature validation is a huge topic, and one that we won’t get into too much detail here. The important thing is that you do at least some form of it before you gather the top priority items for the next sprint. Whether you want to carry user interviews, beta testing, A/B testing or surveys, it’s critical to the prioritization process that you validate ideas at some level after you run them by either a prioritization framework or a value vs. cost quadrant.
Here are the questions that a good customer validation process should help you answer:
- How much will it benefit the users?
- How much does it matter to the users?
- Is it a pain killer (directly addresses a customer pain point) or a vitamin (something that’s nice to have)?
- How often will it be used?
- How much time will people spend using it?
Backlog prioritization pitfall 4:
Prioritizing without taking dependencies into account.
Why this is a problem: You might end up building a feature or functionality that you’ll need to go back to when you spot the dependencies, or you might build something that could have taken less time if only you’d started by building a different feature.
Solution: Make the development team an integral part of the backlog prioritization process.
The bigger your product gets, and the more features you build, the more dependencies there will be between them. When you update or add something new, it can have an effect on more than one other product feature that already exists. Spotting dependencies between backlog items early on can help you prioritize the right set of features for the next sprint.
You should be holding regular backlog prioritization meetings with the development team. That way, they can help you spot technical risks and dependencies early on and before you spend all that time, money and effort into something you’ll have to rework later on. Having prioritization talks with your development team can also help you ensure that nothing is being built sequentially (feature x HAS TO come first, otherwise feature Y, which we have scheduled for our next sprint before feature x, can’t exist).
To wrap things up
If there’s any lesson to be learned from this article, it’s that prioritizing the backlog isn’t a one-man job. Teams should be working together to ensure they’re prioritizing and organizing backlog items based on the parameters that matter the most to the company. Keeping constant collaboration and a healthy environment for ideas and input will also make everyone feel like they’re being heard.
On top of that, by establishing how those values are defined, your team can feel like their contributions are based on some form of qualitative and quantitative criteria.
In the end, when you make an effort to establish these prioritization parameters, you can be confident that you’ll be spending time and effort on the initiatives that matter the most to you, your company, and your customers.
