I once worked in a model that separated the Product Manager role from the Product Owner role. The Product Manager stayed closer to the product's context, vision and customer needs, while the Product Owner stayed closer to the day-to-day details with the development team.
The split made sense. But the challenge started to show during development, whenever details came up that needed a quick decision:
- An edge case the requirement didn't cover.
- A technical constraint that conflicted with what was asked for.
- A trade-off between options that needed someone to call it.
The cost of a deferred decision
The Product Owner had to go back to the Product Manager for more context or a final call. Meanwhile, the team waited, or switched to other work, until the answer came back.
A single decision could take anywhere from a few hours to a day. And when that scenario repeats throughout a Sprint, its impact starts to show in the team's speed and the continuity of the work.
That's why, in many cases, I lean towards the Product Manager also being the Product Owner. Not because separating the two roles is wrong in itself, but because clear end-to-end ownership of the product reduces handoffs and keeps decisions closer to the person who has the full context.
But what about large products?
There's a fair objection here: one Product Manager responsible for discovery, stakeholders, the Backlog and day-to-day work with a large development team can become a bottleneck themselves. Splitting the roles can look like a sensible way to spread the load.
Split the scope, not the ownership
In another hands-on experience with a large product, we took a different route. Instead of splitting product responsibility between a Product Owner and a Product Manager, we split the product's scope itself into Modules.
Each Product Manager owned a clearly defined scope end to end, playing both the Product Manager and Product Owner roles: from understanding customer needs and setting priorities, to managing the Backlog and working with the development team, through to launch and measuring impact.
At the same time, these scopes didn't operate in isolation:
- We held regular alignment between Product Managers on changes and updates across scopes, whether their impact was limited to one scope or extended to the product as a whole.
- On top of that, a Product Director looked at the product more holistically, keeping the overall direction and the connections between scopes intact.
This way, the size of the product was spread across several Product Managers, but each one kept full ownership of their scope.