Product vs. SAFe

Welcome & Opening Remarks

Joe Ghali | 00:00–00:46
Welcome, everyone. Today we’re going to unpack a topic that comes up constantly in product organizations: Product vs. SAFe. Why do they seem to clash? Do they truly clash? And how do we reconcile them so teams can deliver actual outcomes, not just outputs?

Thank you for joining us. Let’s dive in.

Why We’re Having This Conversation

Joe Ghali | 00:46–02:18
If you’ve ever worked in a product organization that uses SAFe, you’ve probably heard some variation of:

• “We’re Agile… but also not really.”
• “We have product managers… but also release train engineers.”
• “We want to be outcome-driven… but SAFe has us shipping features.”

There’s a natural tension that forms between product thinking and framework thinking. Product is about solving customer problems. SAFe is often implemented as a system for controlling workflow and coordinating delivery.

The issue isn’t SAFe itself — it’s how organizations interpret it.

How SAFe Is Commonly Misunderstood

Rosana Johnson | 02:18–03:44
In theory, SAFe is designed to scale Agile and align multiple teams.
In practice, it often turns into:

• A feature delivery factory
• A heavyweight governance model
• A place where “Agile” becomes “waterfall with more meetings”
• A system of endless ceremonies that drown actual product discovery
• A playground for process, not for customer value

This is why product managers sometimes feel suffocated. They’re asked to “prioritize features” instead of solving real customer problems.

What Product Management Is Actually Meant to Do

Joe Ghali | 03:44–05:12
True product management is about:

• Identifying user problems
• Validating opportunities
• Defining outcomes
• Building the smallest product that delivers value
• Learning continuously
• Driving business impact
• Making intentional trade-offs
• Empowering teams to experiment

Product managers ask:
“What problem are we solving, and how will we know?”

SAFe often gets interpreted as:
“What features will we build this quarter?”

That distinction is critical.

The Root of the Conflict: Outputs vs. Outcomes

Rosana Johnson | 05:12–06:26
SAFe (as implemented in many companies) tends to push teams into output mode:

• Features
• Velocity
• Story points
• Commitments
• Release trains
• Delivery timelines

Product thinking pushes teams toward outcome mode:

• Customer behavior change
• Value creation
• Adoption
• Retention
• Satisfaction
• Revenue or cost impact

One is activity.
The other is results.

When SAFe ceremonies dominate the calendar, teams default to feature shipping instead of learning.

Where SAFe Actually Supports Product — When Used Correctly

Joe Ghali | 06:26–07:54
Here’s the nuance: SAFe can support product thinking — if it’s implemented as intended, not as a process compliance engine.

SAFe encourages:

• Continual refinement
• Cadence-based planning
• Cross-team alignment
• Transparency of work
• Iterative delivery
• Learning cycles
• MVP thinking within increments

The problem is that many organizations use SAFe as a control mechanism, not an empowerment mechanism.

SAFe isn’t the enemy. Misuse is.

The Misalignment Caused by SAFe Terminology

Rosana Johnson | 07:54–09:18
One of the biggest sources of confusion is overlapping terms.

For example:

• SAFe “Product Manager” ≠ Modern Product Manager
• SAFe “Product Owner” ≠ Discovery Product Owner
• SAFe “Epic” ≠ True Business Opportunity
• SAFe “Feature” ≠ Customer Value Slice
• SAFe “PI Planning” ≠ Product Strategy

People assume the words mean the same thing — they don’t.

This mismatch creates massive tension and misalignment.

Why Product Teams Feel Handcuffed Under SAFe

Joe Ghali | 09:18–10:52
Because product managers end up spending 80% of their time:

• Writing features that teams committed to last PI
• Managing dependencies
• Attending ceremonies
• Explaining delivery delays
• Preparing slides for leadership
• Reacting instead of discovering

And only 20% of their time on actual product work:

• Customer interviews
• Experimentation
• Market research
• Hypothesis testing
• Opportunity assessment

This inversion of priorities leads to frustrated PMs and mediocre products.

The Organizational Structures That Cause Breakdowns

Rosana Johnson | 10:52–12:12
Most conflict arises because SAFe is implemented in organizations that are:

• Hierarchical
• Risk-averse
• Feature-funded
• Project-driven
• Delivery-obsessed

