# Who Actually Owns Your Product? Why the PM/PO Split Often Creates More Confusion Than It Solves: transcript

This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage.

Episode: https://yuvalyeret.com/scaling-ai-podcast/who-actually-owns-your-product-why-the-pmpo-split-often-creates-more-confusion-than-it-solves/

## The friction around product operating model

Here's something I get asked pretty regularly. We have both a product manager and a product owner and we're not sure we need both. What's the difference and does it matter? It's a fair question and the honest answer is it depends, but probably not in the way that you'd expect. A lot of organizations end up with two people, two titles, one product, and more confusion than they had before they introduced either role.

And it's not because the people are wrong, but because the setup creates ambiguity around who actually owns the decisions. I'm Yval, welcome to another episode of Skill and With Agility. So let's think through when one roll is enough, when splitting makes sense, and what goes wrong when you split it without being clear what you're actually splitting. Here's the pattern that I see most often. A company has a product manager.

They own the roadmap, they talk to customers, they think about the market. They're working reasonably well. From or agile gets introduced and with it comes this role called the product owner and it starts to sound like It might need to be a different person Someone closer to the team or focus on the day-to-day writing stories grooming the backlog answering the team's question the product manager doesn't feel comfortable Doing all of these things they want to stay focused on outbound So the company splits the role. The product manager goes outbound. The company finds somebody, typically from the engineering organization, or just hires for the role, that goes inbound.

Two people, two titles, but with one product. And then the question starts to emerge, who actually decides what the team should work on next. What if there is a conflict between the longer-term road of direction and what's being asked of the team day-to-day, who sorts that out? When a stakeholder wants something added, who do they call? Often the answer is whoever they can reach, whoever they feel comfortable talking to.

## What is really happening in the system

And what that typically means is that engineering and conversations between different product teams often go to the product owner and requests from the market, from customers, go through the product manager, which creates two paths into the team. This approach, where the product direction starts getting driven by two people, can work if these people are really in tune, are aligned on the goal, on the strategy for the product. But it's often starting as a misunderstand, but more often than not, this creates more confusion than clarity. There's a misunderstanding that's at the root of a lot of this, and I want to call it out. When we say product ownership, the accountability that Scrum describes, that doesn't mean doing all of the work that I talked about earlier.

It doesn't mean doing all of the inbound or team-facing work yourself, it doesn't mean writing every story or being available to the team, day in and day out. It just means being accountable for the value that the team creates owning the outcome. Hey, owning is even in the name, yet we see a lot of product owners that don't really own anything other than the backlog of stories. That's not what product ownership is about. If you have a capable team, they can handle a lot of the breakdown work the day to day themselves.

They can figure out how to slice a feature to write acceptance Hetteria to think through sequencing and dependencies. That's what a good product team does. The product person's job is to make sure the team is building the right thing and the direction is clear, not to do the team's job for them. So a lot of the resistance product managers have to take on to taking on product ownership roles, The worry that it means to become a full-time backlog administrator is based on a version of product ownership that isn't really what it needs to be. The accountability is real that day-to-day workload doesn't have to hear where this gets expensive.

When you split the role and give somebody the product owner title, but not the real decision-making authority, where they're essentially relaying direction, playing a broken phone, game from the product manager to the team, sometimes there's even the inability to talk to customers. The product owner is not allowed to talk to customers. You've created a proxy. Someone who manages a queue rather than owns a product. And the team speak up on this pretty quickly.

## The practical shift

They learn that the real decision happens somewhere else. So it starts to be a charade. A theater around the scrum, you know, practices in the product owner. And the real conversations start to happen through escalations to product managers. And that's not a reflection on the person in the role, it's a structural problem.

The title implies ownership, but the setup that most organizations come up with doesn't support it. And in that gap, we start to see friction that shows up as escalations, we still find it in a team that doesn't have one source of truth. For one product, one team, there are really two setups that I've seen work well. The first is one person who genuinely owns the whole thing. The product manager was empowered to own the product.

Market wrote that the relationship with the team, they don't have to be in every stand-up or answer every technical question, but they're the person that the team looks to for direction. And they have the authority to make that direction stick. Most good product managers can do this well if the organization actually gives them the space to. The second is a genuine split, an honest one. If you have somebody focused on outbound and somebody focused on inbound, let's be clear that the onbound person owns the product direction and that the inbound person is supporting execution, helping the team move quickly, keeping things clear at the team level.

It's a valuable role, just don't give it a title that indicates ownership, not ownership of the product. It implies something that the role doesn't have. have, it creates, you know, a disanounce, a simple way to test where you are. Is to ask yourself, can the person who's supposed to own your product say no to a feature request without needing to escalate? If not, it's worth looking at what's getting in the way.

## What leaders should pay attention to

One product, one team, is in some ways the simplest version of this question, and usually is manageable. Once you're honest about where the accountability actually lives and where the structure is set up the scope. Next episode we'll talk about the scenario where we have multiple teams, but let's first fix the one team structure. If you're working on figuring out product apology in your organization, I'm happy to have the conversation. So here, how are you thinking through it and see if I can help you get some clarity.