A Head of Product last month described their backlog as "a graveyard with a search bar": over 400 items, accumulated across two years, all tagged as "ideas" — multi-quarter platform bets sitting alongside CSS tweaks and sentences pasted from Slack threads.

Every sprint planning session ran the same ritual: scroll the list, argue, pick whoever made the strongest case that week, leave feeling defeated. The backlog had become, in the source's words, "a performance of prioritization without any of the substance."

The root problem was structural, not attitudinal. Every item sat at the same altitude, so every priority conversation started from scratch.

Why does a flat backlog fail?

Most teams inherit a flat backlog. At 20 items it works. By 200 it's unmanageable. Past 500, it's a liability. The failure is subtle: a flat list implies every item deserves the same type of evaluation, but "migrate to a new authentication provider" and "change the onboarding button color" are different decisions — different stakeholders, time horizons, risk profiles, and evidence thresholds. Ranking them against each other is like choosing between buying a house and buying lunch.

Teams in this trap default to three dysfunctional patterns:

• Volume-based prioritization. Ten customers complaining about minor UI friction outrank a foundational architecture decision nobody outside Engineering understands. Teams prioritize at the idea level instead of the problem level, and the roadmap optimizes for noise.
• Recency bias. The backlog becomes a queue, not a strategy tool. Items added six months ago decay in perceived relevance regardless of actual value, and long-gestation strategic bets lose to quick fixes.
• False equivalence in scoring. RICE applied equally to every item produces numbers that create an illusion of rigor. "Reach" for a platform migration and "Reach" for a tooltip are incommensurable inputs; the output is fiction dressed up as analysis.

What does the flight levels model offer?

Klaus Leopold's "flight levels" framework — originally a model for organizational improvement — describes three altitudes: the strategic level (portfolio investment decisions), the coordination level (how work flows across teams), and the operational level (how teams execute). Each has its own cadence, decision-makers, and definition of done.

Product teams already decide at all three altitudes — the Head of Product choosing market segments, the PM choosing which problem to tackle, the Engineering lead choosing a technical approach. The breakdown happens when all three land in the same backlog column, forcing constant context-switching. Strategic conversations get interrupted by operational detail; the coordination layer, where cross-team dependencies actually live, gets skipped entirely.

What is the missing initiative layer?

The fix: insert an initiative layer between objectives and ideas. An initiative represents a problem to solve or an outcome to pursue. It connects upward to a company objective and downward to candidate ideas, experiments, and user stories.

Three things shift once it exists:

1. Prioritization happens at the right altitude. "Reduce payment friction" competes against "Improve first-run onboarding" — comparable decisions with similar horizons. Ideas then compete only within their parent initiative, so "add a button" never fights a payment infrastructure overhaul.
2. Context travels with the idea. "Add CSV export" traced to "improve data accessibility for enterprise customers" becomes self-documenting, no 30-minute onboarding conversation required.
3. Saying no gets easier. "This is good, but it serves none of our current initiatives" is a different conversation than "I don't think this matters." The hierarchy absorbs conflict that would otherwise land on the PM's judgment alone.

Why do delivery tools make it worse?

Jira, Trello, and Azure DevOps excel at tracking execution — tickets, sprints, story points, velocity — but their fundamental model is delivery. A Jira backlog is a flat list by design; epics are containers for stories grouped by scope, not strategic constructs carrying objectives or evidence. When teams manage product thinking in delivery tools, everything becomes a ticket, strategic thinking gets compressed into unread descriptions, and the tool rewards moving cards rather than questioning whether cards should exist.

The source prescribes a two-backlog principle: a product backlog (Marty Cagan's opportunity backlog) for ideas, experiments, and hypotheses organized around problems, and a delivery backlog for committed, spec'd work — with a clean handoff between them.

When does scoring actually work?

Scoring fails in flat backlogs for an instructive reason: frameworks like RICE assume comparable items. Teams either score with false precision and generate misleading rankings, or abandon scoring because results never match intuition. Both failures share one root cause — mixed altitudes. The better approach is to score within a level: initiatives against initiatives using strategic criteria (objective alignment, expected impact, customer evidence); ideas against sibling ideas using tactical criteria (feasibility, speed to learn, scope).

The deeper point: a backlog is not a to-do list but a decision system where trade-offs surface and commitments happen at the appropriate altitude. Teams that adopt the hierarchy report the same experience — prioritization stops feeling like a negotiation and starts feeling like a decision. As the discipline shifts further toward outcome-based roadmapping, that structural separation of strategy from delivery is becoming the baseline, not the upgrade.