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.
Hustle Badger product backlog template 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:
- Context – what we are talking about
- 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.
Simple impact model to help understand what value a feature will create Simple impact model template [FREE]: Google Sheets
Full impact model template + 3x worked examples [PREMIUM]: Google Sheets
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
Increasing confidence in product backlog 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!).
Checking whether backlog is credible plan to hit objective 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
Further reading
FAQs
Why should you have a product backlog?
A product backlog is a crucial tool for product managers, with several key functions. Firstly, backlogs make you plans visual, and help you see where your team is spending its time. Secondly, backlogs help you check you are doing enough discovery, and increasing your confidence in features before they get built. Thirdly, product backlogs make it clear what engineers should work on next. And finally, backlogs act as a single source of truth, and link to PRDs and other documentation, so anyone can quickly understand what is being built and why.
What is the difference between sprint backlog and product backlog?
Whilst a product backlog is your medium term plan for strategically important work, your sprint backlog is the work that the engineering team commits to in a single sprint. Sprint backlogs are created every sprint, by pulling items from the product backlog, as well as any bugs, ad hoc requests and technical tickets that the team decides to address.
How is the product backlog prioritized?
A product backlog is prioritized by return on investment (ROI), or the impact it will have for a given amount of engineering effort. Features that will deliver large amounts of value in a short period should be worked on first. Prioritization should be backed up by quantitative and qualitative insights, but remember that prioritization will always be a mix of art and science.
What should a product backlog include?
A product backlog should include all your planned, strategic work. This includes both work that will deliver value to end users and the business, and help you achieve your objectives, as well as planned technical work. It should not include unplanned work such as bugs or ad hoc requests from other teams.
What is a product backlog template?
A backlog template is a predefined format to document and prioritize the work that a product team has planned. It typically includes context on each item (such as name, description, theme and links to further documentation) and prioritization measures (such as reach, impact, confidence and effort).
How do you use the product backlog template?
To use a product backlog, simply make a copy of the template, delete the placeholder entries, and add your own work. Backlogs should be shared with your team members, and updated on a regular basis (typically daily).
What is the difference between a roadmap and backlog?
A roadmap is just a visual representation of your backlog, and indeed many tools like Notion, Jira and Monday allow you to easily convert one into the other. Humans process information visually much better than in tables, so showing a roadmap can help people understand your plans for the future. One obvious drawback is that roadmaps don’t convey the diminishing confidence that you have in work that is further out, and lead to easy misunderstandings.
How do you build a backlog?
If your backlog is short of planned work, or it doesn’t look like you have enough high impact work to reach your objectives, then this is a clear signal that it’s worth running an ideation session. This shouldn’t be done without a clear focus, and the more guidance you can provide people involved, the better the output you’ll get from your session. A good starting point is to:
* Review your customer journey map together to understand which problems you’re trying to solve
* Review some reference products for inspiration
* Brainstorm ideas for solutions to the problems your users have
* Add them to the bottom of the backlog and start to refine them
How do you refine a backlog?
Maintaining your backlog in a good state requires regular refinement. This means reviewing the backlog with your team to ensure you are sticking to the principles above:
* You’ve got sufficient confidence in upcoming work
* Your backlog is a credible plan to achieve your goals
* You are shipping regularly and predictably
Should bugs go in the backlog?
t’s tempting to drop every incoming request and bug into your backlog. After all, these items are competing for engineering time with your strategic, planned work. There is no special additional pool of time for working on bugs. However, this is usually a mistake for a few reasons:
* Creates impression all bugs will be fixed
* Creates impression that bugs should be prioritized in same way as planned work
* Visually drowns out strategic work, making backlog unmanageable
Fundamentally, most other bugs are better treated as incoming data points, and added to your customer journey map. If you see a concentration of bugs affecting the user experience, then you can batch these together and fix a bunch at a time. If the customer experience isn’t really affected, then there may be higher value work you could be doing.
