Lenny's PodcastMelissa Perri: Why SAFe quietly fails real product teams
Through scaled agile frameworks built for developers, SAFe drifts; product owners ripping it up grow into product managers focused on real customer impact.
CHAPTERS
- 0:00 – 2:21
Cold open: What SAFe is—and why Melissa says “don’t use it”
The episode opens with SAFe (Scaled Agile Framework) and Melissa’s strong stance against adopting it “by the book.” She previews a common pattern: teams that claim SAFe success often end up heavily modifying or replacing it.
- •SAFe emerged to help scale Scrum across large organizations
- •Melissa explicitly does not recommend SAFe as implemented “by the book”
- •Anecdotal pattern: SAFe “success” usually involves ripping it up and adapting it
- •Framing the episode around product owners, scaled Agile, and large enterprises
- 2:21 – 6:46
Why product owners are booming (and why Lenny wanted this episode)
Lenny shares job-market data showing product owner as one of the fastest-growing roles, despite being rare in his Silicon Valley circles. He sets the goal: demystify product owners, Scrum, scaled Agile, and how big companies build software.
- •Product owner is a top-growing role, surprising to many PMs
- •The PO world is often invisible in startup/tech-company networks
- •The conversation will focus on large, non-software-native organizations
- •Objective: help leaders and product owners “level up”
- 6:46 – 10:58
Melissa’s path into Agile circles: from flexible Scrum to dogma at scale
Melissa explains how she first encountered Scrum in startups as a lightweight, flexible way to ship and learn. As she began training at large enterprises, she noticed Scrum often became rigid and disconnected from true product management.
- •Early experience: Scrum as a pragmatic way to break work into sprints
- •Shift over time: increasing dogmatism around ceremonies and rules
- •At Agile conferences, Melissa realized “product owner” was a distinct Scrum role
- •Large enterprises created POs en masse without clarifying responsibilities
- 10:58 – 21:59
Where the product owner role actually came from (and why it diverged from PM)
Melissa traces the PO role back to Scrum’s origins and clarifies that it didn’t emerge from modern product management. In many transformations, POs became backlog managers who prioritize for developers—without the discovery and strategy skills expected of PMs.
- •Agile Manifesto (2001) was written by developers, not product managers
- •Scrum Guide codified roles: developers, Scrum Master, product owner
- •Early Scrum positioned PO as accountable for maximizing value—without explaining discovery
- •Two-day PO trainings emphasize backlog mechanics, not research/experimentation/data
- •Result: PO becomes a tactical “requirements intake” function in many orgs
- 21:59 – 26:37
Scrum as a tool, not a religion: who needs frameworks and why
The discussion reframes Scrum as a development operating model meant to improve collaboration and feedback loops. Melissa argues startups often don’t need heavy process if teams already communicate well, while large organizations seek rigor because they didn’t grow up building software.
- •Large companies adopt frameworks to create rigor and coordination at scale
- •Startups can use Scrum lightly—or skip ceremonies that don’t add value
- •Common complaint: “a million meetings” when Scrum is followed rigidly
- •Key principle should be inspect-and-adapt, not ceremony compliance
- 26:37 – 28:07
What SAFe is trying to solve: scaling Scrum with a prescriptive enterprise map
Melissa explains SAFe’s intent: coordinate many Agile teams through a standardized operating model. She outlines SAFe’s popularity with executives because it feels like a plug-and-play blueprint for large-scale software delivery.
- •SAFe is one of several scaling frameworks (alongside LeSS, Scrum@Scale)
- •It’s marketed as a comprehensive map for how to run Agile at enterprise scale
- •Executives like the prescriptive model and definitions
- •Key constructs: Agile Release Trains, roles, and coordination mechanisms
- 28:07 – 35:49
How SAFe splits PM vs PO—and turns product owners into order-takers
Melissa shares her first SAFe encounter: a “product owner” spending all day writing user stories for a narrow component like a login API. She argues SAFe commonly creates a strategic/tactical split where PMs do discovery and POs feed delivery—often blocking learning and autonomy.
- •Real-world SAFe PO work often equals constant user-story writing and backlog filling
- •Organizations frequently organize teams by components, creating narrow scopes
- •SAFe role split: PO embedded with delivery team; PM tied to release train layer
- •Big Room Planning becomes quarterly commitment without sufficient discovery
- •Developers can become dependent on PO prioritization instead of collaborating on solutions
- 35:49 – 41:32
Why SAFe adoption persists—and why it often gets removed later
Lenny challenges the “absurdity” by emphasizing the real problem executives are trying to solve: building good software at scale. Melissa explains why SAFe continues to spread (clarity, marketability), but notes many organizations later abandon it, including prominent examples.
- •Executives buy SAFe because it’s understandable and feels like a handbook
- •Many orgs adopt SAFe first, then later remove or significantly change it
- •Example: companies dropping specialized Agile/Scrum roles after learning
- •Core critique: SAFe covers coordination but not leadership/product strategy
- 41:32 – 49:07
How to do digital/agile transformation better: product strategy, ops, incentives, and career paths
Melissa lays out a broader transformation approach: treat Agile as only the development operating model, and build the rest of the product operating model around it. She emphasizes strategy, organizational design, product ops infrastructure, outcome-based incentives, and clear career ladders.
- •Separate “development operating model” from product management and go-to-market
- •Build a product operating model: strategy, org design, product ops, culture/incentives
- •Enable discovery with access to customers, research, and decision-grade data
- •You may need more (not less) process for transparency across thousands of teams
- •C-suite sponsorship is essential; middle-management resistance is common
- 49:07 – 52:00
Melissa’s bottom line on SAFe: over-process can kill outcomes (and even bankrupt you)
Melissa reiterates she doesn’t recommend SAFe and warns against process obsession that replaces customer impact. She shares an extreme cautionary story where SAFe process focus contributed to severe operational failure, illustrating the risk of “work about work.”
- •Melissa’s stance: don’t use SAFe as-is; at best, selectively adapt pieces
- •Teams get stuck debating ceremonies rather than measuring customer/business impact
- •Rigid quarterly commitments can crowd out discovery and learning
- •Cautionary example: process overload delaying critical billing/collection systems
- •Success metric should be outcomes, not adherence to a framework
- 52:00 – 56:55
The missing ingredient: experienced product leadership (not frameworks) + making POs real PMs
The conversation shifts to the role of experienced product leaders in making transformations work. Melissa argues companies should upskill internal talent but must also hire experienced leaders to model “good product,” and she stresses that product management remains essential even without Scrum.
- •Frameworks can become a crutch when leaders lack experience running tech orgs
- •Best transformations mix internal upskilling with hiring experienced PM/product leaders
- •Product ownership shouldn’t be a separate, dead-end career track
- •“Take Scrum away—you still need product management”
- •Leaders must recognize skill gaps and hire to complement them
- 56:55 – 1:06:39
PO-to-PM playbook: push for outcomes, do discovery, and rewrite your resume around impact
Melissa gives tactical guidance for product owners who want to grow into product managers. She recommends challenging output-only roadmaps, asking outcome questions, joining customer research, and presenting work in terms of value delivered rather than Agile mechanics—especially on resumes.
- •Ask outcome questions: “What do we hope will happen when we release this?”
- •Join or initiate customer research; don’t accept a strict ‘not my job’ boundary
- •Stop optimizing for story count; focus on measurable value and learning
- •Resume advice: remove process-heavy bullets; lead with customer/business outcomes
- •If necessary, move internally to stronger teams—or leave for a healthier org
- 1:06:39 – 1:11:42
Certifications and the “Agile industrial complex”: when badges help—and when they hurt
Melissa warns that common Scrum/Agile certifications often signal training completion, not competence in product work. She explains why enterprises may demand them, why tech companies typically don’t value them, and how candidates should contextualize them.
- •Certifying bodies monetize training and consulting—certs are a business model
- •CSPO is often a short workshop and doesn’t prove product capability
- •Certs can help inside enterprises that require them, but may hurt in top tech hiring
- •Experience and outcomes matter more than credentials
- •Be skeptical of “plug-and-play” career shortcuts
- 1:11:42 – 1:17:25
Standardizing titles and assessing talent: converting POs, leveling skills, and enabling opt-outs
Melissa explains how she advises organizations to simplify PO vs PM titles and create a clear PM ladder. She describes a practical transformation pattern: baseline training, skill assessment, letting people opt out into other roles, and hiring experienced leaders to raise the bar across teams.
- •Reduce confusion: unify around PM titles (APM → PM → Senior PM) where possible
- •Evaluate actual skill sets—some POs already operate as strong PMs
- •After training, many people self-select out once they understand PM accountability
- •Reassign talent into ops, data, or research roles when better fits
- •Scatter experienced leaders across teams so others can learn what “good” looks like
- 1:17:25 – 1:24:19
Closing principles: be agile (lowercase), distrust rigid playbooks, and elevate software strategy to the C-suite
Melissa closes by returning to first principles: agility is about fast learning and customer value, not rigid compliance. She advises skepticism toward consultants selling one-size-fits-all playbooks and argues that digital/software strategy must be a core executive responsibility—often requiring true product leadership at the top.
- •Agile principles: move quickly, get feedback, deliver customer value
- •Inspect-and-adapt should apply to every process; change what doesn’t serve outcomes
- •Be skeptical of by-the-book coaches and big-consulting “transformations”
- •Software strategy must be owned at the C-suite, not pushed down to IT
- •CPO/product leadership helps translate software into competitive advantage
