Product Backlog Templates, Examples and Guide

More than anything else, a well-organized product backlog is the most critical tool for any product manager. Whilst it’s literally the list of tasks that engineers plan to work on, a good backlog provides a snapshot into the health and likely future success of a team. This is because it shows transparently what the team plans to work on, how it links back to the team’s strategy, and the confidence the team has in its plans. 

This guide provides product backlog templates, and tactical advice on how to work a backlog effectively to increase your impact as a product manager.

Why a good product backlog is essential

A product backlog is a prioritized list of the work that the team plans to complete. They are critical tools for product managers because they facilitate several key parts of the PM role: 

• Making plans concrete – they visualize where the team is planning to spend its time. 
• Tracking discovery – they allow you to check you have enough confidence in features before you build them.
• Directing development – they make it clear what developers should work on next.
• Acting as a single source of truth – they link to PRDs and engineering tickets, so that people can quickly dive into the details.

What should be in a backlog

Let’s start by defining a product backlog as a list of the planned work that the team wants to do. This would include both:

• Work that contributes to the team’s objectives
• Technical work that has been planned in advance.

It does not include unplanned work such as:

• Ad hoc requests from other teams
• Bugs

These should be documented somewhere else. This isn’t because the team has a magical proportion of time to work on unplanned tasks, but precisely the opposite. All work competes for time from engineers. Unplanned work prevents you from doing planned work, which by its nature high value. As much as possible, you should actively choose what to work on, and avoid reacting to issues that pop up. By all means fix a critical bug in check out, but do it because it’s really important, not because it’s just been discovered.

Ok, so that said, backlogs need two categories of information to be used effectively:

1. Context – what we are talking about
2. Prioritization – its importance compared to everything else

Context

Name
A shorthand name for the problem or feature this line refers to. Don’t get too caught up on it being 100% accurate, as long as everyone knows what you are talking about. 

Description
A brief description of what the problem / feature is. Think of this as a reminder to people outside the team, who aren’t looking at the backlog every day. What are you planning to build and why. This should be 1-2 sentences – they can always go to the PRD for more details.

Theme
It’s often useful to bucket issues into different categories, whether that is OKRs, projects or any other way you think about what your team is doing. It’s also useful to aggregate up bugs and technical tickets into their own groups so you can see the overall time you’re spending on them.

Links to PRD / Jira / etc.
Make sure that it’s easy to find both the PRD, and the tickets that the engineers will work from. You might get these out the box if your backlog is in Jira / Trello / Linear or whatever your developers are using, but if not, make sure it’s easy to go back and forth between different systems.

Prioritization

Generally it’s better to sort items in order of priority, rather than have tags for “high” / “medium” etc. Ordering your features means you have to force rank everything, but when you’ve got 20 “critical” tags, it’s not clear what the team should work on next. A lot of teams use RICE (or a variation) to prioritize their work:

• R | Reach – the proportion of users affected
•  I | Impact – the impact the feature will have on each user
• C | Confidence – how certain we are about reach, impact and effort
• E | Effort – how long this will take to build

Reach
It’s a lot easier to estimate the proportion of your users who will use a feature than how much they might use it, or what impact it might have. Changing the onboarding flow? That’ll affect 100% of new users and 0% of existing users. Shipping a new payment method? That’ll affect 100% of users checking out, and 0% of free users. Splitting reach out from impact allows you to get a much better idea of how much value you’ll create, rather than bundling everything together.

Impact
This is the impact your feature will have on each user affected. Ideally you can benchmark this against similar features you’ve built in the past, and create a simple model that outlines a “what would you need to believe” kind of logic to help you get to an estimate. Don’t fool yourself into false levels of accuracy here though – think like a cosmologist and round everything to the nearest order of magnitude. You’ve no idea whether something will cause a 5% or 6% increase in engagement before you ship it. But you probably have some indicator of whether it might cause a 1%, 10% or 100% change in your target metrics.

Template: Simple Impact Model

Confidence
Confidence is the degree to which you think your other estimates (impact, reach, effort) are correct. This is critical because it down weights ideas which seem great on paper, but you haven’t validated properly yet. It’s effectively a measure of how much discovery you’ve done on a feature, and can therefore be used to guide your investment in discovery: 

• Use a graded, and logarithmic scale to measure risk appropriately and consistently across your backlog
• Systematically increase confidence in features as they rise up your priorities, so you’re not wasting time on things that will never ship, and you’re not shipping things that you don’t have confidence in.

Effort
This starts out as a measure of how long you want to invest in a problem, and evolves into an estimate of how long it will take to build a solution, once the solution becomes clear. This is important to help you not only work on high impact areas, but ones that are a good investment on the time your engineers spend working on them.

