SAFe, Scrum, and the product owner role: what large companies get wrong

Executive overview

Large enterprises adopting Scrum often create product owner roles that are purely tactical — backlog managers without discovery skills, customer access, or strategic authority. This gap exists because the product owner role emerged from software development practices, not product management.

SAFe gives executives a plug-and-play map, but solves only the delivery coordination problem while leaving out strategy, customer research, and leadership development. Product owners trapped in this system become order-takers with no career path.

The core problem: companies confuse a development operating model for a complete product management practice — and build entire organisations around a role that was never designed to own outcomes.

Origins of the product owner role

• The Agile Manifesto (2001) was written entirely by software developers — no product managers were present
• Scrum introduced the product owner as the person who prioritises the developer backlog, not as a strategic product role
• Early Scrum Guides described the product owner as separate from the team, responsible for maximising value of work done
• The 2013 Scrum Guide dropped even the aside suggesting a product manager could fill the role
• Product owner training: a two-day class covering backlog management, standups, and sprint rituals — no customer research, no experimentation, no data
• Large companies in the 2010s took business analysts, project managers, and developers and relabelled them product owners overnight

How SAFe amplifies the problem

• SAFe (Scaled Agile Framework) was created to coordinate multiple Scrum teams inside large enterprises
• Its appeal: a detailed visual map that prescribes an operating model — executives love it because it looks like a plan
• SAFe splits product managers (strategy, customer research) from product owners (backlog, stories, developers)
• Product owners in SAFe become pure order-takers: writing user stories 40 hours a week with no time or mandate to talk to customers
• Big Room Planning commits teams to a quarter's work before discovery has happened; sprints run back-to-back with no room for learning
• SAFe says nothing useful about how to do product strategy, how to lead discovery, or how senior product leaders should operate
• A Dutch water company adopted SAFe, got so consumed by process that it couldn't deploy its invoicing system in time, and went bankrupt

Why companies keep adopting it

• SAFe is the only framework that specifies things to the level executives want — it fills a vacuum
• Many buyers have never run a technology organisation before and are looking for a handbook
• Consulting firms (including McKinsey) built large practices selling SAFe implementations
• Revenue model of the agile industrial complex: certifications and training — organisations are incentivised to certify everyone
• Companies like Capital One have publicly exited SAFe; many others quietly rip it up and rebuild something else

What a real product operating model requires

• A development operating model (what SAFe addresses) is only one piece; product strategy, org design, product ops, and culture all matter
• Leaders must create infrastructure that lets teams actually reach customers — if the system doesn't allow it, teams won't do it
• Incentives matter: rewarding teams for shipping volume, not outcomes, breaks the feedback loop
• Large organisations need a transparent view of what all their teams are building and whether it connects to company goals
• The C-suite must treat software strategy as a board-level concern, not an IT matter
• Transformation requires mixing experienced external hires with internal talent — training alone is insufficient

Career paths and the product owner trap

• Most large organisations have no defined career path from product owner to product manager
• SAFe treats them as separate tracks reporting into different leadership chains
• Product owners rarely get exposure to strategy, market research, or outcome ownership — making the PM transition hard
• No top tech company (Google, Amazon, Netflix, Microsoft) uses product owners — all have product managers
• CSPO certification (Certified Scrum Product Owner) is a two-day class; it signals agile process knowledge, not product management capability

Advice for product owners wanting to grow

• Reframe your resume around value delivered and outcomes, not agile ceremonies or process ownership
• Describe problems solved, customers served, metrics moved — not backlog management or sprint rituals
• Ask your manager what the career path is; it forces the conversation and often triggers org-level reflection
• Request to sit in on customer research sessions, even informally
• Challenge the value of work in the backlog: "What do we hope will happen when we release this?"
• If no one in the organisation is doing great product management, that is a red flag — find teams or leaders internally who are, or consider leaving

How to run a better transformation

• Baseline everyone with training, then let people self-select — many will opt out once they understand the full scope of the PM role
• Assign experienced product leaders at director level to intersperse across teams so people have role models
• Eliminate the product owner versus product manager title split; use associate PM, PM, senior PM as a single ladder
• Evaluate whether existing people can develop the skills or whether experienced external hires are needed at each level
• Measure transformation success by outcomes, not by how many teams are running certified Scrum