Product Owner Is Not a Job Title. Stop Pretending It Is.
In 2026, we need to end this madness.
Product Owner is not a job title. It’s an accountability within Scrum. And treating it as a separate role from Product Manager is one of the worst anti-patterns in product management.
Here’s what happens when you split the roles:
The Product Manager talks to business stakeholders and customers. Does the strategy work. Makes the big decisions.
The Product Owner (or “backlog administrator”) works with developers and documents “the requirements.” Translates what the PM wants into user stories. Manages sprint planning.
This setup guarantees mediocrity.
And yet companies keep doing it. Because someone told them it’s “too much work for a single person.”
Let me tell you why that’s wrong.
The “Too Much Work” Myth
The argument goes like this: one person can’t talk to customers, understand the business, work with engineers, manage the backlog, and attend all the meetings.
It’s too much. You need to split it.
This reveals the real problem: you’re doing product management wrong.
If you’re spending days in useless meetings, you have a meeting culture problem. If you’re writing detailed instructions for every user story, you’re micromanaging. If your backlog requires constant “administration,” you’re over-planning.
Good product management isn’t about doing everything. It’s about enabling others to do their jobs well.
You don’t write specifications. You work with the product trio to discover solutions together.
You don’t attend every meeting. You prioritize ruthlessly and decline the ones that don’t create value.
You don’t manage detailed backlogs. You focus on outcomes and let teams figure out the implementation details.
When you empower teams instead of controlling them, the workload becomes manageable. More than manageable. It becomes sustainable.
The split role isn’t solving a workload problem. It’s compensating for bad practices.
What Actually Breaks With Split Roles
Let’s talk about what happens in practice when you separate PM and PO.
The Product Manager becomes disconnected from reality. They make strategic decisions without understanding implementation constraints. They commit to roadmaps without knowing what’s actually feasible.
Because they’re not talking to engineers daily. They’re not seeing the technical challenges. They’re operating based on assumptions.
The Product Owner becomes a translator. They’re not empowered to make decisions. They’re just converting PM requirements into developer language.
This is soul-crushing work. No wonder POs feel like backlog administrators. That’s exactly what the role becomes.
Engineers get filtered context. They hear about problems second-hand or third-hand. Through the PO, who heard from the PM, who heard from customers.
By the time context reaches engineers, it’s diluted. Misinterpreted. Missing crucial details.
So engineers build what was requested, not what was needed. Because they never understood the real problem.
Discovery becomes impossible. Product discovery requires the PM, designer, and engineer working together to understand problems and explore solutions.
But if the PM isn’t working directly with engineers, this can’t happen. The PO sits in discovery meetings. But they can’t make product decisions. They’re just taking notes to share with the PM later.
This is theater, not discovery.
What Marty Cagan Got Right
Marty Cagan nails this in INSPIRED and TRANSFORMED.
To succeed as a Product Manager, you need:
Direct access to users and customers. Not filtered through sales or support. Not mediated by a PO. Direct.
Direct access to business stakeholders. The people who understand market dynamics, competitive threats, financial constraints. Not proxies.
Direct access to engineers and designers. The people who will actually build the product. Not through a middleman.
Without these direct connections, you can’t do the job. You’re making decisions based on secondhand information. Playing telephone with critical context.
The whole point of the product operating model is empowered, cross-functional teams making decisions together with full context.
Adding a PO layer breaks this. It creates hierarchy where you need collaboration.
The Only Valid Setup
The Product Manager and Product Owner should be the same person.
This person has end-to-end responsibility. They understand the customer, the business, the technology, and the team.
They work in the product trio with a designer and at least one engineer. Together, they perform continuous product discovery.
They talk to customers. They explore solutions. They prototype rapidly. They learn together.
No handoffs. No translations. No proxies.
This is how empowered teams work. And empowered teams build better products faster than command-and-control organizations.
You might have a Principal PM or Group PM who sets strategy. Fine. But the PM working with a specific team needs direct access to everything.
If you have a “PM” who only does strategy and a “PO” who only does execution, you don’t have product management. You have dysfunction.
The Scrum Perspective
As someone who’s PSPO III certified, let me clarify something about Scrum.
Product Owner is accountability, not a job title.
In Scrum, someone needs to be accountable for maximizing the value of the product. That’s the Product Owner accountability.
This is best fulfilled by an experienced Product Manager. Someone who understands discovery, strategy, and execution.
But companies misread the Scrum Guide. They create a “Product Owner” job title separate from “Product Manager.” Then they wonder why both roles feel unfulfilling.
The PM gets frustrated because they can’t execute their vision. The PO gets frustrated because they have no authority to make product decisions.
This isn’t what Scrum intended. And it’s certainly not what effective product management looks like.
The AI Argument
Here’s another thing: it’s 2026. Backlog work can be delegated to AI.
Writing user stories? AI can do it. Breaking down epics? AI can help. Maintaining sprint documentation? AI handles it.
If your “Product Owner” role is mostly administrative backlog management, that role shouldn’t exist. Automate it.
What AI can’t do: talk to customers. Understand strategic context. Make product decisions. Collaborate with designers and engineers on discovery.
Those are product management activities. They require judgment, empathy, and strategic thinking.
Administrative tasks? Those are increasingly automated.
The split role made more sense (barely) when backlog management required significant manual work. Now it’s just organizational inertia.
The Real Problem This Creates
Let me tell you what I see in companies with split PM/PO roles.
Products lack coherence. Because nobody has end-to-end ownership. The PM sets strategy but doesn’t see execution challenges. The PO knows implementation but doesn’t understand strategic context.
Teams are disengaged. Engineers don’t understand why they’re building things. They get tasks, not problems. They implement, not innovate.
Velocity drops. Because there are handoffs everywhere. PM to PO. PO to team. Team back to PO. PO back to PM. Every handoff adds delay and loses information.
Quality suffers. Because nobody feels fully responsible. The PM blames the PO for bad execution. The PO blames the PM for unrealistic requirements. Engineers blame both for unclear context.
This is organizational dysfunction masquerading as role clarity.
What Good Product Management Looks Like
I’ve worked with teams that get this right. Here’s what it looks like:
One PM works directly with a product trio. PM, designer, and engineer(s). This trio does product discovery together.
They interview customers together. They explore solutions together. They make decisions together.
The PM creates context, not control. They explain the problem, the constraints, the goals. Then they trust the team to figure out the solution.
The designer brings user experience expertise. They prototype rapidly. They test assumptions. They ensure the solution is usable.
The engineer brings technical expertise. They identify feasibility constraints. They propose technical solutions. They architect scalable systems.
Together, they make better decisions than any one person could alone. This is continuous discovery in action.
No PO needed. No translations. No proxies.
Just a high-functioning team with shared understanding and clear accountability.
The Path Forward
If you’re in an organization with split PM/PO roles, here’s what to do.
Start doing discovery together. Even if it’s not official. Get the PM, designer, and engineers in the room with customers. Let everyone hear problems directly.
Blur the boundaries. PM should be in sprint planning. Engineers should be in strategy discussions. Designer should talk to customers. Cross-pollinate.
Demonstrate the problems. Document the handoff delays. The miscommunications. The rework caused by lost context. Make the dysfunction visible.
Propose a pilot. One team with one PM who has full accountability. Track outcomes. Compare to split-role teams.
Most organizations will resist. Because “this is how we’ve always done it.” Because “Scrum says we need a Product Owner.” Because “one person can’t do both.”
Push back. Gently but persistently. With data and examples.
And if they won’t change? Consider whether you want to work in an organization that institutionalizes dysfunction.
The Bottom Line
Product Owner as a separate job title is an anti-pattern. It creates handoffs where you need collaboration. It fragments ownership where you need accountability.
The solution isn’t splitting roles. It’s doing product management properly.
Empower teams. Create context. Focus on outcomes. Cut the administrative bloat.
One PM with end-to-end responsibility. Working directly with customers, stakeholders, engineers, and designers.
That’s how you build great products. Everything else is organizational theater.
Hope that helps.
Do you agree or disagree? What’s your experience with split PM/PO roles?