They think scaling Agile means:

• More process
• More control
• More governance
• More tracking
• More meetings
• More structure

But true product thinking requires:

• Autonomy
• Flexibility
• Learning
• Experiments
• Customer connection
• Strategic clarity

Opposing forces create the tension.

Where Product Teams Can Leverage SAFe Effectively

Joe Ghali | 12:12–13:46
There are areas where SAFe can genuinely make product work easier — if approached with the right mindset.

For example:

• PI Planning can surface hidden dependencies early
• Iteration cadence can push teams toward smaller deliverables
• System demos can provide regular checkpoints for outcomes
• ART collaboration can align cross-functional priorities

But these mechanisms only work if teams allow product discovery to guide delivery — not the other way around.

Common Misconceptions About SAFe

Rosana Johnson | 13:46–15:22
A few myths come up regularly:

❌ “SAFe requires product managers to define features upfront.”
No — that’s a misinterpretation. SAFe encourages defining the intent, not the solution.

❌ “SAFe means we can’t do discovery.”
False. Discovery is absolutely allowed — most orgs just don’t make room for it.

❌ “SAFe forces us into waterfall.”
Not really. Teams turn it into waterfall by over-specifying commitments for entire increments.

❌ “Product Managers lose power under SAFe.”
They only lose power if the org assigns PM duties to process roles instead of actual product roles.

The framework itself is flexible — people often are not.

Product Ownership Confusion: PM vs. PO in SAFe

Joe Ghali | 15:22–17:06
Another major pain point is the split between Product Manager and Product Owner in SAFe.

SAFe defines it as:

• PM → owns the roadmap
• PO → owns team backlog refinement

But in modern product practices:

• PM → owns outcomes, strategy, discovery, prioritization
• PO → may not exist at all, OR is a tactical role supporting delivery

This mismatch causes:

• Decision paralysis
• Confusion about responsibilities
• Teams unsure who defines the “why”
• PMs who are too far removed from engineering
• POs who are assigned product responsibility they shouldn’t hold

Many organizations water down both roles in the process.

The Result: Nobody Owns the Actual Product

Rosana Johnson | 17:06–18:16
When SAFe is implemented poorly, this happens:

• PMs get stuck in meetings
• POs write Jira tickets all day
• RTEs run the process
• Architects own decisions
• UX is rushed
• Engineers feel like order-takers
• Leadership demands predictable delivery

And the real question —“What problem are we solving?” gets lost.

This is why product teams feel the friction so intensely.

The Opportunity: Using SAFe as a Delivery Engine, Not a Product Engine

Joe Ghali | 18:16–19:44
Here’s the shift that unblocks everything:

Product discovery happens outside SAFe.
Product delivery happens inside SAFe.

That’s the key.

SAFe is a coordination and delivery framework, not a product strategy framework.

If you separate:

• Discovery (Product)
• Delivery (SAFe)

you unlock both sides.

Product gets room to think.
SAFe gets predictable increments.
Teams get clarity.

The Real Reason SAFe Feels Heavy

Rosana Johnson | 19:44–21:04
SAFe feels heavy not because of the framework —
but because of organizational fear.

Companies adopt SAFe believing:

• “We need more control.”
• “We need more governance.”
• “We need more predictability.”
• “We need deadlines and commitments.”

These fears push teams to:

• Over-plan
• Over-commit
• Over-document
• Over-govern
• Over-ceremonialize

The result:
A rigid system that squeezes out product thinking.

The Product Manager’s Reality in a SAFe Environment

Joe Ghali | 21:04–22:20
Product managers in SAFe orgs often say:

• “I can’t talk to customers — I’m stuck in ceremonies.”
• “I can’t run experiments — our PI is full.”
• “We’re not solving problems — we’re managing dependencies.”
• “Everything is a feature. Nothing is an outcome.”

If you’ve felt this, you’re not alone.

This is the product vs. SAFe cultural gap.

How to Make Product Work Inside SAFe

Rosana Johnson | 22:20–24:42
SAFe becomes workable when organizations adopt these practices:

1. Decouple Discovery From PI Planning

Discovery cannot be scheduled the way delivery is.

2. Stop Treating Features as Requirements

Features should be options, not mandates.

