Everyone on the product team says they care about the user. The Product Owner talks to customers. The UX designer runs interviews. The account manager reports complaints. And somewhere in that cloud of good intentions, nobody is actually responsible for them.
A Product Owner came to me with a problem. Some users were complaining about certain features. He had already done research, already drawn a conclusion, and was ready to move ahead. A reasonable man doing a reasonable job. I asked who those users were. What exactly they were struggling with. What they actually needed versus what they said they needed. He didn’t have those answers.
We went back to the customers together and within twenty minutes he heard something his own research had missed entirely. His reading of the complaint and the customer’s own reading were slightly out of step. There was noise in the translation, and that noise was the real problem — not the feature. Not because he did it wrong, but because user research is a craft, and asking questions and interviewing are two different things.
The ownership problem that rarely gets said out loud
The deeper problem is in how the collaboration gets framed. The product belongs to the PO. Which in practice means: UX works for him. It’s rarely said out loud, but it colours every interaction, every escalation, every moment where a decision could go either way.
The trouble with that framing is that UX insight carries a different kind of authority. It comes from users. Not from interpretation, not from stakeholder intuition, but from what people say and do when you sit next to them. That isn’t a deliverable you pass up the chain. It’s a foundation that determines what the product should be in the first place.
Shared ownership isn’t a compromise. It’s an accurate description of how good product development actually works.
When the overlap becomes a data quality problem
On another project I found out the PO had been running user interviews himself. Not out of bad faith. He was being proactive, filling what he saw as a gap. But I had no idea how he had phrased his questions. Whether they were leading. What framing he had used. What he had left out.
That isn’t a collaboration problem. That’s a data quality problem. Insights from badly designed interviews can send you in exactly the wrong direction and you only find out once you’ve already built the wrong thing.
I can’t stop a PO from talking to users and I wouldn’t want to. But there’s a crucial difference depending on complexity. If a button doesn’t work, that’s clear enough: the report tells you what you need. But if a user doesn’t understand something because the way a feature works is unclear, you need context. You need to know which questions were asked, in what order, with what framing. Then the answer is: do it together, or make sure I understand the protocol before I build on the results. Not as a control mechanism, but as quality assurance.
What the research says — and what it doesn’t
The Nielsen Norman Group has studied both sides of this relationship in depth. One finding stands out: UX practitioners experience the most overlap, not just from product managers, but from other UX people too. This isn’t a one-sided problem. It’s a structural one that affects everybody, and that everybody half-solves by doing what seems logical, until it collides with what the other person also thought was logical.
NN/g’s recommendation is concrete: at the start of a project, get the whole team together and fill in, jointly, who is responsible, who gets consulted, and who decides. A light-touch RACI, you could call it. Not as a bureaucratic document, but as the conversation you’d otherwise never have. No heavy methodology, just making the agreements everyone assumes have already been made.
What you’re actually protecting
A UX designer who isn’t spending energy defending their scope can spend that energy on quality. A Product Owner who isn’t second-guessing whether user interviews fall under their remit can focus on vision and prioritisation. The overlap doesn’t disappear, but both people know exactly where they stand.
The teams that get this right don’t have the best process. They’re just willing to have a small awkward conversation early, so they don’t have to have a big awkward one later.
The user is better off when someone is responsible for understanding them. Not when everyone vaguely is.
Nielsen Norman Group:
nngroup.com/articles/pm-ux-different-views-of-responsibilities/
nngroup.com/articles/ux-product-managers-overlap/
nngroup.com/articles/ux-roles-responsibilities/