Introducing the product backlog
Once you’re clear on your outcomes, the team can come together and get tactical about the product ideas that will help create them. The first pragmatic step you can take to get there is adopting a product backlog.
In our work, we’ve encountered many product teams using a single Jira backlog to capture everything: feature requests, small and big opportunities, tasks and subtasks, bugs and urgent issues, and ideas for where the product could go next.
Invariably, they told us the same story. The backlog grows out of control, with an ever-growing list of tickets, and becomes a source of anxiety. These disorganized, overwhelming backlogs don’t support prioritization at any level, from tactical changes to big new investments.
Teams ended up moving these discussions in spreadsheets, but it was groundhog day every quarter. Insights were getting lost, decisions weren’t recorded, and resources were allocated under time pressure, based on gut feel or loud opinions.
There’s a better way: a designated product backlog built around outcomes, distinct from the delivery backlog for day-to-day work.
What’s the product backlog?
The product backlog is where ideas are created, prioritized, and shared into roadmaps, connected to outcomes and goals. It contains all product ideas, insights, opportunities and solutions, and is owned by the product team. Rather than planning specific tasks to be executed, it’s a place to discuss “what should we invest in and why?”. Stakeholders across the company can be invited into this backlog, to collaborate on priorities and roadmaps, and discuss the high-level progress of product initiatives in flight.
Think of the product backlog as a home for the product team, to be shared with collaborators from across the company. It’s a designated space for everything they want to track —from vague ideas to fully formed opportunities — and refine them over time based on learnings, customer feedback, and changing big-picture goals.
Product backlog vs. delivery backlog
The product backlog is separated from the delivery backlog, with each serving a specific purpose.
The delivery backlog is for managing delivery work, creating delivery plans, and tracking progress. It contains the work breakdown (epics, stories, tasks and sub-tasks) for how to deliver commitments, and is owned by the engineering team. This is where the whole team meets and collaborates to discuss delivery concerns: sequencing, dependencies, capacity, technical milestones.
Obviously, the product and delivery backlogs are closely connected. Work in the delivery backlog ladders up to ideas in the product backlog, which are themselves connected to desired outcomes. This gives leaders, managers, and developers a bird’s eye view of how the team is working to realize outcomes as they iterate through cycles of discovery and delivery.
Unlike the product backlog, all items in the delivery backlog are intended as concrete plans, to be completed eventually. By contrast, the product backlog is for ideating and brainstorming as well as planning. Some product ideas will never be prioritized and make it onto roadmaps, and that’s okay.
By separating big-picture product concerns from delivery planning and tracking, teams can prioritize more effectively, connect work to outcomes, and avoid out-of-control backlogs that try to be all things to all people.
How the product and delivery backlogs connect to each other, and to different teams at the company.
How to organize the product backlog
Ideas, opportunities, problems, solutions: the product team needs to decide what to put in the product backlog. These should be what the team is trying to prioritize and represent how the team thinks about product investments and priorities.
How different groups of stakeholders interact with the product backlog.
It is very important for the product team to control what comes in the product backlog and the structure used to categorize and prioritize ideas. Otherwise, they risk the kind of backlog drift into disorganization they were trying to avoid in the first place.
To control the backlog, external stakeholders should be invited with pre-defined ways to contribute only, rather than direct item creation and editing privileges. For example, these collaborators could add comments, vote on ideas, or tag the customer who requested a feature.
Different categories of contributors to a product backlog.
Two recommended frameworks for structuring a product backlog are below: boulders, rocks, and pebbles, and long-, medium-, and short-lists. We recommend organizing the product backlog around these three buckets and these activities.
In Jira Product Discovery, this is done by configuring specific views to show the right ideas, and choosing which fields to show to help the discussion (select, rating) and invite collaboration (insights, votes, comments, reactions).
Boulders, rocks, and pebbles
Many product teams just have one object type: “idea.” But the backlog can contain items of different shapes, sizes and levels of granularity, from big new bets to small product improvements.
A common practice is to structure a backlog with three categories of item::
- Boulders: Large investments, strategic opportunities, and big new bets
- Rocks: medium investments, substantial product improvements that drive toward outcomes
- Pebbles: small investments, like fixing “paper cut”-style bugs and UX issues
It is best to create separate areas for these in the product backlog, and think about balancing investments across the three, reserving budget and roadmap space for each. Pebbles, in particular, are difficult to prioritize without this kind of intentionality. A large new bet is exciting, but paper cuts have a compounding negative effect on the user experience.
Find more information about this framework in the Ideas section.
A view for "Boulders".
A view for "Pebbles".
Long list, medium list, and short list
Another simple, pragmatic way to structure a product backlog comes from Brent Johnston, one of the early adopters of Jira Product Discovery. Brent described product work as constantly working with 3 buckets: the long list, medium list and short list.
The product team takes ideas from the long- to medium- to shortlist in the product backlog, inviting stakeholders from across the company to collaborate.
How different groups of stakeholders contribute to long, medium, and short lists.
- The long list holds everything: “someday, maybe ideas”, problems, opportunities or solutions. There could be 200+ ideas on this list.
- The product team curates this long list, using their knowledge of the market, strategic and operational concerns, and customer and business needs, to turn it into a medium list.
- The medium list is a pre-selection of potential priorities: attractive opportunities the team could legitimately invest in. From a long list of 200 ideas, 10-20 may make it to the medium list.
- These are the ideas that look like good bets because they’re important strategically, frequently come up in discussions with customers, or have strong potential to delight users. They must be prioritized into a short list, typically with input from different stakeholders in the company.
- For more information, see Prioritization.
- These are the ideas that look like good bets because they’re important strategically, frequently come up in discussions with customers, or have strong potential to delight users. They must be prioritized into a short list, typically with input from different stakeholders in the company.
- The short list is basically the product roadmap: ideas the product team has committed to exploring further. These tasks put opportunities, problems or solutions into action, to start creating a product experience or improve an existing one.
- The team reviews this list regularly based on what they learn, and keeps it up to date. It is the list the rest of the company can expect an update on most regularly.
- For more information, see Roadmapping.
- The team reviews this list regularly based on what they learn, and keeps it up to date. It is the list the rest of the company can expect an update on most regularly.
A product backlog, organized to hold customer requests.
How to create a product backlog in Jira Product Discovery
We created Jira Product Discovery as the place where product teams can collect their ideas, collaborate on them, and prioritize. Within Jira Product Discovery, you can create one or many product backlogs, called “Discovery Projects”.
Generally, it’s best to put people who work together day-to-day in the same project (e.g. a squad, or multiple squads). However, quite a few Jira Product Discovery customers use a single project to host multiple teams and products. This is particularly useful when there's a high level of collaboration required between these teams.
Here's a demo for how to do that:
With the Jira Product Discovery premium plan, you’re able to visualize ideas from multiple projects in a single place, by creating views that show ideas from multiple projects and tell the whole story of an organization’s product plans.
What’s next?
In the rest of this handbook, we’ll explain in detail how to use a product backlog to:
- Take ideas from inception to delivery
- Set up feedback channels and gather insights to validate ideas
- Prioritize the ideas that can make an impact
- Create roadmaps your teams and stakeholders can rally behind
We’ll give examples for how we do this in the Jira Product Discovery team, using Jira Product Discovery and other products.
Outcomes
Discover how to use JPD to focus on outcomes over outputs in product development to deliver real value to customers and boost team morale.
Ideas
Explore how to manage and validate ideas in Jira Product Discovery, ensuring continuous learning and impactful product development.