A product backlog is a prioritized list of everything a team plans to work on. At its simplest, it’s a task list for engineers—but a good backlog is much more.
A strong backlog provides a clear window into the team’s health and future success. It shows what the team plans to work on, how it aligns with their strategy, and their confidence in those plans.
Product backlogs are living tools, where ideas evolve from rough concepts to fully developed features. Good backlogs prioritize opportunities with the highest impact. Bad backlogs are everything dumps.
This guide will help you get the most from your product backlog, gives you a free product backlog template, and gives examples of good and bad backlogs.
What is a product backlog
A backlog is a public tool that shows:
- Context – What the team is working on
- Priority – The sequence things will be built
- Confidence – The confidence level the team has in each item
- Impact – The rough impact the team hopes to deliver
Backlogs might include any of the follow:
- Features – new features and enhancements that will create customer and business value
- Bug fixes – fixes to existing code that isn’t working correctly
- Tech debt – technical optimizations that will improve the team’s velocity
But we’d argue that product backlogs should focus on planned work:
- Work that contributes to the team’s objectives or OKRs
- Technical work that has been planned in advance
That means that unplanned work should be excluded and documented elsewhere:
- Ad hoc requests from other teams
- Bugs
This isn’t because the team has a magical proportion of time to work on bugs and tech debt, 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.
Product Backlog Template
Many companies use dedicated software like Jira, Linear or Notion for their backlogs. But you can just as easily manage your backlog in Excel or Google Sheets, and often this is the easiest way to focus on the work, and not the tool.
If you need a product backlog template, the we’ve created one here:
Free Hustle Badger product backlog template Create a FREE account to access the Hustle Badger Product Backlog template
Get the free Hustle Badger Product Backlog template: Google Sheets | Excel | Notion
Why have a product backlog
Product backlogs 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.
Product backlog principles
Just like PRDs, people use the term “backlog” in different ways, and you should adapt the term to your circumstances. Just bear in mind the following principles and best practices to help you get the most out of your product backlog.
Good examples of product backlogs
A good backlog increases the value product and engineering teams can deliver. They are:
- Dynamic – up to date, and show the team’s latest thinking
- Prioritized – show the order the team plans to build things based on value
- Collaborative – regularly reviewed by the team and stakeholders outside the team
- Efficient – have more detail for features about to be built, whilst items lower down are sketched out in brief
- Public – team members and stakeholders can view them to see what’s going on
- Data-informed – supported by insights, discovery, and strategy
Bad examples of product backlogs
Bad backlogs are lists of things, with no guiding principles. They require a lot of management without leading to better team performance, greater impact, or better stakeholder management.
- Static – out of date and don’t reflect current team plans
- Private – locally stored or locked documents, which stakeholders can’t see
- Unordered – no or poor prioritization, without clear rationale
- Inefficient – contain lots of detail for features that won’t be built for a long time (or ever)
- Opinion-driven – no insights, discovery or strategy underpinning items
- Isolated – are personal tools for PMs and not reviewed with the team or stakeholders
Get the free Hustle Badger Product Backlog template: Google Sheets | Excel | Notion
How to create a product backlog
Backlogs need two categories of information to be used effectively:
- Context – what we are talking about
- Prioritization – its importance compared to everything else
How to provide context with your product backlog
Your backlog is much easier for stakeholders to read, when it has names and details that everyone can recognise, rather than issue numbers and technical short hand that doesn’t make sense to people outside the team. This might include things like:
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.
How to prioritize your product backlog
When it’s difficult to make a decision, it means the options are basically the same.
In product, results are not distributed in a linear way, but rather in a logarithmic way i.e. some things will give you 100x or 1000x the impact of others. That means for many teams, one thing on their backlog will deliver more impact than everything else combined.
If it’s not obvious what is the most valuable piece of work on your backlog is, then you probably don’t understand your users or their needs well enough.
That can be difficult when the big things require a lot of effort. If it will take a quarter to ship the next really important improvement, that seems risky. But the alternative is fiddling round the edges and shipping lots of things with no particular value.
Much better to take the time to get the hard, important things done.
Backlog prioritiziation techniques
It follows that backlog prioritization techniques should be a sense-check of what you already believe, rather than the driving force behind what you work on. They help remove bias and personal favouritism, and make sure your intuition fits the available data.
This typically means working out a rough return on effort based on:
- Value the feature will deliver
- The effort to build it
- The confidence you have
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 the RICE framework (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
And RICE is much better than most other ways of prioritizing your work because:
- It’s simple. Frameworks with too many dimensions become random number generators as scores get skewed by small changes in each factor.
- It’s intuitive and everyone can understand it.
- It’s a strong sense check your thinking.
Get the Hustle Badger Ultimate Guide to the RICE framework
Let’s walk through how you would calculate each input for RICE to prioritize your backlog.
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. That means reach is often the most accurate number in RICE.
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.
Create a FREE account to access the backlog template
Get the free Hustle Badger Product Backlog template here: Google Sheets | Excel | Notion
Confidence
Confidence is the degree to which you think your other estimates (impact, reach, effort) are correct.
This is critical because it weighs 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.
Example confidence scale Create a FREE account to access the backlog template
Get the free Hustle Badger Product Backlog template here: Google Sheets | Excel | Notion
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.
Remember, RICE should be a sense check and aid to thinking, not the first and last word in prioritization. Prioritization is always as much art and judgment as science.
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 product 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 your product backlog should give you a clear discovery plan that has a clear objective: making sure that you have a high confidence in 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 product 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 your 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 your product backlog has a credible plan to hit objectives 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.
Wrap up on product backlogs
Good 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 product backlog template can help set your backlog up in a robust way, 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.
Hustle Badger Resources
Other Resources
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 your 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.
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). Get the free Hustle Badger product backlog template here: Google Sheets | Excel | Notion
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). Get the free Hustle Badger product backlog template here: Google Sheets | Excel | Notion
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?
It’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.
Which of the following is a required attribute of a product backlog item (pbi)?
Required attributes of a product backlog item are context (what it is, short description, links to key documents) and prioritization inputs, such as the RICE prioritization methodology to product a prioritization score that can be stack ranked.
Who is accountable for ordering the product backlog?
Product managers are accountable for ordering product backlogs. They should use a robust prioritization framework such as RICE to do so.
What is product backlog refinement?
Product backlog refinement can be either: adding more context and detail to the backlog, or calculating product backlog prioritization. Product backlog refinement by adding more context includes scoping opportunities better. For example this could be fleshing out items using a PRD, or Amazon’s PR FAQs method, or adding discovery information.
Product backlog vs sprint backlog?
This isn’t an either or question, it’s a what when question. A sprint backlog should be a sprint’s worth of activities taken from the top of your product backlog. In order to identify prioritization on your product backlog, you can use a prioritization method such as the RICE framework. This not only allows you to identify potential Reach, Impact and Confidence in your opportunities, but estimates Effort – allowing you to break your opportunity area into sprints once it rises to the top of your product backlog.
What are common product backlog management activities?
Common product backlog management activities include
* Engaging stakeholders and using customer discovery techniques to identify opportunities
* Formulating goals using tools like PRDs and the Amazon PR FAQs method
* Prioritizing the product backlog using prioritization frameworks such as RICE score
* Iterating PRDs and product backlog items as you move through discovery stages
* Product backlog refinement as more context and detail is uncovered, and revisiting product backlog prioritization in light of new information
* Estimating the effort involved in different product backlog opportunities, and ultimately sizing them into sprint backlogs
