The Indispensable Product Owner

The Indispensable Product Owner

The Product Owner Role Is Being Done Wrong Everywhere

Not broken everywhere — done wrong. The distinction matters. Teams are often performing the ceremonies 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 the Role Actually Requires

The Scrum Guide says the PO is “responsible for maximizing the value of the product resulting from the work of the Development 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. Not by committee, not by whoever argues most loudly, but by applying a coherent framework: what delivers the most user value while meeting the most critical business constraints?

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 development team is constantly context-switching. I’ve seen backlogs with 600 “high priority” items. That’s not a prioritized backlog; it’s a wish list with a misnomer.

Knowing what customers actually need versus what they say they want — Henry Ford’s aphorism about faster horses is relevant here. 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. That’s a lower-value activity than product ownership and it produces worse outcomes.

Saying no — most clearly. The backlog should reflect what the team will build, not everything anyone has ever suggested. Every item in the backlog represents a future commitment of 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.

The Availability Problem

The most common practical failure mode: 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, velocity that’s lower than it should be, 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 not a less expensive full-time PO; it’s a different and worse thing.

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

The Backlog: What Good Looks 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 development team, 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.

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.

The Relationship With the Development Team

The PO-development team relationship 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, not just 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.

My Actual Recommendation

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. Not stakeholders who represent users — actual users. 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.