The Product Owner Escape Ladder
Five moves to climb out of the order-taker trap without quitting first
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 92%
Practical advice for a product owner stuck writing user stories for developers with no path to strategy. Perri's sequence escalates: reclaim ownership, force the career-path conversation, borrow discovery time from the product manager, cut the user-story volume you treat as your metric, and ask the single outcome question that reframes your work. Only if all of that fails does she recommend moving — laterally inside the company first.
Origin
Melissa Perri, from a decade of training product owners inside banks, insurers and telecoms running SAFe; the pushback story comes from a Mind the Product workshop attendee.
Core principles
- 01Your role is more than working with the developers — assert that first, internally.
- 02Product, not project: your job does not end when a project ends, so pushing back on the wrong work is not job suicide.
- 03Volume of user stories is a vanity metric; value delivered is the real one.
- 04Leaders don't want to lose good people — raising the question moves them.
- 05A ground swell of people asking the same question forces the org to answer it.
How to run it
- 1
Take ownership and push back on handed-down work
Stop accepting the backlog as given. If you don't believe the work is the right work, build the case and say so to your manager.
Pro tip Perri's workshop attendee feared she'd be fired for saying the roadmap was wrong. She built the case, presented it, and was promoted.
Watch out Bring evidence, not just objection — she put together 'this whole thing' before presenting.
- 2
Ask leaders what your career path is
Directly ask what comes after the product owner role. In most orgs no one has defined it, and the question itself triggers the work of defining it.
Pro tip Point them at existing literature on product career ladders so the ask is constructive rather than a complaint.
- 3
Buy discovery time by cutting story volume
Ask the product manager if you can sit in on customer research. When you say you have no time, strip back the user stories you're writing and stop treating story count as a quantitative metric that must go up.
Pro tip If you genuinely run out of feature work for developers, don't invent it — point them at tech debt they can scope themselves with the architects.
Watch out The 'sprint back-to-back, keep the developers full' treadmill is the exact mechanism that prevents discovery. It has to be broken deliberately.
- 4
Ask the outcome question
For every feature, ask: what do we hope will happen when we release this? What metrics will change? How do we instrument it to know? This one question converts a delivery conversation into an outcomes conversation.
Pro tip Perri calls it the single best question for anyone worried their company isn't focused on outcomes — it also creates the after-the-fact conversation about why something did or didn't work.
- 5
If the org can't change, move — laterally before externally
If you genuinely cannot do good product management there, look for another organization. Inside a large corporation, first look for a division or business line that does it well and move to that team.
Pro tip Find the leaders who know what they're doing and go work for them — that is usually the best move.
Watch out Perri acknowledges job changes are hard when tied to healthcare/insurance; treat this as the last rung, not the first.
In the wild
A product owner in a SAFe org told Perri she didn't think her team was working on the right things, but feared she'd be fired for saying so — and worried about what she'd even work on instead. Perri told her to take it to her manager. She assembled the case and presented it.
→ She was promoted.
At a bank in 2015, a product owner told Perri she had no time to talk to customers because she spent essentially all her time writing user stories to keep developers' backlogs full. Her scope: the login API — which already worked. A separate product manager talked to customers and fed her requirements.
→ Perri's canonical illustration of the order-taker trap: enormous story volume, zero strategic surface, no discovery, and a component-shaped scope with no real work in it.
Common mistakes
Treating story throughput as your performance metric
Optimizing for keeping developers full means you never have time for discovery, which means you never build the skills that get you promoted out of the role. The metric is self-trapping.
Waiting for the org to hand you a career path
In most enterprises nobody has designed one. The path only gets defined when product owners start asking — and a ground swell of people asking is what makes leadership act.
Is it for you?
Best for
A product owner inside a SAFe or scrum enterprise who wants to become a real product manager without quitting
Not ideal for
Someone already in a software-native company with a functioning PM ladder and discovery access
From the transcript
“push back on the things that are being given to you”
“if you're a product owner and there's no career path for you start asking leaders what your career path is”
“what do we hope will happen when we release this what metrics are we going to change how do we instrument it to make sure…”
“in a large corporation maybe think about moving internally like laterally to a different team and seeing if you can work there I'd find the…”
From the episode
Everything you’ve ever wanted to know about SAFe and the product owner role
Melissa Perri (author, founder of Product Institute)