Introduction
There’s a fair bit of ambiguity around the Product Owner accountability because it's been done so poorly for so long. Everyone knows they’re supposed to be “maximising value,” but what that looks like in practice is confused. In some organisations, the Product Owner seems to be everywhere, setting goals, working closely with users, and making rapid decisions and behaving in a way that demonstrates they own the product. In others, they’re barely present. They forward stakeholder emails, maintain a loosely ordered Product Backlog, attend Sprint Reviews in silence i.e. at best, they are a passive Project Manager. If you’ve worked in or around Scrum teams for a while, you’ve probably seen both.
So here’s a blunt question worth asking: is your Product Owner actually owning anything? Do they need authority or seek approval before making decisions? This blog explores what ownership really looks like for Product Owners, how to spot when it’s missing, and what can be done to restore it.
Are They Setting the Product Goal?
The Product Goal defines the next meaningful milestone for the product. It connects day-to-day delivery with a broader sense of purpose. Teams that don’t have one will wander from Sprint to Sprint, picking up a variety of independent 'tickets' that may be important in their own right, but do no cohere around a larger focus. The work gets done when it gets done (typically without impetus), but the reason behind it feels vague. This is the Product Owner’s accountability. If they’re not setting and updating a clear Product Goal, th
en they’re not leading the product. Try asking the Developers, "What are we working towards right now?".
A Product Owner without a Product Goal is a captain with no destination. The ship might move, but it’s probably just going in circles (if you like this metaphor, check out Scrum Lake). If the team can’t explain what they’re working towards, beyond just getting stuff done, then there’s a vacuum where direction should be. Sadly, the focus on fighting the current fire leads the Product Owner into Task Manager territory and speaking from personal experience, it's very hard to escape from. Even though it's beyond the scope of this blog, the Three Horizons Model is worth looking into.
Are They Deciding What Gets Worked On?
Let’s be clear: the Product Owner decides what gets built. Not the stakeholders. Not the Developers. Not the PMO. The Product Owner. That doesn’t mean they make decisions in isolation because that would be short-sighted and somewhat arrogant. It does mean they gather input, weigh options, and decide which Product Backlog items are worth pursuing. If every prioritisation decision has to be signed off by someone else, then the Product Owner is a proxy, not an owner. This isn't uncommon, as it's immensely easy to perform this role; on the other hand being a true Product Owner is a real challenge.
Scrum makes this point very clearly:
For Product Owners to succeed, the entire organization must respect their decisions.
Scrum Guide, 2020
That requires judgement, focus, and the courage to say no.
Do They Own the Customer Journey?
It’s hard to maximise value if you’re disconnected from the customer experience. Product Owners should know how users interact with the product, where they struggle, and what brings them delight. Can they even describe what your product does? It's awful, but I've met many Product Owners who couldn't explain their product. They should be able to map the customer journey and spot where it breaks down. This insight should shape their Product Backlog, not just feature requests or internal demands. Too many Product Owners rely on second-hand feedback which is out-of-date and typically inaccurate. They wait for someone else to run usability sessions, gather metrics, or interpret analytics or even task the Developers to do this for them! They keep themselves at a distance which means they’re often solving the wrong problems or solving the right ones too late.
Owning the customer journey doesn’t mean they need to be experts in UX or service design. But they do need to care about the user experience and be active in shaping it.
Do They Build Relationships That Maximise Value?
Ownership isn’t just about the Product Backlog. It’s about relationships, especially with customers. Product Owners who make time for real conversations with users uncover insights that don’t show up in dashboards. They hear the nuance, spot the workarounds, and understand the ‘why’ behind requests. This direct engagement doesn’t just inform the product. It builds trust. Customers feel heard. Feedback loops get tighter and ideas improve.
Product Owners who avoid these relationships, by relying on Business Analysts, support teams, or marketing to be the go-between, miss out. Worse, they become order-takers, not decision-makers. I recently read that Marketing is not a department, because being able to sell the product is everyone's job. Right or wrong, I like the sentiment.
So, What Does Ownership Look Like?
True Product Ownership means:
They define and evolve the Product Goal based on insight, not assumption.
They make ordering decisions based on value and not internal politics.
They shape the product experience by understanding the customer journey.
They engage directly with customers to inform direction and build trust.
If the person called Product Owner isn’t doing these things, then the team is probably working harder than it needs to for less impact than it could achieve.
It's worth saying that it’s not always their fault. Sometimes the role is poorly defined. Sometimes the organisation doesn’t give them the space or authority they need. But without ownership, value suffers.
What Can Be Done?
Scrum Masters have a key role here. They can help teams and leaders understand what Product Ownership actually involves. They can highlight gaps, remove organisational blockers, and support the Product Owner in stepping up. Teams can ask for clarity too. If it’s unclear how decisions are made or what the product direction is, it’s worth raising. Above all, organisations need to stop confusing the title with the role. Calling someone a Product Owner doesn’t mean they own the product. That only happens when they’re trusted to lead it.
References
The Scrum Guide. 2020 Edition
https://scrumguides.org/scrum-guide.html
Scrum Lake: A Visual Metaphor for Scrum
https://www.scrum.org/resources/blog/scrum-lake-visual-metaphor-scrum
Three Horizons for Product Owners
https://www.scrum.org/resources/blog/three-horizons-product-owners