# When One Product Needs More Than One Leader: Getting Multi-Team Product Ownership Right: 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.