Everyone's arguing about PM vs PO.

Evan Fishman - Quely for Jira

Who owns the backlog. Who talks to customers. Where the line is between discovery and delivery.

Here's the thing though:

The one thing that keeps breaking, no matter the title, no matter the org size, is context.

Not the roadmap. Not the backlog. Not the sprint goal.

The why behind decisions. What the customer actually said. What tradeoffs were discussed and never documented.

Why a ticket was scoped the way it was.

What actually happens when context gets lost:
→ A new engineer joins and reopens a debate the team closed three months ago.
→ A stakeholder asks why feature X got cut…nobody remembers.
→ The sprint starts and half the team is operating on different assumptions.

That's not a PM nor a PO problem.

It's a context problem. And it shows up everywhere, regardless of how you've structured the org.

The PM vs PO debate is just a title argument.

Managing context is the actual work, and almost nobody has a system for it.

Anne Saunders

Maybe I'm missing the point, but I've never understood why a small-to-medium size project needs both. 

In a team-of-teams situation where a bunch of features are in concurrent development by different teams, I kinda get the need for a PO to orchestrate the multiple teams that each have their own (or at least a fractional) PM. 

It may also be that I've never worked with any POs who felt very effective. 

Our solution at Clevyr is that we don't split the role - we just have PMs and Account Managers. Some of our clients assign a PO on their side who acts as a kind of counterpart for our PM in the best cases, but most don't formalize it.