When One Product Needs More Than One Leader: Getting Multi-Team Product Ownership Right

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/when-one-product-needs-more-than-one-leader-getting-multi-team-product-ownership-right/transcript.md ## Published episode notes The question isn't how many product owners you need. It's how many genuine product problems your product actually has. In the final episode of this three-part series, Yuval Yeret works through the most complex version of the product ownership question: what happens when a product has grown to multiple teams? The default answer , one team, one product owner , often creates titles without real ownership, especially when teams are organized around technical components rather than product value. Yuval walks through when multi-team product leadership genuinely works, when it doesn't, and what the more uncomfortable conversation underneath usually turns out to be about. This episode lands the series with the most structurally challenging scenario, and connects product ownership topology directly to team design , one of the most consequential and often avoided conversations in scaling organizations. Essential listening for product directors, heads of engineering, and CTOs navigating a growing product org. The right question: Not "how many product owners do we need?" but "how many genuine product problems does this product have?" , a reframe that clarifies the structure instantly. Mini-products inside a larger product: When teams are organized around real, independently deliverable slices of product value, multi-leader structures work well. The razor example makes this concrete: shaving experience, handle design, packaging, and price viability are all genuine product problems that can be owned semi-independently. The symptom vs. the diagnosis: If your teams can't deliver value independently, giving them product owner titles won't fix it. The ownership problem is a symptom. The team design problem is the diagnosis. "Product ownership only really makes sense when a team can deliver something of genuine value independently. When they can take a customer problem, work on it, and ship something that actually moves the needle , without needing three other teams to complete it first." "Giving each of those teams a product owner doesn't change the underlying dynamic. It adds titles without adding real ownership. And what you often end up with is product owners who feel like they should have more authority than they do, and teams that are still fundamentally waiting on each other." "If your teams can't deliver value independently, the product ownership question is a symptom. The underlying question is whether the team structure is set up to enable that kind of independence , and if not, what it would take to get there.", Yuval Yeret Related reading on yuvalyeret.com: When and Why Do We Need a Product Operating Model? Are your teams structured around genuine product problems they can own end to end? Or around technical components that make independent ownership hard? Experiment to try this week: Pick one team in your product org. Ask them: what's the last thing you shipped that delivered value to a customer without depending on another team to complete it? If they struggle to answer, you have a team design question hiding inside your product ownership question. 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/when-one-product-needs-more-than-one-leader-getting-multi-team-product-ownership-right/ ## The friction around product operating model So your product has grown. You've gone from one team to several. It's great. You're starting to scale. And at some point, somebody asked, OK, does each team need its own owner, its own product owner? It seems like the obvious answer is yes, one team, one product owner, clean accountability. But in practice, it's a bit more nuanced. Sometimes it works really well. Sometimes you end up with a bunch of people with ownership titles who are mostly managing queues and coordinating. which isn't really what product ownership is about. It's just coordination with a better job title. I'm Yvaly Arett, welcome to Scaling With Agility. So the real question isn't how many product owners you need, it's how many genuine product problems your product actually has. That's what I want to dig into today. When a product grows to the point where multiple teams are working on it, there's a temptation to map the org chart directly to the product ownership structure. Each team gets a product owner, the product owner reports in an hierarchy, and on paper it looks clean. The problem is that product ownership only really makes sense when a team can deliver something of value independently, real value independently. When they can take a customer problem, work on it and ship something that actually moves the needle, like an impact, without needing three other teams to complete it first. If your teams are organized that way, then yes, each team having its own product, point of contact, product leader can work well. You're essentially got mini-product inside the larger product and it's structured reflects them. ## What is really happening in the system But if your teams are organized by a technical layer front and team, back and team, data platform, then or whatever's the mapping in your world, then no individual team can really deliver value on their own. They deliver pieces, slices of those custom-oriented features. And product ownership for these teams end up being less about product direction and more about managing what's coming in from other teams and what's going out. And in that environment, you often see product managers that are refusing, legitimately refusing, to take ownership of these teams. They don't really care about the inside work that's happening on these teams. They care about the holistic view, the systemic view, the aggregation, the integration of what these teams are. So let's look at a case study. So think about developing a new razor. You've got the shaving experience itself, blade design, the quality of the shave, you've got the handle, all the materials, the economics in the shower, you've got the packaging, the sustainability story, you've got the price point and the business liability. Each of those could be seen as a real product problem. Each one has its own customers, its own trade-offs, its own definition of what good looks like. A team focused on the shaving experience can make progress independently. A team focused on business viability can run their own analysis, P&L, and experiments. That's a set up where multiple product leaders really make sense. Each one of them can own something real. They can move without waiting for the others, at least most of the time. And there's still somebody that owns the whole razor, making sure that the design is compatible with the handle, that the price band works, that all of this holistically is a product we have the right to believe will succeed in the market, that customers will find delightful, that they would buy at a price that will be creating value for our enterprise. That overall product leader role doesn't go away, it actually becomes more important as we have more and more teams with more and more complexity in that. So in that case, it actually makes sense to have one product owner, one product leader, Bertie. The harder case, which is more common, is when teams are organized around technical components, rather than customer product value. ## The practical shift In that structure, teams depend on each other heavily. The front-end team can't really ship without the backend. The features team can't move without the platform. Product ownership in that context is mostly about sequencing work and managing dependencies. Even when you're owning an internal system, an internal API, a lot of the time, product ownership for that API is about the needs of other systems in the enterprise, in the architecture, not really the needs of custom. in some environments it makes sense to create the product owner for these internal teams. In other cases it doesn't. If those teams are most of the time acting as a service provider to other teams, managing dependencies from the other teams and just doing the work and integrating with other teams, product ownership is really meaningless for these teams. It's not really owning a product. What changes is if this team starts to act as platforms. If the work for these teams or at least what you want to see as the work from this team is more horizon work, building the ability for other teams to self-serve, to create APIs, to minimize the dependencies that the team has on others, then this is where real product ownership is useful that product ownership will be thinking about the experience of working with the team and improving it and optimizing it all. So if you have these teams that are just working on unreal backlog and they don't really have their own product goals and horizons on their own, it makes sense to have one with delivery, engineering leads, whatever you want to call these roles that focus on the execution, the interaction in between these teams. Fewer product ownership titles and clear about where the real product decisions you've. If you have more and more platform teams, then it makes sense to create product ownership. For them, and minimize the dependencies, it goes together. The underlying question is the interaction between your product architecture and your product ownership topology. to need to be aligned. ## What leaders should pay attention to They don't live well on their own. So the question we're thinking about is in your product organization, are your product teams and the ownership structure around them, structured on genuine product platforms or genuine product problems, or are they just components that constantly need to work together to deliver value? Neither answer is wrong. There are often good reasons for maintaining a certain structure. What's important is to align the product ownership topology with the product architecture, with the technology approach you have. Honesty and transparency around where you are on these both helps clarify what kind of product leadership you actually need versus just copy cutting something from the book or doing it because that's how things are done in some sort. I hope this was useful for you. If you haven't had a chance, check out previous episodes that talk about one team one product as an internal platform with competing stakeholders, as well as the episode on multiple teams and multiple leaders. If any of these hits too close to home, I'd love to hear what you're wrestling with. I'm Yvall. ## 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.