3. Establish Product Outcomes Before Features

If the outcome isn’t clear, don’t fill the PI with features.

4. Empower PMs to Say “No”

SAFe often encourages too much “yes.”

5. Use POs as delivery partners, not mini-PMs

Let them handle flow while PMs handle value.

6. Educate leadership on the difference between output and outcome

SAFe never fixes a lack of product literacy.

The “Feature Factory” Trap

Joe Ghali | 24:42–26:06
SAFe teams often fall into the feature factory trap:

• Features are funded
• Features are sized
• Features are estimated
• Features are committed
• Features are delivered

But nobody asks whether the features created:

• Customer behavior change
• Adoption
• Retention
• Value
• Outcomes

Without outcomes, delivery is just… activity.

And activity ≠ product success.

Where SAFe Actually Helps — When It’s Not Misused

Rosana Johnson | 26:06–27:42
Let’s be clear: SAFe isn’t inherently bad. It becomes harmful when used incorrectly.

When applied with discipline and intention, SAFe can help product teams:

• Create predictable delivery rhythms
• Improve communication across teams
• Reduce hidden dependencies
• Establish visibility for leadership
• Surface risks earlier
• Improve coordination across complex systems

These benefits matter — especially in large organizations.
But they must be applied in service of product outcomes, not as replacements for product thinking.

The Danger of Mistaking Process for Product

Joe Ghali | 27:42–29:10
Many teams fall into this trap:

They confuse doing SAFe with doing product.

Examples:

• Running PI Planning ≠ product strategy
• Filling a backlog ≠ product discovery
• Delivering features ≠ customer value
• Completing stories ≠ solving problems
• Hitting velocity targets ≠ achieving outcomes

This confusion is why many SAFe orgs end up with products that feel disjointed, overbuilt, and under-adopted.

Process is not product.
Process is not customer value.

Why Leadership Defaults to SAFe

Rosana Johnson | 29:10–30:48
Executives often choose SAFe because it provides:

• Repeatable cycles
• Predictability
• Commitments
• Visibility
• Governance
• A sense of control

These things feel comforting.

But here’s the irony:

Predictability is only valuable if you’re building the right thing.

If discovery and product strategy are weak, SAFe only makes the organization more efficient at building the wrong things faster.

How Product Leaders Can Shift the Conversation

Joe Ghali | 30:48–32:06
Product leaders need to drive this message:

“We don’t need predictability first — we need clarity first.”

Predictability on top of unclear goals is waste.

Product leaders must insist on:

• Clear product outcomes
• Opportunity assessments
• Measurable metrics
• Customer insights
• Discovery cadence
• Strategic trade-offs

SAFe can’t create these.
Only product teams can.

Adopting Product Thinking Inside a SAFe Machine

Rosana Johnson | 32:06–34:38
So how do you embrace product thinking inside an organization built around SAFe?

Here’s the practical approach:

1. Start with outcome-driven roadmaps

Replace feature lists with “problems to solve.”

2. Use experiments before adding anything to a PI

If you haven’t validated the opportunity, it doesn’t belong in the plan.

3. Treat features as hypotheses, not guarantees

Every feature should be a test.

4. Protect discovery time

SAFe will consume all available space unless product teams guard discovery.

5. Make PI Planning about options, not commitments

Shift language from “we will build” to “we intend to explore.”

6. Hold leadership accountable for outcomes, not output

This is where real culture change happens.

Why SAFe Teams Rarely Innovate

Joe Ghali | 34:38–36:04
Organizations complain:

• “We’re not innovative.”
• “We’re too slow.”
• “Teams don’t experiment.”
• “We build too much technical debt.”
• “No one is thinking strategically.”

But they don’t realize this is the natural consequence of:

• Filling PIs to 100% capacity
• Overcommitting to features
• Leaving no room for learning
• Prioritizing delivery metrics over customer outcomes
• Rewarding output instead of impact

Innovation requires:

• Slack
• Exploration
• Curiosity
• Signals
• Iteration
• Time

SAFe as practiced in many orgs eliminates these conditions entirely.

The Customer’s Voice Gets Buried Under Process

Rosana Johnson | 36:04–38:06
Another major issue:

SAFe focuses heavily on internal alignment — and unintentionally pushes customers out of the conversation.

