A short story to illustrate why “Product Owner” is a pointless role

Somehow, the role “Product Owner” is creeping into the world of product development. The idea is to have someone sitting between product managers and engineers to write user stories, prioritize the backlog, and track development progress. In other words, POs take care of the nitty-gritty of product delivery so PMs can focus on the vision and strategy.

On the surface, this seems like a reasonable setup. However, anyone who has built products for a few years can spot the problems from miles away.

Let me use a short story to illustrate why having this PM/PO split is so problematic.

At ACME corp…

It’s a sunny afternoon. A product manager (PM) is ready to start tackling a new user problem with a product designer (PD).

After 2 weeks of interviews and analysis, they finally scope out the problem. They then spend another 2 weeks crafting a solution.

The engineering team (ENG) is not involved because “Well, PO will do the handoff.”

Time for handoff

Now PM/PD have to pass 1 month of knowledge to a product owner (PO) in a 1-hour meeting.

PM thinks: (With this much info, why don’t I just talk to ENG directly?)

PO thinks: (There’s no way I’ll understand all this.)

Time to write user stories

Because PO wasn’t part of the discovery, he keeps going back to PM for questions.

PM thinks: (Ugh, why don’t I just write them myself?)

PO feels bad, so he makes some guesses on things he considers minor (but he has no clue if they actually are).

Time for development kickoff

ENG looks at a list of user stories that read like “As a user, I want to push a button, so the button will be pushed.”

ENG rolls her eyes: (I’d rather have a clearly-defined, old-school PRD than this pseudo-user-centric crap.)

ENG then asks clarifying questions…

PO can’t answer most, so he has to ask the PM. The meeting was a waste of time.

PO follows up with answers. ENG says the solution is not technically feasible. PO relays the info…

Now PM & PD have to find another solution.

After another round of story writing, ENG looks at the new solution and says: “Why would users want this?” (remember they aren’t part of the discovery?)

This loop repeats 2 more times

Now PM/PD think: “Gosh, the ENG has zero user/business understanding!”

ENG thinks: “PM/PD didn’t think things through!”

They’ve had enough, so they call a meeting to clear things up. Within just 30 minutes, the trio is able to clarify everything.

Turns out, all confusion was caused by a crucial detail that the PO had “guessed” when writing the stories.

Well, at least now everything is clear, the PO cheers “Hooray!”

Everyone turns to him and asks “SO, WHY ARE YOU HERE AGAIN!?”

The end.

Time for rebuttal

I know some will comment “That’s not how PO works!”

Let’s counter their potential counters…

“PO do participate in discovery to some degree.”

Are you saying one has to be in discovery to do delivery? So why not distribute that work among PM, PD, ENG?

“Because they have to focus on one area!”

Switching context between discovery and delivery has a cost, but it’s far smaller than the cost of a messenger who can’t pass the right info.

“PM focuses on strategy, PO focuses on execution.”

This is a just hollow abstraction that doesn’t carry any substance. When you ask those who support PO/PM split to define what it looks like in practical terms, they always end up describing the relationship between product leaders & IC PMs.

If you happen to be in such a role — don’t feel bad. Being able to operate in a sub-optimal setup is worth applauding, and seeing what doesn’t work first-hand will help you avoid the traps in the future. Just know that there are probably better places for you to shine. 

P.S. Blame all the confusion on SAFe (a terrible framework).

Product owner originated as a role that product managers (occasionally others) play in a Scrum team, not a separate job. 

The separation is simply an attempt to let “business function” take control of product direction without having to be responsible for all the practical executions. If you look at the type of companies that adopted this approach, you will understand why. (It’s also funny that many of them do not have PMs at all, only POs.)

I won’t expand on this topic too much because some of the best PM thought leaders already have. If you want to learn more, check out:

Enjoyed it? Help me share it

Hi, I’m Austin

I love exploring new ways of building and growing products. If this sounds like your cup of tea, feel free to get in touch.
You might also like

Hi, I’m Austin

I love exploring new ways of building and growing products. If this sounds like your cup of tea, feel free to get in touch or subscribe!

Open your inbox to confirm your email