"The Product Owner – The Most Misunderstood Role"

December 2025 10 min read Opinion + Experience

The Product Owner is the most pivotal role in Scrum. It is also the one most consistently stripped of the authority it requires to function. What remains after the authority is removed is not a Product Owner. It is a backlog administrator with an impressive job title.

---

The Hook: A Role Without Power Is Not a Role

Ask ten organisations to describe their Product Owner’s responsibilities. You will get ten similar answers: owns the backlog, prioritises stories, attends ceremonies, communicates with stakeholders. Ask those same ten organisations whether their Product Owner can unilaterally change a sprint priority without management approval. Whether they can say no to a senior stakeholder’s feature request. Whether they can cancel a sprint if the Sprint Goal becomes obsolete.

Watch how many hands stay up.

The Product Owner role, as defined in the Scrum Guide, is one of the most demanding in any software organisation. It requires genuine decision-making authority, deep product knowledge, constant stakeholder engagement, and the political courage to say no to powerful people on a regular basis. What most organisations have created instead is a coordination role dressed in Product Owner clothing – and then wondered why their product development is slow, unfocused, and disconnected from what customers actually need.

---

The Reality: What Most Product Owners Actually Are

In the course of twenty years working in enterprise environments, I have worked with Product Owners who ranged from genuinely exceptional to actively harmful. The distribution is not encouraging. Here are the four most common Product Owner archetypes I have encountered – none of them are what the Scrum Guide describes.

Archetype 1: The Proxy

The most common variant. The real decision-maker – a senior manager, a director, a “business owner” – does not have time to engage with the team directly. So they appoint someone more junior to be the Product Owner. This person attends ceremonies, maintains the backlog, and writes user stories. For any significant decision – prioritisation changes, scope trade-offs, strategic direction – they must go back to the real decision-maker for approval.

The result is predictable. Decisions that should take hours take days. The team waits. Dependencies accumulate. The backlog reflects what the real decision-maker last said they wanted, which may or may not reflect what customers actually need. The Product Owner is in every meeting but has authority in none of them.

Archetype 2: The Committee Secretary

Worse than the Proxy. Instead of one real decision-maker behind the scenes, there is a committee. The Product Owner attends steering group meetings, captures decisions, and translates them into backlog items. They are, in effect, the interface between a group of people who cannot agree on priorities and a development team that needs clear priorities to function.

The Product Backlog in this scenario reflects political compromise rather than strategic clarity. The highest-priority items are the ones that generated the least committee disagreement, not the ones that deliver the most value. The team builds what the committee can agree on. Customers get what the committee can agree on. Nobody is surprised when the result does not match what the market actually wants.

Archetype 3: The Feature Collector

This Product Owner has genuine access to stakeholders and a genuine interest in understanding their needs. The problem is that they treat every stakeholder request as equally valid and equally urgent. The backlog grows continuously. Priorities shift with every stakeholder conversation. The team never finishes anything because the definition of “most important” changes faster than the team can deliver.

The Feature Collector is often well-liked and well-intentioned. They are responsive to stakeholders, they have relationships across the organisation, and they work extremely hard. They are also, systematically, preventing their team from delivering value by failing to make the difficult prioritisation decisions that are the core of the Product Owner role.

Archetype 4: The Technical Backlog Manager

Common in technology-led organisations. This Product Owner is often a former developer or technical lead who has been promoted into the role. They understand the technical work deeply and write excellent user stories. What they lack is the business and customer perspective that should drive prioritisation. The backlog is technically coherent and strategically adrift. The team builds things that work beautifully and that nobody asked for.

The common thread: All four archetypes share one characteristic – they are filling a Product Owner shaped gap without having the authority, the mandate, or the customer proximity that the role actually requires. The organisation has the title. It does not have the role.

---

The Checksum: What the Scrum Guide Actually Requires

The 2020 Scrum Guide is unambiguous about the Product Owner’s accountabilities. Three things stand out as consistently violated in practice.

Single Person, Not a Committee

The Scrum Guide states explicitly: “The Product Owner is one person, not a committee.” It goes further: “Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.” Not by emailing the steering group. Not by escalating to the Product Owner’s manager. By convincing the Product Owner.

This requires the Product Owner to have genuine authority – and genuine organisational backing for that authority. In most organisations, that backing does not exist. Senior stakeholders who cannot get their feature prioritised go around the Product Owner to their own senior contacts. The Product Owner’s decisions are overridden. The role becomes meaningless.

Ordering the Backlog, Not Just Maintaining It

The Scrum Guide says the Product Owner is responsible for “ordering” the Product Backlog – not just maintaining it or grooming it. Ordering implies active, continuous prioritisation based on value. It implies saying no to things that do not make the cut. It implies the courage to have a backlog where item 47 will probably never be built, and to be honest about that.

Most Product Backlogs are not ordered. They are accumulated. Items are added at the top when stakeholders are urgent, added at the bottom when stakeholders are polite, and shuffled in the middle when nobody is looking. The Product Owner manages the additions. They do not make the hard decisions about what will never be done.

Accountable for Product Value