Teams spend more time:

• Aligning
• Planning
• Estimating
• Refining
• Grooming
• Syncing
• Attending ceremonies

…and less time:

• Talking to customers
• Reviewing user behavior
• Observing pain points
• Understanding real jobs to be done
• Validating assumptions

The customer slowly disappears from the system.
And nobody notices until adoption drops or users churn.

When SAFe Works Surprisingly Well

Joe Ghali | 38:06–39:48
Despite everything we’ve said, SAFe can be powerful in certain contexts, such as:

• Highly regulated industries
• Large, multi-team platforms
• Long-term infrastructure investments
• Environments requiring coordination across hundreds of people
• Companies with complex enterprise integration needs

In these cases, SAFe brings:

• Alignment
• Visibility
• Sequencing
• Dependency resolution
• Cadence

It just cannot replace product thinking.

Both must coexist — with clarity on the role each plays.

The Real Goal: A Healthy Product + SAFe Partnership

Rosana Johnson | 39:48–42:26
The goal isn’t to eliminate SAFe.
The goal is to rebalance power between Product and Process.

Healthy organizations:

• Let product lead discovery
• Let SAFe guide delivery
• Empower PMs to define problems
• Use SAFe to coordinate teams
• Keep ceremonies lightweight
• Keep customers at the center
• Support experimentation
• Make decisions based on outcomes, not output

When Product leads and SAFe supports, organizations thrive.

Closing Thoughts

Joe Ghali | 42:26–43:48
Here’s the summary:

• Product thinking = outcomes
• SAFe thinking = delivery coordination
• Both matter — but they must be separated
• SAFe should never dictate product decisions
• Product should define the “why”
• SAFe should help execute the “how”

When these roles are clear, teams build better products, move faster, and deliver actual customer value.

Q&A and Closing Discussion

Joe Ghali | 43:48–45:18
Yeah, that’s such a good point, and honestly something we see all the time with teams trying to reconcile product thinking with SAFe. I think the important thing to remember is that SAFe gives you ceremony, structure, and predictability — but it does not replace product management. It doesn’t tell you how to discover value, how to validate problems, how to prioritize strategically, or how to make decisions based on outcomes instead of output. That’s where you come in as the product leader.

Rosana Johnson | 45:18–47:10
Exactly. And I’ll emphasize again: SAFe’s roles and artifacts don’t map cleanly to the modern product management mindset. So there’s naturally friction — especially with PI Planning. It’s extremely output-driven by design. Your job as PM is still to articulate the outcomes, the problems, the user behavior change you expect — and then collaborate with the ART to determine how those outcomes can be supported within the PI structure.

Joe Ghali | 47:10–48:52
Right. One piece of advice for anyone dealing with that tension: Zoom out before you zoom in.
When someone asks you, “What are we building in the next PI?”
Your answer shouldn’t be a list of features.
It should be:

• “This is the business outcome we’re targeting.”
• “This is the user problem we’re solving.”
• “These are the leading indicators we’ll look for.”
  THEN you get into potential solutions.

Rosana Johnson | 48:52–50:40
And document it! Use your outcome tree, product canvas, opportunity canvas — whatever your org uses. The more you socialize outcomes, the easier it becomes for teams to think beyond just features. SAFe doesn’t forbid this thinking — it actually needs it to work well. But nobody gives you that part. Product leaders must fill the gap.

Final Remarks

Joe Ghali | 50:40–52:16
Thank you all for joining today. This is such a nuanced topic, and none of this changes overnight. If you’re living in a feature factory today, if you’re trying to bring outcome thinking into a SAFe environment, if you’re dealing with stakeholder pressure — you’re not alone. These are common challenges, and it takes consistency and clarity to shift behaviors.

Rosana Johnson | 52:16–54:32
Yes — and be kind to yourself. Change is slow. Every time you articulate a problem instead of a feature, every time you anchor a conversation around outcomes instead of outputs, every time you say “Let’s talk about the user behavior we want to influence,” you’re nudging the culture forward.

Joe Ghali | End
Exactly. And feel free to connect with us — we love hearing how teams are working through these shifts. Thank you again for spending an hour with us. Have a great rest of your day!

Rosana Johnson | End
Bye everyone! Thanks again.