I rarely start blogs with a disclaimer, but I'm about to do just that. When reading the content below, it may sound cruel to those calling themselves Product Owners but that is not my intent. Much like poor Scrum Mastery is rightly called out as simply facilitation, a colourful Sprint Retrospective template and asking the team 'how they are feeling', poor Product Ownership equally deserves to be discussed, so that is what I have aimed to do.
Introduction
Scrum positions the Product Owner as the person accountable for maximising the value of the product, but a common mistake is that it's a managerial or oversight only role. It is not just about writing Product Backlog items or attending Product Backlog refinement - frankly, if it was, sign me up! It is a strategic function, one that carries the weight of purpose, direction, and prioritisation of company and customer requirements. Yet, in many organisations, Product Owners operate with neither a strategy nor the mandate to shape one. They manage features, not results. They execute independent requests, not product intent.
Being a Product Owner is difficult work. But what many Product Owners are doing is remarkably easy. The real challenge of the role lies not in owning the Product Backlog or attending events, but in defining what matters, resisting distractions, owning stakeholder communications, and holding a clear line between effort and value. Without having a strategy though, that line disappears.
The Illusion of Ownership
It is common to find Product Owners who are diligently maintaining a Product Backlog, ensuring PBIs are “ready” for the next Sprint. They gather inputs from stakeholders, convert those into epics and stories (if we're using Jira), maybe event facilitate Sprint Planning with a roadmap in hand. On the surface, it appears they are fulfilling their accountability. The Product Backlog is well-looked after, events are on schedule, and features are delivered incrementally. But this output often hides a deeper problem: the absence of any intent because simply, they don’t have one beyond surviving from one day to the next. I often refer to this in a similar way to how it looks when a Scrum Master is facilitating every event. They are definitely visible, but are they useful?
A Product Owner should know what problem the product is solving. When starting a new consultancy recently, the first question I needed to answer was 'Why does my product exist?'...and after three weeks, I couldn't answer it despite a £1.8mpa budget. So what did I do? I started the preparation for a graceful shutdown. A few questions to ask your Product Owner:
How is value being measured?
What do our users dislike the most about our product or delivery process?
How is the current Sprint contributing to the long-term direction of the product?
What changes can a user expect to see in the next 6 months?
When I've asked similar questions in the past, the answers are often vague, speculative, or simply unaddressed. In some cases, there is no Product Goal. In others, it exists in name only, disconnected from decisions or priorities and usually in a list with three of four other 'priorities'. Without clarity on why the Scrum Team is building what they are building, the Product Backlog will become hollow. Scrum is empirical, not mechanical. It is built on learning and adaptation. This only works when there is a clear hypothesis to inspect against. Without strategy, the Product Backlog becomes an unexamined ledger of obligations, a record of who asked for what, not why any of it matters. The team may deliver features, but they do not necessarily deliver outcomes.
Many Product Owners function as intermediaries, and are sometimes called 'proxies'. They collect requests, resolve conflicts, translate stakeholder desires into PBIs and then sit back and do little else. Their primary concern is throughput. Is the Product Backlog well refined? Are the Developers going to deliver when they said they would? In many organisations, this version of the accountabilitiy is not only accepted but encouraged because it more closely aligns with a Project Manager or Delivery Lead (which are typically more accepted responsbilities). This mode of working is manageable. It is comfortable. It is also inadequate. The Product Owner is not there to manage 'the list'. They are there to challenge its validity. Strategy requires prioritising one thing over another, not just arranging items in order of stakeholder urgency.
The shift from requirements owner to value maximiser is not semantic. It is structural and demands that the Product Owner resists being a messenger and instead becomes a decision-maker. It means actively shaping the Product Goal, framing trade-offs, and rejecting ideas that do not advance the strategy, even when they come from influential voices. Stefan Wolpers has written about how easily this role becomes performative when strategy is absent and expectations are fixed around delivery mechanics rather than impact.
The Cost of Passive Ownership
In Scrum Teams where the Product Owner has no strategy, several patterns emerge. Sprint Goals are improvised or generic, often describing the activity to be performend rather than the intended outcomes. Work is evaluated by how much was completed, not by what changed for the user or the business - it's sad. The Product Backlog reflects legacy assumptions and feature requests, with minimal inspection. It's a list of 'jobs to be done'. Developers are disconnected from customer context and rely entirely on the Product Owner for clarity, which they may not have. Sprint Retrospectives reveal delivery issues but seldom surface questions about product direction, because that direction has never been made explicit i.e. the Scrum Team don't even know what it's like to have one!
These are not signs of immature teams but signs of misaligned leadership. When the person accountable for value does not act as such, the team adapts around them. They continue to work efficiently, but the cohesion behind that work erodes. The organisation may still consider the team successful based on their output but the gap between activity and strategic contribution continues to grow. Over time, this erodes trust in the product and reduces the willingness of stakeholders to invest in Scrum as a vehicle for actual change. You may have come across this concept in the form of 'it's all Scrum's fault'.
Strategy as a Practice, Not a Plan
Real product strategy is not a vision deck or a quarterly roadmap delivered to stakeholders or simply stored in a Sharepoint archive. It is not defined by timeline templates or Initiative Backlogs. Strategy is a working model of value, testable, adjustable, and deeply embedded in day-to-day decision-making. The Product Owner does not need to be a visionary. But they do need to understand how value is created, the constraints of the environment, and the signals from the market. Value creation is a blend of human sensors and a scientific process. In one of John Coleman’s blogs (which I've added in the section at the bottom) he talks about how the emphasis on proximity to stakeholders and users reinforces this point on understanding value creation. Distance leads to incoherence and strategy begins with contact.
This understanding cannot be borrowed or faked. It must be built through discovery, engagement, and evidence. Product Owners who treat the Product Backlog as a 'list to maintain' will miss the opportunity to adapt based on what they learn. Those who embrace discovery see Product Backlog refinement as more than technical elaboration because it becomes a process of narrowing/reducing uncertainty and risk. This includes, but is not limited to:
- Talking to users and customers regularly.
- Collaborating with Developers to shape valuable experiments.
- Interpreting feedback loops from incremental delivery.
- Aligning Product Backlog refinement with product learning, not only readiness.
- Protecting the Product Goal from dilution or confusion.
This type of work is hard. It requires saying no to well-intentioned stakeholders. It requires being comfortable with ambiguity and resisting the pressure to fill every Sprint with feature work. And it requires defending focus in organisations that often reward volume over insight (in my experience, this is most of them, irrespective of what they tell you they care about).
Reframing the Accountability
The Scrum Guide is unambiguous: the Product Owner is accountable for maximising value. That accountability cannot be exercised from a place of neutrality. It requires owning trade-offs, navigating competing interests, and defining success in terms of outcomes, not features.
Doing what most Product Owners do today, facilitating, documenting, and coordinating, requires discipline, but not strategic leadership. It sustains delivery, but it does not challenge the organisation to build the right thing. It ensures the Scrum Team is active, but not necessarily effective (effectiveness vs. efficiency is something I'm keenly interested in). This distinction is crucial. Because while being a Product Owner is hard, doing what many Product Owners currently do is not. And until that gap is addressed, the potential of Scrum will remain untapped.
Conclusion
A Product Owner without strategy is not just underutilised. They are fundamentally misaligned with the role Scrum describes. They may be effective in delivery terms, but ineffective in product terms. They may satisfy stakeholders, but fail their users. The damage is subtle but significant. When a Product Owner stops asking “why,” the team slowly stops caring about the answer.
The solution is not more process, nor more documentation. It is to restore the Product Owner to their proper function as a value maximiser.