The Product Owner: Decision-Maker, Not Backlog Admin

The Product Owner role is being done wrong almost everywhere. Teams are often performing the motions of Product Ownership: writing user stories, managing a backlog, attending planning sessions, reviewing sprint output. And yet the product doesn’t improve meaningfully, the backlog is a mess, and developers are frequently building things that don’t matter.

The problem is almost always the same: the Product Owner is a backlog administrator rather than a product decision-maker.

What Is the Product Owner Accountable For?

The 2020 Scrum Guide puts it in one line: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” That sentence is so simple it hides how hard the job is.

Maximizing value requires knowing what value means: for the customer, for the business, for the product’s competitive position. It requires being willing to make difficult prioritization decisions that disappoint some stakeholders. It requires enough technical understanding to have informed conversations with developers about feasibility and approach. And it requires enough business knowledge to connect daily sprint decisions to strategic outcomes.

Most Product Owners I’ve encountered have some of these but not all. A business analyst can become a capable PO if they develop prioritization instincts and business acumen. A project manager can become a capable PO if they develop genuine customer empathy and the courage to say no. But the role demands a combination of skills that doesn’t fit neatly into any traditional job category, which is why it’s so frequently done poorly.

The Three Jobs Nobody Talks About

Making prioritization decisions when stakeholders disagree. This is the PO’s most politically difficult responsibility and the one most often avoided. When the marketing lead, the sales director, and the compliance officer all have “top priority” items and they conflict, the PO decides. Committees and whoever argues most loudly don’t get the call; the PO applies a coherent framework: what delivers the most user value while meeting the most critical business constraints? The Scrum Guide backs this up: for Product Owners to succeed, the entire organization must respect their decisions. Handling those stakeholders well is most of the political work.

POs who can’t do this, who let every stakeholder’s priority be “high,” end up with bloated backlogs where nothing is clearly first and the Developers are constantly context-switching. I’ve seen backlogs with 600 “high priority” items. That’s a wish list with a misnomer.

Knowing what customers actually need versus what they say they want. The “faster horses” line usually attributed to Henry Ford (there’s no good evidence he said it) makes the point: customers describe solutions in terms of their current experience. A good PO synthesizes what customers say with what customers do (user research, usage data, support patterns) to identify the underlying needs that features should serve.

A PO who writes user stories directly from stakeholder requests, without any synthesis or interpretation, is a requirements transcriptionist. Ron Jeffries described the story card as a placeholder for a conversation; transcription skips the conversation and produces worse outcomes.

Saying no. The backlog should reflect what the team will build, leaving out most of what anyone has ever suggested. Every item in the backlog represents a future claim on attention and estimation time. An infinite backlog is an abdication of prioritization responsibility.

Effective POs regularly close backlog items that have sat without being prioritized for more than a few months. If something is genuinely valuable, it will come back. If it sat for six months without being prioritized, it probably wasn’t as important as it seemed when it was added.

What Happens When the Product Owner Isn’t Available?

The most common practical failure mode is a Product Owner who isn’t available.

Developers have questions during sprints. The questions are often small (“did you mean X or Y in this story?”) but the answers determine what gets built. When the PO is unavailable (in back-to-back meetings, responding slowly, unclear about answers), one of two things happens: developers make assumptions that may be wrong, or they stop and wait, and work queues up.

Multiply this across a two-week sprint and you get features built to the wrong spec, less delivered than should have been, and developers who are frustrated and disengaged.

The organizational root cause is usually that PO is a part-time role for someone who has a full-time job doing something else. This is a false economy. A part-time PO is a different and worse thing than a cheaper full-time one.

Product Ownership requires roughly as much time as development leadership. If your PO is spending less than half their time on product work, reduce the team size until the PO can serve them properly, or hire a dedicated PO.

What Does a Good Product Backlog Look Like?

A healthy product backlog has roughly three layers:

Top layer (1-2 sprints deep): stories that are refined, estimated, and ready to be pulled into a sprint. These have clear acceptance criteria, have been discussed with the Developers, and any open questions have been answered. This layer gets pulled into Sprint Planning.

Middle layer (1-2 quarters out): epics and features that are prioritized and understood at a coarse level but not yet refined into stories. This layer represents the PO’s current strategic intent, and should line up with the Product Goal the 2020 Guide asks every backlog to serve.

Bottom layer: everything else. Ideas, stakeholder requests, long-term possibilities. This layer is essentially an inbox. The PO’s job is to regularly review it and either move items up toward refinement or delete them.

The failure mode is a backlog where all three layers are mixed together, everything is vaguely prioritized, and nobody is sure what the team should work on next. This backlog didn’t get bad all at once. It accumulated its chaos through months of undisciplined additions and insufficient deletion.

How Should a Product Owner Work With the Developers?

The relationship between the PO and the Developers is the most important daily relationship in Scrum, and it’s the most often neglected.

POs who treat developers as execution resources (“here are the stories for the sprint, build them”) get slower and lower-quality output than POs who treat developers as collaborators (“here’s the problem I’m trying to solve, what’s the best way to approach it?”). Developers know things about technical complexity and user experience that inform what features should actually look like. Excluding them from design thinking is waste.

The practical version: bring developers into discovery work, beyond Sprint Planning. When you’re exploring a new feature area, have a developer in the user research session. When you’re designing something technically complex, have the technical lead in the prioritization conversation. This changes the quality of the conversation on both sides.

Start With a Backlog Audit and Time With Users

If you’re a Product Owner who has been doing this role for more than six months: audit your backlog. Delete everything that hasn’t moved in three months and isn’t related to a current strategic priority. What’s left is your actual backlog. Size it for your team’s capacity.

Then spend more time with users than you currently do. Actual users, rather than stakeholders who represent them. Watch them use the product. Read support tickets. Sit with customer service for an afternoon. That experience, more than any backlog management technique, will make you a better Product Owner.

The role exists to maximize value. You can’t do that without knowing what value means to the people using your product.