Everyone's arguing about PM vs PO.

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.

2 comments

Comment

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.

Like • like this

Exactly. The title doesn't matter as long as the context survives the handoff. Whether it is a PM or a PO.

The moment one person talks to the customer and another writes the ticket, context starts to leak.

Like • like this

And that's before you bring in the concept of Technical PMs or Technical POs, whatever that is, into the mix.

I experienced that in a company of less than 500 people. Which was ridiculous.

Another problem was that 80% of Technical PMs were developers, which would explain both the technical bit and the why the PM bit was not really happening.

On the other hand, I worked with POs whose job title was changed to PMs. That didn't matter. Those folks had an incredible sense of ownership and were great to work with.

And I'm saying that as a person who was responsible for technical content (product documentation and processes...) and, for my people, that's inceredibly rare.

Cannot but agree @Evan Fishman - Quely for Jira

Like • like this

100%! Technical PM, Technical PO, whatever comes next, is just the org trying to solve an ownership problem with a label. It never works.

Like • Anne Saunders likes this

I will 100% never understand the train of thought that stacks on project admin staff- "This team doesn't seem to be communicating with each other very well. The obvious answer is to add more people to communicate with!"