Data Product Owner: A role or a workaround?

I’ve been thinking about the Data Product Owner role for a while now, and the more I look at it, the more uneasy I become. Not because the intent is bad. Not because the people in the role are incompetent. But because the role itself feels like something that only exists because other things didn’t scale the way they should have.

The idea starts innocently enough. Data should be treated like a product. Products need owners. So we create a Data Product Owner. On paper, it sounds neat. Almost obvious. But the moment this role lands on an org chart, reality intervenes.

• What exactly does this person do?
• What decisions can they make without asking someone else?
• Where does their authority actually come from?

And the answers are never clean.

The scavenger role

What’s interesting is that the Data Product Owner role didn’t come from a framework. There is no clear definition everyone agrees on. No standard reference. No obvious boundary. It wasn’t designed top-down. It appeared bottom-up, as a response to discomfort.

Things were falling through the cracks. Ownership wasn’t clear. Handovers were messy. Governance existed, but mostly on slides and documents. So instead of fixing the structure that caused those gaps, we placed a person in the middle and assumed the problem was solved.

For a while, it even feels like it works.

Someone is finally “on it”. Someone follows up. Someone connects dots. Someone makes sure nothing is forgotten. But slowly, the role morphs into something else entirely. It becomes the place where unresolved things go. The person who picks up what others drop. The role that absorbs ambiguity.Not because that’s the job description, but because someone has to do it.

At that point, it stops being ownership and starts being scavenging.

Accountability without Authority

What makes this worse is that the role carries expectations it can’t realistically meet. It’s called a product owner, but it doesn’t own delivery. It doesn’t control engineering capacity. It doesn’t decide priorities end-to-end. To get anything done, it has to negotiate with IT, platforms, shared delivery pools.

Functionally, it behaves like any other stakeholder to IT. Just with a more ambitious title.

Calling it a product role doesn’t magically give it product power.

From inside the role, I can see why a certain belief starts to form: that the organisation itself is the problem. That if only everything were organised around products, things would finally make sense. I understand that instinct. If you’re given product-shaped accountability inside a non-product organisation, you naturally want the world to change shape around you.

It’s a nice idea. It’s also naive.

Organisations don’t only consist of products. They consist of shared services, regulatory obligations, legacy systems, risk controls, and constraints that don’t bend just because we want them to. You can’t product-model your way out of institutional reality.

Where it actually works

What’s telling is that in the few places where the Data Product Owner role actually works, nothing fundamentally new was introduced. Those organisations were already product-driven. Delivery authority already existed. Teams already owned their capacity. Platforms already enforced governance by design.

In those cases, “Data Product Owner” is just a relabelled Product Owner with a data-heavy scope.

The role works because the structure already supports it.

Everywhere else, it doesn’t.

The structural test

That leads me to a simple test I keep coming back to: if existing structures actually scaled, would this role be necessary? And if the answer is no, then the role isn’t a sign of maturity ,it’s a sign of deferred design.

Strong ideas don’t need permanent roles to keep them alive. If a concept only works because someone is constantly there to remind, translate, chase, and patch things up, then the concept isn’t embedded. It’s bolted on.

Organisations don’t scale by adding people whose job is to absorb complexity. They scale by fixing the structure so that complexity doesn’t need to be absorbed in the first place. By strengthening existing roles. By clarifying authority. By moving rules out of people and into systems.

The reflection

Seen through that lens, the Data Product Owner isn’t a framework. It’s not a necessity. It’s a loose idea that people hope will solve problems until it collides with an org chart and the questions start.

In that sense, the role behaves like organisational technical debt.

Useful in the short term. Costly in the long term. A signal that something more fundamental was postponed. This isn’t about blaming individuals. It’s about being honest with design choices.

And like any form of technical debt, the real solution isn’t to defend it ,it’s to fix the structure so the role quietly disappears.