The Scrum Guide makes the Product Owner accountable for “maximising the value of the product resulting from the work of the Scrum Team.” This is an outcomes accountability, not an activities accountability. The Product Owner is not accountable for maintaining a healthy backlog, for attending sprint reviews, or for writing well-structured user stories. They are accountable for whether the product delivers value.

Almost no organisation holds their Product Owner accountable for product value. They are held accountable for backlog hygiene, for story quality, for stakeholder satisfaction. Value delivered to customers is measured – if it is measured at all – at a level far above the Product Owner’s pay grade.

“A Product Owner without authority over their backlog is like a chef without access to the kitchen. The title is accurate. The job description is not.” Markus – agile-checksum.com

---

Real-World Examples: The Gap in Practice

The Overridden Priority

A Product Owner at a large logistics company had carefully ordered her backlog based on customer research, revenue impact analysis, and technical dependency mapping. The highest-priority item was a customer-facing tracking feature that research showed would reduce support call volume by an estimated 30%.

Two weeks before the sprint in which this feature was planned to start, a senior sales director requested that a different feature – an internal reporting dashboard he needed for a client presentation – be moved to the top of the backlog. The Product Owner explained the prioritisation rationale. The sales director escalated to her manager. The manager told her to accommodate the request. The tracking feature was delayed by two sprints. The reporting dashboard was built and used once.

The Product Owner had done everything correctly. The organisation had demonstrated, unambiguously, that her authority extended exactly as far as senior management was willing to support it – which was not very far at all.

The Backlog With 600 Items

A Product Owner I coached inherited a backlog with 623 items. The oldest items were four years old. Nobody had looked at them in years. The Product Owner spent significant time every sprint in backlog refinement sessions, estimating and discussing items that had no realistic prospect of ever being built.

When I suggested deleting everything older than eighteen months that had not been discussed in the last quarter, the response was horror. “We can’t delete those – stakeholders requested them.” When I asked whether those stakeholders still worked at the company, still had the same priorities, or would even remember making the requests, the answer was uncertain. The backlog had become a museum of past conversations, maintained out of political anxiety rather than strategic intent.

We deleted 340 items. Not a single stakeholder noticed. Not one complaint was received. The team’s planning sessions became 40% shorter. The Product Owner spent that recovered time talking to customers. The next quarter’s delivery was the most focused and highest-value in the product’s history.

The Product Owner Who Was Never Wrong

A Product Owner at a fintech startup had strong opinions and a persuasive personality. He was effective at getting his priorities into the sprint. He was less effective at validating whether those priorities were correct. Customer feedback from sprint reviews was filtered through his existing convictions. Data that contradicted his product intuition was explained away. The team built what he wanted, consistently and efficiently.

After eighteen months, a competitor launched a product that addressed several customer needs the team’s product had consistently deprioritised. The market response was significant. When I was brought in to assess the situation, I found a product that was technically excellent, efficiently delivered, and increasingly misaligned with what customers actually needed. The Product Owner had been maximising his own product vision. He had not been maximising value.

---

What a Genuine Product Owner Looks Like

Genuine Product Owner	Common Substitute
Can say no to a senior stakeholder without escalating	Needs management approval to change any priority
Makes prioritisation decisions based on value evidence	Prioritises based on stakeholder volume and seniority
Actively deletes backlog items that will never be built	Maintains every requested item indefinitely
Attends sprint reviews to get feedback, not to present	Uses sprint reviews to demonstrate progress to management
Measures success by value delivered to customers	Measures success by backlog health and story completion
Spends more time with customers than in refinement meetings	Spends most time managing stakeholder requests and backlog items

---

The Takeaway: Fix the Authority Problem First

Most Product Owner problems are not Product Owner problems. They are organisational authority problems that manifest in the Product Owner role. The person in the role is frequently doing the best they can within constraints that make the role impossible to perform correctly.

If you want a functioning Product Owner, the questions to answer are organisational, not individual. They are questions about whether the organisation is willing to give one person genuine authority over a product’s direction. Whether senior stakeholders are willing to make their case to a Product Owner rather than around them. Whether management is willing to back the Product Owner’s decisions even when those decisions are inconvenient.

Those are not easy questions. They require organisational change, not training programmes. A Product Owner certification course does not give anyone authority. Only the organisation can do that.

Run the checksum on your Product Owner:

1. Name the last time your Product Owner said no to a senior stakeholder’s request and the decision held without escalation.
2. How many items in your current Product Backlog have not been discussed in the last three months? What is the plan for them?
3. What metric does your Product Owner use to measure whether last sprint delivered value? Is it a business outcome metric or an activity metric?

The answers will tell you whether you have a Product Owner or a backlog administrator. Both can be useful. Only one of them is what the Scrum Guide describes.

“The Product Owner role is not a coordination role. It is a leadership role. Treat it as one – or do not be surprised when your product goes nowhere in particular, very efficiently.” Markus – agile-checksum.com

---

Glossary Terms Used in This Article

• Product Owner – The Scrum accountability responsible for maximising product value and managing the Product Backlog.
• Backlog – An ordered list of work items representing everything a team might work on.
• Scrum – A lightweight framework for developing and delivering complex products.
• Sprint Review – A Scrum event where the team and stakeholders inspect the Increment and adapt the Product Backlog.
• Definition of Done – The shared agreement on what “complete” means for a product increment.