A product backlog, at its simplest, is a task list. The best backlogs however help surface the right strategic priorities for a product team, via discovery and impact calculations.
In this article we’ve collated 11 real product backlog examples from companies like Gitlab, ClickUp, Microsoft, Atlassian and more to show you how established tech companies are managing their backlogs, and share the learnings.
Many of these are publicly available, either as feature request boards or public backlogs and roadmaps.
Public feature request boards and hosted backlogs are not only a way of generating a backlog, but they can be powerful discovery tools to uncover and solve user needs.
Broadly speaking there are two types of backlog:
- Product backlogs: Each piece of work is typically a 2-3 days to a month in size and will make a significant difference to the user experience. These are communication documents, for setting out a path and engaging stakeholders.
- Engineering backlogs: tend to be much more granular and describe tickets that engineers will work on. each ticket is 1-3 days long. These are working documents, which track engineering work. Typically managed by a tech leader, or product owner.
We'll be sharing both types in this article.
Real examples can give you inspiration on how a best in-class backlog should look and help you manage your own. Let’s get into it now.
“The purpose of product discovery is to discover and then describe the product backlog. The product backlog is the output of product discovery.” - The Opportunity Backlog, Marty Cagan
The Hustle Badger Product Backlog Example & Template Miro Board
Ministry of Justice's Cloud Optimisation and Accountability Team’s Product Backlog
The Ministry of Justice is a department of the UK government. As part of a cost reduction initiative they invested in building and then migrating services to a cloud platform. This product backlog example is a public backlog, showing items in their backlog being reviewed, refined, and where appropriate, allocated to sprints.
What’s good about this product backlog example:
It’s a great example of a team actively grooming as part of agile working practices. The backlog has 4 sections: current sprint, firebreak, next sprint, and no sprint.
In the first 3 categories, stories are moving through refinement stages, receiving a risk marker where it makes sense, being categorized, and being agreed for sprints. In the no sprint section, items are still being refined. While it’s not clear why certain things are accepted for sprints, it’s clear that by the time they make it to a sprint, the story is crystallized.
There’s additionally a clear structure to the stories, which follow the below structure:
- User need: As….I want…..so that….. Structure
- Value: the reason for doing the work
- Functional requirements (What): required features
- Non-Functional Requirements (How): how they will be delivered
- Acceptance criteria: what good looks like
- Notes: supporting documentation
Front is a customer service platform, and a competitor to Zendesk. They host what they describe as a public roadmap on aha. When you break it down, it’s a list of user voted and inspired ideas on a backlog, and then a tab where backlog items are prioritized for development, in a simple list view. The tabs are labelled ‘Ideas’ and ‘In the works’.
What’s good about this product backlog example:
Users can vote for features, propose features, and they can easily see what is actually been worked on. Many of the backlogs we’ve discussed so far have user participation. However what is good about this example is that the product team truly engage with this backlog.
They made it public to engage with users, as a discovery tool and to be held accountable. As ideas don’t only come from users, but also from internal squads, the company doesn’t fall into the trap of building features users describe as solutions when they’re trying to articulate deeper problems.
“The reaction of our users exceeded our expectations….The public roadmap has already helped us collect valuable feedback e.g. the native iPhone app was far more urgent than we anticipated, and 4 times more requested than the Android app: we instantly added it to our next product cycle.” - Why we made our product roadmap public, and how to build your own
Product Discovery Course
ClickUp’s user generated feature request board is part of its public roadmap. Users can propose and upvote features, and they can see what is being worked on on the roadmap tab.
What’s good about this product backlog example:
Product managers and users really engage with each other. If you click into the threads you can see long conversations between PMs and users, and requests being managed and merged into each other to create tickets. PMs also provide updates, and users share feedback.
Notify.gov is the UK government’s messaging service. It allows central and local government, plus NHS authorities to message users.
What’s good about this product backlog example:
It’s a good example of a merged bug or issue backlog and a strategic backlog. The two backlogs (issues, epics) are displayed on either side of the board, tagged appropriately and are moved into current work queues when they’re prioritized. It’s good hygiene to keep track of bugs alongside planned strategic work.
.NET (often referred to as Dot net) is an open source development and execution platform that works across Windows, Linux and OS. Originally developed by Microsoft, it remains free.
What’s good about this product backlog example:
It’s hosted on Github (also Microsoft owned), and is open source and publicly available. Users submit requests, devs interact with them, and users upvote the requests, which may make it into the roadmap.
However, it does have one of the classic characteristics of a backlog, which is that despite upvoting and community engagement, sometimes requests don’t get shipped. It’s very public when that happens - in this product backlog example, the top requested feature for over a decade is still at the top of the board, unshipped.
Product Neo MBA
Gov.uk’s design system cycle board
What’s good about this product backlog example:
It’s a good example of where a backlog is integrated into a roadmap. The work is organized according to roadmap theme, and work passes through 5 stages, including blocked, and released.
Work that doesn’t fit into the core theme is stored under Small Stories at the bottom, and stored in the backlog section of the board.
Working in public can be particularly critical for public sector organizations, but the principles can be applied to any organization that
“The decision to ‘work in the open’ is often based on a duty to be transparent but there are several other practical benefits to working in the open that are about better delivery: Get feedback, Own your narrative, Gain in visibility, Attract talent, Build trust.” - Filling in the Gaps, the Case for Public Backlogs and Roadmaps, Ross Ferguson
Semantic Kernel is an open-source dev kit that allows integration of AI models into codebases built with Python, Java or C#, and facilitates the building of AI agents. Their backlog and sprint planning is hosted on Github, and displayed in public boards. There’s two boards - one for apps and services, and one for the team who support the SDK or OSS.
What’s good about this product backlog example:
They’ve written a guide to reading the boards for their users, where they explain why they’re doing it and how to read the boards.
The final aspect which is good is that they decided to make their decisions public. Decisions are marked up, users have a chance to comment as they are being made, and once they are finalised, they are documented.
Brainboard is a visual first solution to help teams manage their cloud infrastructure. They have a product feature request board which feeds into sprint planning. Users can submit, comment and discuss and upvote requests.
What’s good about this product backlog example:
It’s a relatively simple public request board. However what’s good about it as the requests are labelled either explaining what is happening with them, or requesting more user input, in terms of upvotes, explanations of need, or more. The team do pick items up from this list and ship them.
Jira Cloud maintain a huge public bug and feature request board on Jira.Atlassian.com
What’s good about this product backlog example:
Users can flag bugs, propose new features, comment, upvote and watch tickets. PMs and devs work directly on the tickets and provide update. Tickets are tagged and given in progress, gathering input, closed and similar statuses.
The major strength of this product backlog example is the Confluence page which accompanies the board. It clearly explains how the product teams work with new feature requests, the best way for users to explain their needs via examples and screenshots, plus points users towards artefacts such as bug lists and roadmaps. It’s a good supporting resource for the feature request board and an effective way of communicating with users at scale.
“The most helpful information you can provide us when commenting on issues is how a particular suggestion would help you. If you describe your use-case to us, and how the suggested change would benefit you and your team, it lets us gain a much deeper understanding of the need behind the suggestion.Suggestions often have an impact on what we work on, even if we ultimately choose not to implement a suggestion exactly as it’s described.” - Atlassian, Implementation of New Features Policy
What’s good about this product backlog example:
At first glance this backlog from the about.gitlab.com site appears relatively simple. However Gitlab have a sophisticated process for managing backlogs, and have put significant effort into articulating their beliefs about a good backlog as part of their Handbook (professional services team).
There they note many common issues with backlogs, including
- PM capability: either spread too thin, missing skills required to manage an agile backlog and being overwhelmed
- Lack of vision or strategy: no overarching goals to align work to
- No roadmap: missing a plan aligned to desired outcomes, and managing the backlog accordingly
- Failure to size backlog items: no effective process or time to size backlog items for elevation to roadmap
Aside from a clear message about the role the PM has in initiating, owning and managing the hierarchies of a backlog, the core takeaways from the Gitlab backlog best practice list are
- Create good user stories: initiated by the PM, the what and the why have to be clear
- Estimate impact continuously: they recommend working with engineering teams and using techniques like estimation poker routinely as part of sprint planning and routine sprint meetings
- Groom & manage backlogs effectively: tags are a core part of managing backlogs within Gitlab, and in the above example, you can see 91 labels being deployed to produce dynamic backlog list views
“Without good user stories and applying good estimation techniques, the product and sprint backlogs become less useful and will ultimately prevent the Agile / Scrum process from becoming predictable.” - Gitlab Handbook
“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.” - Ed Biden, Product Backlog Template
We advocate for a routinely maintained backlog which contains all key context and documents, prioritized using an adapted version of the RICE framework.
What’s good about this product backlog example:
We believe that backlog hygiene is critical. A backlog should be a living document, and it should contain key info, such as PRDs and open tickets.
RICE is a simple prioritization framework initially developed by Sean McBride at Intercom, where backlog items are scored according to Reach (number of people affected), Impact (the scale of impact on users), Confidence (level of certainty), and Effort (difficulty to build).
We adapt RICE in two critical ways:
- Confidence meter to guide discovery: Using Itamar Gilad’s confidence meter to categorize inputs and score the confidence component
- Scoring logarithmically (10, 100, 1000x) rather than linearly (1-5): in order to properly weight big things versus smaller things when it comes to the composite RICE score.
In our opinion, both these adaptations ensure that your backlog is robust.
We also provide a simple impact model to help size your work: since modelling impact in revenue terms is better than linear estimates.
Wrap up on product backlog examples
Good backlogs are transparent, living documents that shape discovery, and help teams uncover pockets of impact.
Public backlogs can help uncover user needs at scale, and drive accountability within teams, but every backlog needs to be supported with a strategy and with effective prioritization and management. Investing time in designing an effective backlog strategy, thinking through how you will communicate with stakeholders, and having a system for discovery and prioritization is critical.
Hustle Badger Resources
[Articles]
[Courses]
[Real examples]