• Initially think of effort as the amount of time you’re willing to invest in solving a particular problem
• Talk through the problem and potential solutions with engineers to get a quick feel for the size of effort things are. You’re not looking for a firm estimate, but to understand the complexity of code, and what aspects might greatly increase or decrease the effort
• Before the solution is fully designed, you can give it an order of magnitude estimate such as less than a day / a few days / a few weeks / a few months. Score these appropriately (e.g. 1 / 3 / 15 / 50) not linearly (e.g. 1 / 2 / 3 / etc.)

Priority
Once you’ve calculated reach, impact, confidence and effort, you can combine these into a single priority score:

Priority = (Reach x Impact x Confidence) / Effort

However, in practice the degree of accuracy that you have on each term means if you can’t already eyeball the priority, there’s not a meaningful difference in how you should sequence the work. Prioritization is always as much art and judgment as science.

Product Backlog Templates

Here are templates with example content for product backlogs in different formats:
Google Sheets | Excel | Notion

Product Backlog Principles

Whether you are a PM managing your own backlog, or reviewing other PM’s backlogs, there are some quick and easy checks you can do to see if your backlog – and by extension your team – is in good shape.

Increasing confidence: ice / water / steam

Current cycle | High confidence | Ice

Great backlogs have enough work for the current cycle (typically a quarter, but whatever period your organization works to) that you have high confidence in (>10% on our confidence scale). This means that you have plenty of work that you are reasonably sure will create value, and aren’t going to be scrambling to “feed the beast” and find work for your engineers. For items here:

• You are confident in the impact, because you’ve modeled it
• You are confident in the effort, because you’ve done technical spikes
• Have a static sequence, because your prioritization metrics (RICE) are stable
• You can commit to narrow delivery windows because you’re confident in effort and the sequence is static.

Of course, if new information comes to light during the cycle, you’re going to adapt, but your default course of action here is shipping high quality, high impact work. And that’s a great place to be.

Next cycle | Medium confidence | Water

After the high confidence items, you’ve then got enough items with medium confidence (1-10% confidence) to fill the next cycle. For items here:

• You’ve got some solid, but incomplete insights that indicate they will deliver impact
• You’ve spent 15-30 mins speaking with your technical lead about potential solutions to understand areas of complexity, and get an order of magnitude effort estimate
• Discovery is ongoing to further refine your impact and effort estimates
• You commit to only broad delivery windows
• You have a draft sequence for delivery, but this is likely to change as you do more discovery

Reviewing this section of the backlog should give you a clear discovery plan that has a clear objective: making sure that you have a high confidence work for the next cycle.

Later | Low confidence | Steam

And then, beyond this medium time horizon, you’ve got a bunch of other ideas that are still at very low levels of confidence (<1%). These are largely prioritized on gut feel and relative to each other, but as you ship features and do discovery elsewhere you’re likely to uncover insights that start to increase confidence in some of these ideas and discredit others. Here:

• You’ve got lots of ideas, which are largely unprioritized
• Discovery is ongoing, but limited, so you can spend more time on your medium confidence items
• Confidence is gradually increasing, but largely passively, from discovery on other things

Thinking about your backlog in this manner of increasing confidence is usually a pragmatic and workable compromise between a product team’s preferred Now / Next / Later state of ambiguity, and stakeholders’ preference for hard deadlines and commitments.

Believable plan to reach targets

As the backlog is the work you have planned to reach your objectives, then good product backlogs provide a credible plan for how the team will achieve its objectives. In the best case, the impact that you have modeled in the impact column adds up to more than the impact you need to deliver, and can be shipped within the time remaining to achieve the goal (with a sensible buffer for both!). 

Achieving this level of certainty is only possible in well run and resourced teams. If you’re struggling to get there, then look for root causes you can solve:

• Do you have a clear objective and metrics to measure progress?
• Do you have sufficient insight to know the problems you need to solve to create impact?
• Have you brainstormed in a cross-functional group to come up with effective solutions to the problems you need to solve?
• Does your team have the size, seniority and mix of skills needed to deliver the backlog?
• Does the team have sufficient time to work on planned strategic work? (vs. constantly distracted by ad hoc requests, bugs and operational load)
• Is the team an autonomous unit of delivery? (vs. dependent on other teams to deliver meaningful work)

If you answer “no” to any of these questions, then you’ll need to fix these  fundamental issues to give yourself a chance of success.

Summary

Good product backlogs prioritize work, making it clear what engineers should work on next, helping you decide where to focus discovery time, and providing a detailed plan of how you will achieve your goals. A backlog template can help set your backlog up, and get you into good habits. A healthy backlog will show you that you have high confidence in near term work, with confidence decreasing as the work gets further out.

Resources

• Product Backlog (Google Sheets | Excel | Notion)
• Simple Impact Calculator (Google Sheets)

Further reading

• How to prioritize a backlog – Hustle Badger
• Free Product Backlog Templates and Examples – SmartSheet
• tools for managing your backlog – Lenny’s Newsletter
• What is a backlog – Product Plan

FAQs