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. The backlog was just rearranged.

That's not a dysfunction story. That'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. And then the quarterly business review happens, a sales call surfaces an enterprise request, or someone reads a competitor announcement. The backlog reshuffles to reflect something different. Not the most important problem. The most politically important problem.

Three factions, one artifact

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

Engineering speaks for the technical estate as much as for the engineers themselves. They generally want clean, consistent work: 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 don't have a user story attached and they don't move a metric anyone is watching.

Product speaks for the customer. They want to learn — space to run experiments, talk to users and discover what they don't yet know. The backlog that serves this need is less a list of committed deliverables and more a hypothesis queue. Most stakeholders find that unsettling.

Leadership speaks for revenue and finance, and carries the picture the board is watching. They want proof: proof that the team is productive, proof that the strategy is working, proof to show investors. The backlog that serves this need is full of visible deliverables, tight deadlines and features that can be announced. Output over outcome, because outcome is harder to put on a slide.

None of these agendas is wrong. They're legitimate perspectives that reflect real pressures. The problem is that when they compete without an explicit arbitration mechanism, the result isn't a prioritised strategy. It's 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. The backlog adjusts around them automatically, because 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 isn't the quality of the opinion. It's 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. The difficulty is structural, not personal. When positional authority means that 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. The leader doesn't learn whether they were right. The team doesn't learn either. Everyone 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. 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. It's not that the leader's knowledge is stale. It's that 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 and frameworks and user research are inputs to a decision that will ultimately be made on different grounds. Teams learn this quickly. They 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 because they are proximal: a customer complained this week, a support ticket has been open for four days, a competitor 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. 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. Items are written as solutions rather than problems. Priorities are assigned to deliverables rather than to opportunities. The measure of a good sprint is a longer "done" column, not a better-understood user.

The feature-shaped backlog isn't a neutral consequence of poor process. It's a political outcome. Solutions are easier to sponsor than problems, because a solution can be named, claimed and credited. A VP can attach their identity to a feature launch. They cannot attach it to a well-framed problem space.

This is why backlogs fill with items that are requests in disguise: "build integration with X" instead of "users need their data to move between systems", "add reporting dashboard" instead of "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. The translation is always lossy, and the loss is 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. It's a description of how organisations without explicit prioritisation governance actually function. The next question is what you do about it. That's what Part 2 addresses.