The Product Backlog: Bigger Is Not Better
A lot of companies are falling victim to an infinitely growing product backlog. Why is this happening, and what are the ways to change the pattern?
👋 Hey, it’s András here! Every two weeks, I write about product management concepts, hot takes, and frameworks to help you build better products. Subscribe to get each article delivered to you when it’s published!
There are countless memes about the infamous “I’ll put it to the backlog” product manager quote. And for a reason, as it’s a common practice in many places to add new product ideas to the product backlog. What would be wrong with that?
That’s the topic this article is exploring, and how product backlogs become heavy and daunting over time. But what are the ways to avoid the backlog becoming a graveyard of ideas, and restore the important artifact’s lost shine?
What does the backlog contain?
There are always more ideas than the capacity to deliver those. Customers, sales, developers, and other internal stakeholders are constantly coming up with ways how our product could be better.
Should we store those ideas in the backlog? Not really.
Pushing a constant flow of ideas that way will only lead to a very bloated product backlog. One where only the top items matter and all the rest is “something else”. These kinds of backlogs have a bad reputation, and no stakeholders like to work with them.
In addition, the backlog should be a prioritized list, and if anyone can freely add items (or even change the order of those), then the product team’s focus is ultimately lost.
Also, let’s be honest: ideas at the bottom of these backlogs are never addressed. At best, product managers only record suggestions to that place to reassure stakeholders.
If you want to find out whether you’re falling victim to this pattern, go to your backlog right now, and list all the items that haven’t been updated for 3 months. How many items do you see? What if you change it to 6 months? One year?
And these backlogs not only contain product ideas. Technical ideas recorded by the development team are also lining up there: component upgrades, refactors, and other would-be-great-to-do items.
Imagine those backlog items are weights put on a pallet and the product team is required to pull the thing forward. How comfortable would you be putting on one extra weight? What about ten? And who is picking up the falling pieces then?
A different perspective
Another way to approach the subject is to store product and technical ideas separately from the backlog. This way, it’s possible to flexibly triage incoming items in their new place, group recurring ideas together, and avoid comparing suggestions to tasks about to start.
Backlogs should only contain a groomed list of near-term priorities; product and technical items the team consciously prioritized and agreed on.
Don’t get me wrong, I’m not campaigning for a rigid structure where changes are not possible. Agility and adaptation are important, but most teams are not affected by earth-shattering changes every week, so let’s not optimize towards edge cases and extreme flexibility.
Keeping ideas separately has two key benefits.
First, we can design the process of prioritizing ideas freely. We’re not limited by the capabilities of product management tools (Jira, Trello, Azure DevOps…) when grouping or visualizing items.
Second, it should be easily possible to tabulate which ideas are the most demanded and launch product discovery activities in those fields. All without mixing up ideas with other planned items.
Keeping ideas separately is especially useful if we were collecting “official” feature requests in a separate place already. As there is not so much difference between the two, now we can store them together in their new home.
When using this approach in practice, the product manager and the technical lead are shaping the backlog together. In this version, technical and product items are not prioritized separately, the parties agree on one overall priority. Sometimes new functionality developments or user experience improvements are more important, other times refactoring or solution deprecation takes priority.
When this process becomes a habit, the bottom of the backlog doesn’t contain effectively dead ideas, but rather items that’ll be worked on in a few weeks or months.
And plans change, but that’s okay. We should aim for the backlog to reflect the current plan.
The theory in practice
To not just talk about a hypothetical theory, we’re running this approach with my current team for a while. Below, I’ll briefly explain what ceremonies and tools we use for what, but that doesn’t mean this is the only way to do it.
We’re keeping the product backlog in Jira, aligning with the organization’s wider tooling. Product and technical items are mixed but kept in priority order. Stories usually illustrate a bigger effort (often connected to epics), and tasks are smaller chunks of work.
Technical ideas are stored separately, at least somewhat. For practical reasons, we’re using the same Jira product to collect technical ideas, but those items have a different, “Idea” status. While a separation could be better, this made it easy initially to transfer old items to the idea pool.
Product ideas are stored in a specialized tool called Productboard, where we collect customer insights and manage our internal roadmaps. We gather product feedback in the tool and then we group ideas to see what’s the most demanded. Once there is a worthy problem, then it goes through the validation phases. And at the end, the idea graduates from Productboard and becomes a Jira epic with their work items in the backlog.
To ensure new ideas are being looked at, we do a backlog grooming every second week. There, we look at OKRs and the state of current items, then spend most of the time discussing the newly added ideas. For new technical items, we discuss whether it’s an immediate priority or something that we should think about later. And things are rarely an immediate priority, so the theory from above stands: don’t come up with a process for the edge cases.
In addition, every quarter or so we schedule a “big backlog grooming” session where we review the whole backlog and address everything that’s outdated. If the product backlog is kept fairly well, it’s no longer than a 2-hour session. And if something is obsolete, we either delete those items or move them back to an idea. In both cases, it disappears from the backlog.
But again, this is only one way to do it.
Bonus: how others see the topic
I was curious whether ideas are kept separately from the product backlog at other companies, so I asked around. Here are a few takes from the responses:
I allow anyone in the company to add ideas to an Airtable. Complaints/feedback goes into another table once a week, and then I try and match the feedback to the ideas. This is where I go for dry powder when we want to move a metric based on a shift in goals.
—Matt Quinn @ Tanzu Labs
Huge pain point. Backlogs will grow and difficult decisions will have to be made. Most ideas seem like good ones and it's a shame to throw out a good feature, story, spec, or even bug. But if there's little hope in ever being able to justify prioritization of it, it needs to be archived or deleted. This is especially true of empowered product teams where engineers are writing a lot of their own stories, adding their own bugs, etc. There can be too many contributors; what's a product manager to do? This is something I'm facing again, at scale. And I'm asking myself the question, "if I'm going to have to move all this stuff to an archival board at some point, shouldn't I just put it on a separate board to begin with?"
—David Lerner @ Nuts.com
We have a long-term roadmap that allows us to get a big-picture view as to where [ideas] fit while giving us an opportunity to relatively rank their priority beyond evaluating the business impact and engineering effort.
—Larry Chao @ ConstructionBevy
I generally maintain raw and clean backlogs. Raw is just a bunch of ideas/hypotheses, not validated either by quant/quantitative analysis, typically one-pagers. Clean backlogs are where the ideas have been validated and got buy-in from senior execs. Then we start writing the [product requirements document].
—Kali Charan @ Byjus Future School