How to Prioritize Your Product Backlog

Be honest. What does your backlog look like right now?

If you’re like most Product Managers, it’s probably become a massive heap of ideas, feature requests, tasks, and bug fixes.

The idea of going through it makes you cringe.

How can you clean and prioritize your backlog to make sure the most important things are tackled first?

We spoke with Melissa Chenok, Group Product Manager at Lattice, about the process of managing a backlog and the role that product managers play in prioritizing backlog items. Melissa provides an overview of the major prioritization frameworks for PMs and outlines how product, engineering, and design roles all fit into the process.

In this interview, we cover:

The process for managing a backlog
The different approaches for prioritizing a backlog
How roadmapping improves backlog prioritization
How managing a backlog differs between product, engineering, and design roles
How to address technical debt issues while managing a backlog

The conversation below has been edited for length and content.

What is the process for managing a backlog?

Managing backlogs generally involves four main components: Definition, Prioritization, Maintenance, and Refinement.

Let’s break these down.

Before you create tickets, you must look at the roadmap, enhancement requests, bugs from stakeholders, and data. From there, you can define the work scope, the value it delivers for users, and the acceptance criteria that the code needs to meet in-order-to be considered done.

Once you’ve defined the tasks, stories, and bugs that you want to complete, then you can move onto prioritization. There are many frameworks for this step, from Agile to Kanban, to Scrum, to Waterfall.

But at the core of prioritizing a backlog, you need to think about the four primary forms of value: customer value, business value, technical value, and quality value.

In essence, these encompass customer needs, the level of effort that it’s going to take for your team to be able to implement a feature, and the value that your organization is going to get from this endeavor.

It’s the product manager’s job to decide on the priority order based on implementation difficulty, task dependencies, and feedback urgency while still maintaining a good line of communication between all key teams, stakeholders, and clients to optimize planning.

After you’ve prioritized the backlog, you then need to maintain, groom, and refine it.

At my current company, we have regularly scheduled reprioritization, estimation of tickets, and “spikes”: time spent estimating the level of effort required to complete a large project. We also have time reserved for things that come in last minute in the backlog so that we have readiness criteria for tickets. And because we’re working within a Scrum methodology, those things fit within sprint themes or goals for current projects.

What are the different approaches to prioritizing a backlog?

There are several different types of frameworks that PMs use to help with prioritization of the backlog such as Kano, RICE, Story Mapping, MoSCoW method, and opportunity-scoring bio features. I wouldn’t say that there’s a specific framework that I recommend over others. Whatever you choose ultimately needs to help the product manager assess the value to users and communicate that out.

What benefits does roadmapping bring to this process?

Roadmapping is crucial for assessing dependencies across pods. A lot of the framework that my current team has in place for managing dependencies requires regular communication.

Most of the identification and evaluation of dependencies occurs during the early stages of the process. So making sure that you have that roadmapping process, that takes dependencies into account, is really important.

I’ve also found success in using roadmapping for taking requests from various departments. As a product manager, we need to look at bugs that come in from customer success, customer support, and technical support. Holding quarterly roadmapping sessions where customer success and sales bring quantitative and qualitative data to us about what we’re hearing in the market ultimately helps me with backlog prioritization.

How does managing a backlog differ between product, engineering, and design roles?

It depends on the team and the organization. I think this differs from pod to pod within my zone, for example. But the overarching responsibilities of these roles is that:

Product is responsible for prioritization and bringing business value
Engineering weighs in on tech debt that we need to accomplish and the level of effort for different projects
Design weighs in on level of effort from the design side, the experience tradeoffs that we need to make, etc.

How can you address technical debt while managing a backlog?

Allocating time specifically for technical debt during roadmapping or sprint planning is helpful. Don’t hesitate to hand your engineering counterparts a list of important technical debt items that need to be addressed. Paying down technical debt and improving developer efficiency does add user value even though it’s not directly correlated. So remember to find time between the PM, engineers, and engineering manager to discuss these important questions: