Backlog Politics (Part II): Govern the Backlog, Don't Just Manage It

The backlog is rarely the rational artefact it appears to be. It is a political document, shaped as much by who has authority, whose requests carry weight and what gets quietly reordered after the meeting as by user need or strategic fit. Part 1 made that diagnosis in detail. This piece takes up what to do about it.

Democratic governance offers one model. It's not a perfect mechanism — no one who has watched a parliament at work would claim otherwise. But it doesn't pretend that power disappears when you design the right process. It assumes power will always try to concentrate, and builds structures to keep it accountable anyway.

Most product teams have a process. Very few have governance. The difference is not the sophistication of the scoring framework. It's whether the process has teeth when someone with authority decides to ignore it.

The PM as civil servant

The democratic metaphor earns its place here not as decoration but as a design principle. If users are the people whose problems product is built to solve, and the company is the institution with the mandate and resources to do it, then the PM sits somewhere in between: a civil servant, accountable to both, captured by neither.

This framing matters because it clarifies what capture looks like. A PM captured by leadership becomes an order-taker, translating executive preference into tickets. A PM captured by users becomes a customer service proxy, unable to say no to any individual request. Neither version is actually serving the function.

The civil servant model demands a different kind of accountability: professional, not personal. The process is legitimate because it is visible, consistent and applied regardless of who is asking. A decision is defensible not because a powerful person made it, but because the criteria used to make it are on record. That sounds abstract. The practical version has three parts.

Outcome metrics: did it matter?

The first piece of governance infrastructure is a metrics system that serves users, not internal comfort.

Most teams track what is easy to track: velocity, features shipped, roadmap completion rate. These are output metrics. They answer one useful question: did we do what we said? But that's not the most important question. The most important question is: did it matter?

Outcome metrics answer that question. They sit at the level of user behaviour and experience: are people completing the core action? Are they returning? Do they trust the product enough to pay for it, recommend it, rely on it? Outcome metrics are harder to move and harder to game, which is precisely why they make better governance instruments. They shift the definition of "done" from shipped to worked.

The governance role of outcome metrics is easy to underestimate. A team measuring only output can have a full "done" column every sprint while the product quietly deteriorates. A team with strong outcome visibility knows when a sprint's worth of work made no difference, and that knowledge creates accountability that output metrics simply can't. It also provides a different kind of political protection. When the measure of success is user outcome rather than feature count, anyone who wants to add a speculative item to the backlog has to answer a harder question than "is there capacity?"

North Star metric: are we choosing the right work?

Outcome metrics tell you whether individual work is landing. They don't, on their own, tell you whether you're choosing the right work to begin with.

That connection — between the company's purpose and the team's day-to-day decisions — is what a North Star metric provides. The term has been used loosely enough to start losing meaning, so it's worth being precise: a North Star metric is a single measure that captures the core value the product delivers to users and acts as a leading indicator of sustainable growth. The value to users and the value to the business are represented in the same number. When those two things can't be represented in the same number, that's usually a signal that the product strategy needs attention before the backlog does.

The governance function of a North Star metric is alignment. When every team can see the same metric and understand how their work connects to it, the question "why are we building this?" becomes navigable. Items that can't be connected to the North Star become harder to defend, and that difficulty is a feature rather than a friction to be eliminated. It forces the sponsors of backlog items to articulate the connection, or accept that the item shouldn't be there.

It also constrains the HiPPO pattern described in Part 1. A senior leader who wants to reprioritise now has to do it in relation to a shared, visible measure, not just their own authority. The metric doesn't remove the argument. It changes the terms of it.

Transparent criteria: how was this decided?

The third piece is the most directly political, because it targets the mechanism of capture head-on: transparency in prioritisation criteria.

The way most backlogs get ordered in practice is opaque. The PM has a mental model incorporating dozens of factors, some formal and some not. When a senior leader overrides the list, the informal factors simply become more visible. The formal process is revealed as a layer of legitimacy over a political result.

The antidote is not a better scoring formula. It's making the criteria legible to everyone in the room, including the people whose requests are being declined. Intercom's RICE framework (Reach, Impact, Confidence, Effort) gained traction not because it was mathematically more rigorous than the alternatives, but because it turned a private judgement into a shared conversation. The numbers are debatable. Having debatable numbers is the point.

Similarly, Basecamp's Shape Up approach removes the infinite backlog entirely, replacing it with a periodic betting table: explicit decisions, made by named people, against stated criteria, with a fixed time horizon. The items that don't get bet on are not deprioritised. They're declined. The distinction matters, because a declined item is a decision and a deprioritised item is a deferral. Decisions are accountable. Deferrals are not.

Transparent criteria have a specific political effect: they create a record. When an item is prioritised or declined, there is a reason attached. When that reason is overridden, the override is visible. Over time, a team with transparent criteria can see the pattern of how their backlog actually gets made, and that visibility is the first step to changing it.

This doesn't require a rigid process or a committee. It requires two things: criteria that are written down before the meeting, and a habit of noting what was decided and why. Neither of those is technically difficult. Both of them are politically uncomfortable, which is exactly why most teams avoid them.

The goal is not a frictionless backlog where every decision is clean and every stakeholder is satisfied. That product doesn't exist. The goal is a backlog where the friction is honest: where trade-offs are visible, where overrides are named and where the measure of success is whether users are better off rather than whether the sprint was full. Governance doesn't remove the argument. It puts it on record, and that changes everything about how the argument gets made.