Backlog Politics (Part I): The Backlog is a Political Artifact

The sprint planning had been running for twenty minutes when the CTO joined the call. Within five minutes, the backlog had a new top item; nobody said anything, and the backlog was just rearranged.

That's not a dysfunction story; it's a description of how backlogs actually work.

Product managers are trained to frame the backlog as a rational artefact, a prioritised queue ordered by impact, effort, strategic fit and user need. We debate RICE scores, run discovery sessions and write careful opportunity statements. Then the quarterly business review happens, or a sales call surfaces an enterprise request, or someone reads a competitor announcement, and the backlog reshuffles to reflect something different, not the most important problem but the most politically important one.

Three factions, one artifact

Engineering, product and leadership each speak for a wider constituency than the org chart suggests, with engineering carrying the technical estate, product carrying the customer and leadership carrying revenue and finance. Each comes to the backlog with a different agenda, and those agendas are not hidden, just rarely discussed.

Engineering speaks for the technical estate as much as for the engineers themselves. They generally want clean, consistent work, namely problems they can scope properly, technical debt they can address before it compounds and time to do things right rather than fast. The backlog items that serve these needs rarely make it to the top, because they carry no user story and move no metric anyone is watching.

Product speaks for the customer. They want to learn, which means running experiments, talking to users and discovering what they don't yet know. The backlog that serves this need is less a list of committed deliverables and more a hypothesis queue, and most stakeholders find that unsettling.

Leadership speaks for revenue and finance, and carries the picture the board is watching. What they want is proof, that the team is productive, that the strategy is working and that there is something to show investors, and that tends to fill the backlog with visible deliverables, tight deadlines and features that can be announced. Output is easier to put on a slide than outcome.

None of these agendas is wrong; each is a legitimate perspective that reflects real pressure. The problem is what happens when they compete without an explicit arbitration mechanism, because the result isn't a prioritised strategy but a political settlement.

The HiPPO in the room

The term HiPPO (Highest Paid Person's Opinion) was coined by digital analyst Avinash Kaushik to describe what happens when data-driven processes get overridden by seniority. The HiPPO doesn't raise their hand to ask for priority; they don't need to, because the backlog adjusts around them automatically once the team already knows what the answer will be.

It's worth pausing on the positive case first, because the critique only lands if you've taken it seriously.

Senior leaders often carry something genuinely valuable, pattern recognition built across years of decisions, markets and failures. A CPO who has scaled a product through two enterprise sales cycles, or a founder who spotted a regulatory shift before analysts did, brings signal that no discovery sprint can fully replicate. Experience translates real-world lessons into intuition, and intuition, when it's earned, is a legitimate input. The mistake is treating that input as a veto rather than a hypothesis.

The problem with HiPPO dynamics is not the quality of the opinion, but what happens to it once it enters the room.

Some of the most effective senior leaders are also the most exposed, CEOs who speak to enterprise clients every week, CTOs who track the technical landscape closely and bring genuine current knowledge into the conversation. The insight they carry can be exactly the thing a team needs, and the difficulty is structural rather than personal. When positional authority means an opinion automatically reshuffles the backlog rather than entering the queue as a hypothesis to test, the feedback loop that would confirm or challenge that opinion never runs, so neither the leader nor the team learns anything, and everyone simply moves on.

This matters because the HiPPO pattern is self-concealing. The backlog adjusts, the feature ships and, if it succeeds, the instinct is validated. If it falls short, the explanation is usually execution rather than premise, and the original call is rarely revisited. Over time, a team that has learned to absorb rather than interrogate senior input stops offering the friction that good decisions require, not because the leader's knowledge has gone stale, but because the organisation has stopped building the mechanism that would keep it sharp.

This is why HiPPO reprioritisation is so corrosive. It doesn't just move items up the backlog, it signals to the team that the process doesn't matter, that scores, frameworks and user research are inputs to a decision that will ultimately be made on different grounds. Teams learn this quickly, and game it accordingly.

Writing this, I realise I've been that PM.

When urgent becomes a veto

The second pathology is more insidious because it doesn't require a senior leader to trigger it. Urgency is a democratic bias.

Every backlog contains items that feel pressing simply because they are proximal, such as a customer who complained this week, a support ticket that has been open for four days or a competitor that shipped something on Thursday. These items have advocates who can be named, timelines that can be pointed to and a clear before-and-after narrative. They feel important because they feel urgent.

The long-term, important work is harder to argue for. A platform migration whose value will compound over the next year doesn't have a customer face attached to it. An onboarding redesign whose benefit shows up in six-month retention data doesn't create pressure in this week's stand-up. These items collect dust at the bottom of the backlog, perpetually important and never urgent enough.

The Eisenhower distinction between urgent and important is widely cited and consistently ignored in practice. In backlog management, urgency functions less like a dimension of prioritisation and more like a veto. An item with sufficient urgency bypasses the normal queue regardless of its importance rank. The stakeholder with a deadline, a customer name and a raised voice will almost always beat the PM with a well-reasoned case for foundational work.

Over time, the backlog accumulates a sediment of genuinely important work at the bottom and a churn of reacting-to-today at the top. The team feels productive while the product drifts.

Output dressed up as strategy

The third pathology is the most sophisticated, because it borrows the language of strategy without the substance.

The build trap, as Melissa Perri describes in Escaping the Build Trap, is what happens when organisations measure success by outputs rather than outcomes, features shipped, velocity maintained, roadmap delivered on time. The backlog becomes the instrument of this confusion, with items written as solutions rather than problems and priorities assigned to deliverables rather than to opportunities. The measure of a good sprint becomes a longer "done" column rather than a better-understood user.

The feature-shaped backlog is not a neutral consequence of poor process, but a political outcome. Solutions are easier to sponsor than problems, because a solution can be named, claimed and credited, and a VP can attach their identity to a feature launch but not to a well-framed problem space.

This is why backlogs fill with items that are requests in disguise, phrases like "build integration with X" standing in for "users need their data to move between systems", or "add reporting dashboard" standing in for "stakeholders lack the information they need to make decisions". The user's actual problem has been translated into a deliverable so that someone can own it, and the translation is always lossy, with the loss always borne by the user.

When you look at a product backlog, you're not looking at a prioritised list of the most important things to work on. You're looking at a record of who asked, who pushed back, who escalated and who was in the room when the decision was made. That's not a criticism of the people involved, but a description of how organisations without explicit prioritisation governance actually function. The next question is what you do about it, which is what Part 2 addresses.