Product backlogs help product leaders refine ideas, eliminate those which don’t stack up to scrutiny, and understand which ideas to do when.
A product backlog is a living list where concepts are iterated until they evolve from ideas to fully developed projects.
Good backlogs prioritize opportunities based on ROI. Bad backlogs are everything dumps.
This guide to product backlogs walks you through this tool, provides a free powerful product backlog template, and gives examples of good and bad backlogs.
What is a product backlog
A backlog is a public tool that shows
- What the team is working on
- Demonstrates the priority order of many different product backlog items
- Indicates the confidence level the team has in what they are pursuing
- Demonstrates the order of magnitude of impact the team hopes to achieve
- Shows that the team has a believable plan to reach their goals based on what they select as product backlog items
- [Later] it informs developer tickets based on priority
In so doing a public product backlog:
- Broadcasts the team’s primary focus
- Creates a level playing field about how product backlog items are prioritized
- Enables stakeholder management via transparency and an agreed methodology
- Indicates whether the team is likely to be successful
- Allows proper time management of engineering resource
Product Backlog Template
A great product backlog template can help you
- Improve how you schedule and evaluate projects
- Make sure you have a rock solid prioritization methodology
- Create buy in for how projects are prioritized across the organization
- Inform and improve your discovery efforts
- Help you indicate focus on company impact
- Give you a robust framework to organize your opportunities without re-inventing the wheel
We’ve put together a winning product backlog template in Google Sheets, Excel and Notion.
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
In technology companies there can often be a lot of great ideas floating around, but not a great way to
- Keep track of all these great ideas and make sure they don’t get lost
- Make sure all stakeholders are aware of all opportunities
- Consistently score opportunities according to a fair and understood methodology
- Demonstrate the evolution of ideas as more information comes to light
Done well a backlog solves those issues by
- Capturing multiple competing opportunities as ranked product backlog items
- Ranking those opportunities according to a prioritization framework which is understood by all stakeholders involved
- Acting as a single source of truth, linking to PRDs and engineering tickets, so that people can quickly dive into the details
- Informing future product roadmaps
- Directing development – making it clear what developers should work on next
Product backlog examples
A good backlog improves the ROI on product and engineering activities.
A bad backlog is a list of things, with no guiding principles. It’s not a living document and it doesn’t lead to better team performance, greater impact, or better stakeholder management.
Bad examples of product backlogs
- Locally stored, non public documents which are not socialized with stakeholders (black box)
- Locked documents: ‘Sorry, come back next quarter’
- No prioritization or bias in prioritization
- Missing a north star of value
- Those which are not informed by discovery or strategy i.e. bug lists
- No credible path to achieving goals
Good examples of product backlogs
- Public documents which are being routinely updated and discussed
- Informed by discovery, strategy and delivery
- Rigorously prioritized via a robust methodology that
- Minimizes bias, and brings in evidence
- Has inputs which factor in customer reach, potential future value, level of confidence, and effort involved
- Are socialized for scrutiny outside the product and tech teams
- Prioritization methodology is agreed by stakeholders
- Are routinely surfaced and reviewed with stakeholders
- Are flexible: continuously groomed and maintained, with ideas progressing through stages of evidence collection and confidence level
Get the free Hustle Badger Product Backlog template: Google Sheets | Excel | Notion
How to create a product backlog
Product backlog management is key to the success of a product team.
Product backlogs are living documents
Product backlogs are not set in stone, but rather evolve continuously:
- If it’s on the backlog, that doesn’t mean it will get done
- The order may well move around, according to strategic considerations and new information coming to light
- The backlog may also be routinely ‘cleaned’ or items removed, based on team capacity, prioritization and so on
What should be in a product backlog
Not everything should go on your product backlog. A product backlog is a list of the planned work that the team wants to do. The product backlog definition we advocate for is:
- Work that contributes to the team’s objectives or OKRs
- Technical work that has been planned in advance.
Product backlog items should not include unplanned work such as:
- Ad hoc requests from other teams
- Bugs
These should be documented somewhere else, and should be excluded from your product backlog criteria.
This isn’t because the team has a magical proportion of time to work on unplanned tasks, but precisely the opposite. It’s a prime example of product backlog management and why it matters.
All work competes for time from engineers. Unplanned work prevents you from doing high value planned work.
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.
Providing context on your 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
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.
How to prioritize your product backlog
A good backlog is stack ranked or sorted in order of priority according to a prioritization methodology which is robust.
There are many different product backlog prioritization techniques that you can use, many of which are useful workshop tools.
However if you want to have certainty in your product backlog impact, it’s best to pick a robust prioritization methodology which calculates a number, taking into account multiple factors, such as
- Value or impact of your efforts
- The customer reach of your efforts
- How much effort an opportunity will take
Rather than grading things on intangible scales, like importance = ‘high’, ‘medium’ etc, and according to people’s intuition.
Who is accountable for ordering a product backlog?
Product managers need to take responsibility for ordering a product backlog, via
- Picking a prioritization methodology
- Socializing it with stakeholders and getting buy-in
- Calculating and refining the inputs to get a score that can be used to organize opportunities
Product backlog definition and product backlog management is one of the most critical tasks a product manager can undertake.
Picking a prioritization methodology
There are many prioritization methodologies you can use. These include tools like impact modeling, RICE, or value / effort calculations.
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
We strongly recommend using RICE for the following reasons:
- It takes into account multiple key factors to produce a trustworthy prioritization based on ROI
- It includes a simple impact calculation which will help you understand the possible impact of your team and whether you have a credible path to reaching goals
- It’s flexible and can be adjusted for context
- It will inform your discovery goals
Get the Hustle Badger Ultimate Guide to the RICE framework
We’ll walk you through calculating each of the inputs in our template below:
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.
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.
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.
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
