Examples of Product Backlogs and How to Manage Them

Product backlog examples come in all shapes and sizes, many of them very, very long. So how can a product manager (PM) organize and structure all these ideas so the right ones always make it to the top? That takes a combination of technology and teamwork.

In this post, we’ll cover a few product backlog examples from a few different angles and how these formats can help you prioritize ideas. 

Product backlogs

First off, I’d like to make clear that these suggestions are around the product backlog, which is separate from the development backlog. I touch on development backlogs a bit more below. (I also have some choice words for weighted scoring algorithms!)

The job of a product manager or product owner is to look at all the things that the team could do, and ultimately decide what the team should do. This means time spent discovering, validating, and invalidating different hypotheses and solutions that are listed as tickets in a backlog.

The backlog is only as valuable as the conversations it enables. These collaborative conversations around your roadmap are essential to building the best version of your product! Product managers, product owners, developers, and people from other functional teams should all be able to read, question, discuss, and understand where the product is headed and why.

That said, here are some ways your team can structure all of the tickets, ideas, and possibilities so that discussions and backlog grooming are smoother and more efficient.

Ways to view a product backlog

List

This format is as straightforward as it sounds. Everything you could possibly do is listed here. In a way, it’s the heart of a product backlog, a valuable collection of feedback, ideas, and discovery.

But, although each ticket is likely tagged, categorized, and color-coded, this long list might not be the best format for actually managing and prioritizing ideas. It’s great as a repository and reference point, but it’s not much of a tool for conversation or decision making.

Priority Chart

This approach literally charts ideas according to effort and impact, providing a super clear overview of quick wins, worthwhile investments, and no-go ideas. Each ticket is represented as a dot on the chart. The effort required to make it happen is measured on the X axis, its impact on the business is measured on the Y axis. 

As a result, each quadrant represents a category of solutions: low effort-high impact (the easiest decisions), high effort-high impact, low effort-low impact, and the section you likely won’t touch — high effort-low impact. 

In ProdPad you can filter this even further according to customer demand, team popularity, or how thoroughly the product spec has been written.

Workflow

Here you can view your backlog through the whole product management workflow, from acknowledging brand new ideas to QA testing fully developed features. Each ticket appears at whatever stage of development it currently sits.

The great perk of this format is that it provides full visibility into the product development process, especially to people on other teams. They can see the status of certain features of fixes and learn about what else is in the pipeline.

Internal transparency is a key part of most company cultures, and ProdPad’s workflow view helps create it across teams.

Roadmap

You can also look at your long list of ideas through the lens of your product roadmap. Don’t look at the backlog as a whole. It’s too much information which, taken all together at once, doesn’t really tell you anything about what you should do next.

Instead, think back to your roadmap and the problems you’re trying to solve. Problem A will have corresponding ideas for solutions in the backlog, as will Problems B and C. So if your team prioritizes at the problem level, then that organizes the backlog according to ideas A, then ideas B and C. It becomes clear what your options are and why you might try them. In ProdPad, this view is simply called “Your roadmap,” and it’s one of my favorite approaches.

Quick note on development backlogs

The structure or style of the backlog will always follow the development method of the team.

For example, a Kanban backlog will cater to a pull flow. The most important tickets will be at the top of the list, and developers pick from the top as they have the capacity. The team typically has three buckets of items in development: doing, testing, done. Each bucket has a limited number of items according to how many developers are actually on the team.

Scrum backlogs cater to a push flow. The tickets are scoped, selected, and prioritized according to what can fit within a one, two, or three-week sprint — however the team structures its dev cycles. A definitive number of tickets are approved for this sprint, and they’ll move through development as a batch.

How not to manage a product backlog

The #1 piece of advice I have on what not to do is unfortunately a widespread practice in the product management world: using weighted score algorithms. I’m talking about RICE and ICE and other acronyms that are used to prioritize backlogs automatically.

Weighted scoring algorithms just aren’t as helpful as we want them to be. In my experience, here are the outcomes of using them:

• The product manager ignores the algorithm. The system will suggest a certain top 5 items, but the PM immediately starts on item 7 because they intuitively know that #7 solves a real problem for the business.
• The product manager ignores their own intuition. Never a good idea. Now they’ll likely spend time working on what’s actually the wrong thing.
• The product manager tweaks the algorithm to match their intuition. The algorithm becomes increasingly complex without telling them anything new. What a waste of time!

Plus, relying on technology to tell us what technology to build misses a very crucial element I’ve already mentioned a few times here (and many other places on this blog): conversation. Collecting feedback and collaborating on potential solutions should be on-going throughout the development process, not just when we create a ticket or write a user story.

At the end of the day, no matter how you structure or view your backlog, remember that it is a living, dynamic record of your team’s creativity and your product strategy. The backlog doesn’t dictate what you will do; rather it’s a tool for decision making and direction taking.