Product Ownership Topology: The Difference Between Flow and Theater

When a product grows past one team, the instinct is to hand out product owner titles to match the org chart — one team, one PO, tidy accountability. But product ownership is not a title. It is the authority to make tradeoffs stick. The fast diagnostic: who around this team can say “no” to a meaningful request and have it hold? If the answer is fuzzy, conditional, or political, you have a proxy, a queue manager, or a title without decision rights — and that is one of the shortest roads to Agile Theater.

This article pulls together a three-episode mini-series on product ownership topology. The one-team case: splitting product manager and product owner usually creates a proxy PO unless the decision rights are crystal clear. Platform teams: if the platform is strategically important, it needs an owner with the standing to disappoint important people — not a junior engineer handed the title and told to negotiate with VPs. Multi-team scaling: do not copy-paste a PO onto every team, because products do not scale by org-chart symmetry — ownership works only where a team can deliver meaningful value with real independence. The throughline: fix the topology of authority around the team, not the role description.

I was recently with a client building a fairly complex mix of hardware and software. They had a platform team serving five internal product lines, a “Product Owner” for that platform team, and Product Managers for each of the lines. On paper, ownership looked covered. In practice, every serious prioritization conversation stalled out. Nobody around that platform team really had the standing to make the hard tradeoffs, so the calls kept drifting upward to the CTO. The team itself lurched from urgent request to urgent request and finished very little.

I see versions of this all the time. The problem usually isn’t lack of talent or commitment. It is that companies confuse job titles with organizational standing.

If you’re leading product in a growing company, this is one of those structural choices that ends up shaping far more than people expect. When ownership is set up well, work tends to flow. When it isn’t, you feel it everywhere: prioritization turns into negotiation, escalations become routine, and teams spend a lot of energy managing requests instead of finishing meaningful work.

Here’s the test I like to use:

Who around this team can say “no” to a meaningful request and have it stick?

If the answer is fuzzy, conditional, or political, you probably don’t have real product ownership. You have some version of a proxy, a queue manager, or someone carrying the role name without the decision rights that are supposed to come with it.

That is one of the fastest roads to Agile Theater. The ceremonies are there. The tickets are there. The ownership isn’t.

This often starts innocently. A growing company decides to “do Scrum,” and somebody suggests a clean split: the Product Manager will focus on strategy while the Product Owner will work closely with the team. It sounds tidy. But very often what this creates is a proxy Product Owner.

That person becomes the relay station between the team and the person who actually owns the decisions. They refine backlog items, answer some day-to-day questions, and run ceremonies. But when the team needs a real tradeoff, people look past them to the Product Manager, founder, or executive sponsor.

At that point, decision latency goes up almost immediately. The team learns where the real authority sits and starts routing around the PO. You end up with more coordination and less ownership.

For one team working on one product, my default is that one person should own the outcome. That doesn’t mean they need to write every Jira ticket. It means they need enough connection to the team and enough authority in the organization to make actual calls.

If your Product Manager is “too busy” to engage with the team, the answer usually isn’t to add another ownership layer. More often, it is a sign that your Product Manager is being used as a roadmap broadcaster, stakeholder shield, or internal salesperson instead of a product leader.

Platform teams are where this issue becomes impossible to ignore.

A platform often serves multiple internal products, so leaders end up treating it like a shared technical service instead of a product. Then they wonder why the team is drowning in competing requests.

Here’s the question I usually ask:

If this platform team stopped shipping for a quarter, would the business feel it?

If the answer is yes, then this isn’t just a service desk with better tooling. It is a strategic bet, and it needs product leadership with enough standing to disappoint important people when necessary.

That doesn’t always mean a full-time senior Product Manager sitting with the team every day. But it does mean somebody credible and empowered needs to own the hard tradeoffs around investment and priorities for that platform.

What usually doesn’t work is giving a junior engineer or analyst the PO title and expecting them to negotiate with a VP Sales, a GM, and several product leaders with conflicting priorities. That isn’t empowerment. It’s a polite way to manufacture escalation.

In situations like this, one pragmatic move is to connect platform ownership directly to the leader who owns the broader portfolio or product line. They don’t need to micromanage the backlog. They do need to own the “not this quarter.” Once that part is clear, the team can stop pretending every request is top priority.

As companies grow, they often copy and paste ownership roles team by team. One team, one Product Owner. It looks neat on the org chart.

The problem is that products don’t scale according to org chart symmetry. Product ownership works when a team can deliver meaningful value with enough independence to learn, decide, and improve. If the team mostly owns a layer, a component, or a specialist function that can’t really move customer or business outcomes on its own, giving that team a Product Owner often creates more coordination overhead than value.

Now you have more people representing partial interests in a system that still needs constant cross-team negotiation. That’s not scaling. That’s full gas in neutral.

This is why topology matters so much. When I worked with Gillette on the Exfoliating Razor, the work wasn’t split into neat software buckets. The meaningful questions were around product problems and choices like the shave experience, the ergonomics, and the viability of the overall bet. Those could move with a decent level of independence while still connecting to one product story. That is the kind of context where separate product leaders can actually help.

If your teams are organized mostly around frontend, backend, or specialist components, slapping a Product Owner on each one rarely fixes anything. Usually it just hides the deeper issue, which is that the topology itself is fighting flow.

If you’re trying to improve product ownership, I wouldn’t start with “how many Product Owners do we need?”

I’d start here:

• What does this team really own?
• Can it deliver value with some meaningful independence?
• Who has the standing to say no on behalf of this team?
• Where do hard tradeoffs get made today?
• Which escalations are symptoms of missing ownership rather than bad people or bad process?

Those questions usually surface the real problem much faster than a role-definition workshop does.

A few signs I see again and again:

• prioritization meetings end in stalemate
• platform teams serve everyone and satisfy nobody
• the “PO” runs the backlog but not the decisions
• stakeholders keep bypassing the team and going to senior leaders
• every important tradeoff turns into an escalation

When that happens, the problem usually isn’t that people need better backlog hygiene. The problem is that your decision-making topology is leaking. You’ve installed the rituals, but you haven’t fixed the flow of authority.

Pick one team that feels stuck. Map the work it actually owns, the dependencies it can’t escape, and the decisions it is allowed to make without escalation.

Then ask the uncomfortable question:

Does the person called the Product Owner actually own anything that matters?

If the answer is no, I wouldn’t start by rewriting the role description. I’d start by fixing the topology around the team.

This article distills a three-episode arc from the Scaling with Agility podcast. Each episode goes deeper on one layer of the topology:

• Who Actually Owns Your Product? Why the PM/PO Split Often Creates More Confusion Than It Solves — the one-team, one-product case, and how splitting product manager from product owner creates a proxy.
• Why Your Product Owners Can’t Say No — platform teams, and why a product owner without organizational standing cannot make a “no” stick.
• When One Product Needs More Than One Leader: Getting Multi-Team Product Ownership Right — scaling across many teams, and why the number of genuine product problems matters more than the number of teams.

Do I always need one person to be both Product Manager and Product Owner?

No. But for a single team working on a single product, splitting those responsibilities often creates a proxy ownership problem unless the decision rights are crystal clear and the two people operate as one.

Can a platform team have real product ownership even if its users are internal?

Absolutely. If the platform is strategically important, has real customers inside the company, and requires tradeoffs about outcomes and investment, treat it like a product.

What is the quickest diagnostic for fake ownership?

Look at who says no when priorities collide. If the person with the PO title cannot make that call stick, you likely have fake ownership.

If this is hitting close to home, let’s talk. I help leadership teams sort out where ownership is real, where it’s theater, and what structural changes are actually worth making.