The setup: Who really owns the product?
You’re scaling your product team. You already have capable Product Owners who keep the wheels turning, the backlog healthy, and the developers sane. But now, someone raises a red flag: “We need a Product Manager!”
At first, the reasoning sounds solid: market pressure is growing, management wants better strategic visibility, and sales keeps demanding features that aren’t on anyone’s radar. A PM sounds like the natural next step.
So you hire one. And things… get weird.
The PO suddenly doesn’t know whether to run decisions by the new PM. Developers are unsure who to talk to. Sales goes to the PM, bypassing the PO. The PM starts refining backlog items. POs feel disempowered. Teams slow down.
You didn’t solve a problem. You created a turf war.
Learning: Why roles blur and teams suffer
Here’s the hard truth: in most companies, the PO is the beating heart of agile product development. When enabled and equipped, they handle backlog priorities, collaborate with stakeholders, and make fast, valuable decisions.
But many organizations create Product Manager roles for the wrong reasons:
- “Management wants reports.”
- “Sales needs a contact person.”
- “It worked like this at our last company.”
Translation: “We need a grown-up in the room, and we don’t trust the PO to be it.”
This approach rarely works. Instead, you get overlapping responsibilities, bloated processes, and frustrated teams. Like hiring a second driver because the first one isn’t allowed to use the GPS.
If your POs can’t handle strategic communication or aren’t connected to customer needs, ask yourself: are they the problem, or is your system failing them?
Real-World Example: The PM-as-Proxy Trap
A mid-sized SaaS company, hired a PM because “leadership needed roadmap visibility.”
But instead of empowering their already skilled PO to handle these conversations, the PM became a proxy. Leadership stopped engaging with the PO. The dev team got backlog updates second-hand. The PM began to act as a filter rather than a facilitator.
Result? Strategic context got lost in translation. Delivery slowed. The PO felt sidelined and left. The company eventually restructured the role, shifting the PM to focus on external market insights and re-enabling the new PO to own the roadmap discussions.
Lesson learned: don’t install a middleman when you can level up the actual owner.
The tool: When a PM really adds value
Now, let’s be fair. There is a time and place for Product Managers. But it requires honest answers to hard questions:
The PO vs. PM Decision Matrix
| Question | If Answer is YES | If Answer is NO |
|---|---|---|
| Do you have, lets say, more than 5 Scrum teams working on the same product? | Consider adding a PM to align strategy and roadmap across teams. | The POs can likely cover strategic needs. |
| Is your product a suite with multiple modules? | PM needed for portfolio strategy. | A strong PO can manage it all. |
| Is leadership engagement failing due to scale? | PM can bridge vision and reporting. | Enable the PO to lead these discussions. |
| Do you need in-depth market & competitor analysis? | A PM can add strategic firepower. | PO might still own this with the right support. |
| Are your POs feeling disempowered or bypassed? | Rethink structure before adding roles. | PM can reinforce, not override. |
This matrix helps clarify whether you have a scaling problem or a structural clarity issue.
1. Are you truly scaling?
A PM makes sense when the product spans multiple Scrum teams, and coordination becomes strategic. Think multiple POs, shared vision, conflicting priorities. A PM can align them.
2. Do you need portfolio-level guidance?
If you’re juggling several interdependent products or modules, someone has to define the big picture, the market positioning, and the long-term investment logic. That’s PM territory.
3. Are your POs empowered?
Adding a PM to “fix” weak POs is a band-aid. Fix the root cause: enable your POs with context, tools, and coaching. A great PO can handle exec comms, stakeholder alignment, and sprint planning—if you let them.
4. Is the PM a guide, not a governor?
PMs should enable, not override. Strategy, vision, and customer insight? Yes. Telling teams how to build? No. The PO and dev team own the “how”. Anything else breaks agile.
5. Do you have role clarity?
Here’s the clean split:
- PM: Owns the “why” and “what” at a strategic level. Portfolio view. Roadmaps. Market trends. Alignment across POs.
- PO: Owns the “what” and “how” for their team. Backlog. Sprint planning. Value delivery.
Clear roles avoid turf wars. Blurry ones start them.
Final thought: Complexity doesn’t justify confusion
Organizations often mistake complexity for justification. “It’s complicated, so we need more roles.” But more roles don’t create clarity — they create bottlenecks.
If your POs can’t deliver business value and strategic alignment, don’t hide behind a PM title. Upgrade your enablement game.
And if your product is scaling fast, and you need someone to stitch the vision together across teams, by all means: bring in a PM. But only if they know their job is not to steer the ship alone, but to help others navigate together.
Because in product development, the most valuable role isn’t the one with the title. It’s the one that clears the path without blocking it.