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

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/who-actually-owns-your-product-why-the-pmpo-split-often-creates-more-confusion-than-it-solves/transcript.md ## Published episode notes Two titles, one product, and a gap in accountability that's quietly costing you more than you think. In this solo episode, Yuval Yeret tackles one of the most common structural problems in product organizations: the split between product manager and product owner that creates ambiguity instead of clarity. Drawing on client patterns across hardware, software, and platform organizations, Yuval unpacks the misunderstanding at the root of this confusion , and makes the case that product ownership is an accountability, not a workload. The result is a practical framework for knowing when one role is enough, when splitting genuinely makes sense, and how to tell the difference. Accountability vs. workload: Product ownership means being accountable for the value the team creates , not writing every story or attending every standup. Confusing the two leads to a split that solves the wrong problem. The proxy problem: When someone gets the product owner title but not real decision-making authority, you've created a proxy. Proxies manage queues. Teams that work with proxies quickly learn the real decisions happen somewhere else. The no test: Can the person who's supposed to own your product say no to a feature request without escalating? If not, the structure isn't supporting the accountability. "Product ownership doesn't mean doing all the inbound work yourself. It means being accountable for the value the team creates. Owning the outcome." "When you split the role and give someone the product owner title but not the real decision-making authority , when they're essentially relaying direction from the product manager to the team , you've created a proxy. Someone who manages a queue rather than owns a product." "Teams pick up on this pretty quickly. They learn that the real decisions happen somewhere else. So they start going around the product owner, escalating directly, or just making calls themselves and hoping it works out." If you're not sure whether your product org is set up to make real product decisions or just manage requests, that ambiguity is worth resolving. Experiment to try this week: Ask your product owner (or product manager) to say no to the next non-critical feature request that comes in , without checking with anyone first. Watch what happens. The reaction will tell you whether the authority matches the title. Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As both a SAFe Fellow/SPCT and Professional Scrum Trainer, Yuval is frequently brought in to help organizations evolve from agile theater and feature factories toward product-oriented agility , building on existing investments rather than starting over. 📩 Start here: Scaling w/ Agility Crash Course , a free email course to help you scale without falling into the process theater trap. 🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret ## 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. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.