GoKawiilAn idea can be anything from “should we replace our payment system” through to “could you add this button to this particular page.” When both live in the same list, treated as peer-level items competing for the same prioritization slot, you’ve already lost. The word “idea” is doing too much work, and nobody in the room realizes it.
I was talking to a Head of Product last month who described their backlog as “a graveyard with a search bar.” Over 400 items, accumulated over two years, all tagged as “ideas.” Some were multi-quarter platform bets. Some were CSS tweaks. A few were vague sentences pasted from a Slack thread. Every sprint planning session started with the same ritual: scroll through the list, argue about what matters, pick things based on whoever made the strongest case that week, and move on feeling slightly defeated. The backlog had become a performance of prioritization without any of the substance.
The root problem was structural. Every item sat at the same altitude, so every conversation about priority had to start from scratch. There was no hierarchy telling anyone whether they were comparing apples to oranges, or oranges to aircraft carriers.
The Flat Backlog Trap
Most Product teams inherit a flat backlog. It starts innocently enough: someone sets up a board or a spreadsheet, people add items, and the list grows. At 20 items, it works fine. By 200, it becomes unmanageable. Push past 500 and it’s a liability.
The structural failure here is subtle. A flat backlog implies that every item is the same type of thing, deserving the same type of evaluation. But “migrate to a new authentication provider” and “change the color of the onboarding button” are fundamentally different decisions. They operate at different altitudes. They require different stakeholders, different time horizons, different risk assessments, and different evidence thresholds. Putting them in the same list and asking a team to rank them against each other is like asking someone to choose between buying a house and buying lunch. Both are purchases. Both cost money. The comparison is still absurd.
What a flat backlog does to prioritization
When everything sits at the same level, teams default to one of three dysfunctional patterns.
Volume-based prioritization. The items with the most votes, the most customer requests, or the loudest internal advocates win. This rewards frequency of complaint over strategic importance. A minor UI friction that ten customers mention will outrank a foundational architecture decision that nobody outside Engineering even understands. Teams end up prioritizing at the idea level instead of the problem level, and the result is a roadmap that optimizes for noise.
Recency bias. Whatever was discussed most recently feels most important. The backlog becomes a queue, not a strategy tool. Items that were added six months ago decay in perceived relevance, regardless of their actual value. Teams lose track of strategic bets that need longer gestation periods, and the backlog slowly tilts toward quick fixes and reactive work.
... continue reading