Understanding Marty Cagan’s Product Model: Empowering Teams for Better Outcomes

Signal Boost: "The Dog Days Are Over", Florence and the Machine. The song captures the feeling of breaking old habits and running toward something better, which is exactly like moving from traditional delivery models to empowered product thinking.

If you want to build products that customers actually care about and stop wasting time on features that do not matter, you need to rethink how your teams work from the ground up.

If you have spent any time around product teams, you have probably heard the name Marty Cagan. Maybe even uttered with a bit of awe, like the way musicians talk about Prince or surfers talk about Kelly Slater.

His book, Inspired: How to Create Tech Products Customers Love, is not just another manual. It is a manifesto for a different way of working, one where empowered teams build products that solve real problems rather than just ticking boxes.

And in a world still cranking out feature factories and bloated roadmaps, Cagan’s product model feels more relevant than ever.

How Does Marty Cagan’s Product Model Work?

At its core, the product model describes how empowered cross functional teams work together to discover and deliver products that solve real customer problems.

It is built on collaboration, trust, and shared accountability for outcomes.
Rather than being handed requirements and deadlines, teams are given problems to solve and the autonomy to figure out how to solve them.

"Empowered teams do not take orders. They solve problems."

This model challenges traditional top down ways of working and puts creativity, responsibility, and decision making where it belongs, inside the team.

What Makes Empowered Product Teams Tick?

At the centre of Marty’s model is a simple but powerful idea: great products come from empowered teams. Not from executives handing down fully formed requirements. Not from committees designing by consensus.

Real product innovation happens when you trust small cross functional teams, typically a Product Manager, Product Designer, and Engineers, to discover and deliver solutions together.

The Product Manager is not a backlog administrator. The Product Designer is not just polishing screens. The Engineers are not order takers.

Each brings their creativity, insights, and expertise to the table. They work as a unit, discovering the right solution together, like a band improvising their way to a song that no one could have written alone.

"Empowered teams are not a delivery machine. They are a discovery engine."

Structuring and Supporting Empowered Product Teams

In this model, product teams are small, stable, and cross functional. They have all the skills they need to discover and deliver solutions without being pulled apart or slowed down by constant handovers.

A typical empowered product team includes:

• Product Manager: Ensures the solution is valuable and viable.
• Product Designer: Ensures the solution is usable and delivers a great customer experience.
• Engineers: Ensure the solution is technically feasible, scalable, and maintainable.
• Depending on the problem space, teams might also include:
• Data Analysts or Data Scientists
• Quality Engineers
• Technical Leads

These teams are small, usually between four and ten people. They are long lived and accountable for outcomes, not just outputs. Think of it like a highly skilled expedition team, not a convoy of departments trying to coordinate over walkie talkies.

Each team owns a problem space — whether it is improving customer onboarding, speeding up checkout flows, or increasing engagement — and they work towards real business outcomes rather than just shipping features.

"Teams own problems. They do not rent requirements."

What About Business Analysts?

In Marty Cagan’s product model, Business Analysts are not part of the core empowered product team. Instead, discovery is a collaborative effort between the Product Manager, Product Designer, and Engineers.

That said, in large or heavily regulated organisations, Business Analysts can still play a valuable supporting role, helping to uncover business rules, technical constraints, or regulatory requirements. They provide specialist input into discovery but do not own requirements or define the solutions.

Think of the Business Analyst as supporting the discovery process from the side, offering expertise when needed but never replacing the team’s responsibility for owning solutions.

"Business Analysts support discovery. They do not own it."

Core and Supporting Roles in Empowered Product Teams

To help clarify how empowered teams operate, it is important to understand which roles are inside the product team itself and which roles sit outside, supporting the team without taking control.

Inside the Product Team (Core Roles)

These roles are embedded in the team, collaborating daily to discover and deliver solutions:

Discovery and delivery are shared responsibilities across the team. There are no handovers between roles. The team is accountable for outcomes.

Outside the Product Team (Supporting Roles)

These roles support the empowered team but are not part of its daily structure:

Supporting roles enable the product team’s success without directing product decisions. They help clear the path, connect the dots across the organisation, and drive adoption while respecting the team's autonomy.

"Support roles clear the path. They do not set the direction."

Visual Summary:

[ Empowered Product Team ]
- Product Manager
- Product Designer
- Engineers
    |
    | (Supported by)
    v
[ Supporting Roles ]
- Delivery Manager
- Scrum Master
- Project Manager
- Change Manager
- Business Analyst

The Role of Architecture in Empowered Product Delivery

Architecture plays a critical enabling role in empowered product delivery. Technical architecture, which governs how codebases, APIs, and services are structured, sits inside the squad and is owned by the team delivering the outcomes.

Wider strands of architecture — solution, data, and business architecture — sit outside the squads. Their role is not to control teams, but to enable them: providing guidance, standards, and strategic alignment to ensure that individual outcomes contribute to the broader system and enterprise.

In the empowered model, architects collaborate with product teams, respecting their autonomy while helping shape sustainable, scalable solutions.

Customer Outcomes --> Owned by Product Manager and Squad
|-- Solution Architect (collaborates across system boundaries)
|-- Data Architect (supports data integrity and governance)
|-- Business Architect (aligns value streams to business outcomes)
|-- Technical Architecture --> Owned inside squad

"Architects do not design solutions for teams. They design systems where empowered teams can thrive."

Delivery Manager: Supporter, Not Micromanager

In an empowered product team, the Delivery Manager plays a critical supporting role. They are there to protect flow, remove systemic blockers, and help the team continuously improve how they deliver outcomes.

They are not there to assign tasks, micromanage individual work, or pressure teams to rush delivery. Micromanagement undermines the core trust that makes empowered teams work.

Instead, a great Delivery Manager clears the path — so the squad can stay focused on solving real customer problems, sustainably and effectively.

“The best Delivery Managers do not control the team — they clear the path.”

In empowered product teams, every role exists to enable ownership, not override it, and the Delivery Manager is no exception.

Quality Ownership Inside Empowered Squads

In empowered product teams, quality is owned inside the squad. Unit testing sits fully within the team’s day-to-day development practices, ensuring that code behaves correctly at a granular level.

Integration testing, where multiple systems or services must work together, is also largely owned within the squad — validated as part of sprint delivery, not left to external teams.

Where integrations span wider boundaries, teams collaborate with others to agree contracts, test strategies, and environments. Empowered delivery means testing early, often, and as part of delivery, not as an afterthought or a separate project.

Handling Enabling Work in the Product Model

Empowered product teams focus on delivering customer and business outcomes, but some internal activities — like data migration and data integration — play a critical role in enabling those outcomes. It is essential that these are handled visibly, strategically, and always anchored to the value they unlock.

Work like data migration and integration enables customer outcomes.
• Product Managers prioritise it based on value
• Engineers and Architects deliver it with clarity

"If it does not enable outcomes, it does not belong on the roadmap."

Handling Enabling Work Like Data Migration

While empowered product teams focus primarily on delivering customer and business outcomes, some technical activities — such as data migration — play a critical enabling role.

Migration work is not treated as a standalone project or an output in itself. Instead, it is framed as an enabler that unlocks or protects customer value. Product Managers prioritise migration activities based on the outcomes they support, while engineering and architecture leads plan and deliver the technical execution.

In empowered models, even internal work like migration remains visible, strategic, and tied back to the ultimate value we are trying to create.

Handling Enabling Work Like Data Integration

Data integration activities also play an important enabling role in empowered product teams. While integrations themselves are not customer value, they often directly unlock customer features, journeys, or operational capabilities.

Product Managers prioritise integrations based on the outcomes they enable, not simply because a connection exists. Engineering and architecture teams design and deliver the integration work, ensuring it supports flow, security, and scalability.

In the product model, integrations are treated as strategic enablers that must be visible, prioritised thoughtfully, and tied back to real customer or business outcomes.

Environment Strategy and Empowered Squads

In empowered product delivery, environment strategy is a shared responsibility. Platform or Enablement teams own the global environment strategy — defining resilient, secure, scalable patterns for how environments are provisioned, operated, and governed.

Squad Technical Architects design and manage how their services use these environments, ensuring they can deliver and test outcomes effectively within the organisational guardrails.

This separation of concerns allows teams to move fast with confidence, without compromising the stability, security, or sustainability of the wider technology landscape.

“Empowered teams move fast not by ignoring guardrails, but by trusting the road beneath them.”

Owning the Route to Live in Empowered Squads

In empowered product delivery, each squad owns its Route to Live — the safe, sustainable pathway for moving code from development to production.

The Tech Lead or squad-level Technical Architect designs and continuously improves this flow, ensuring that integration, testing, deployment, and monitoring are all handled within the team.

Platform or Enablement teams provide the underlying infrastructure, tools, and guardrails, but it is the squad that owns how their product moves into customer hands. This ownership reinforces autonomy, accountability, and confidence in delivery.

“In empowered delivery, the journey to production is not a handover — it is part of the product.”

Understanding Product Work versus Project Work

One of the most important distinctions Cagan draws is between product work and project work. Project work is about delivery, getting something built and shipped. Product work is about discovery, figuring out what should be built in the first place.

In many organisations, delivery gets all the attention. It is tangible, trackable, and reassuring. But in Marty’s world, discovery is just as important. Because building the wrong thing efficiently is still failure.

• Project work focuses on delivery.
• Product work starts with discovery.

"Finishing the race means nothing if you were on the wrong course."

Seeing Empowered Teams in Action

Imagine a product team at a fintech company tasked with improving their mobile app sign up process.

Instead of being told "Add three more verification steps," they are given the real problem: "Too many users drop off before completing sign up."

• The Product Manager digs into customer behaviour.
• The Product Designer explores friction points in the journey.
• The Engineers test rapid prototypes for smoother authentication.

Together, they discover that simplifying account creation rather than adding steps is the answer.

That is an empowered product team in action.

A team is asked to reduce drop off during sign up.

• They explore the journey
• They prototype and test
• They simplify, not complicate

They discover a better solution than anyone could have prescribed.

Separating Product Model from Delivery Methodology

It is worth clearing up a common misunderstanding. The product model Marty describes is independent of whether you use Agile, Waterfall, or any other delivery methodology.

You can run an empowered product model inside an Agile framework. You can misapply Agile ceremonies and still run a top down feature factory. You can even deliver in Waterfall stages if discovery is properly done, if teams are trusted to solve problems, and if outcomes are the real measure of success.

In simple terms:

They are different gears in the machine. Confusing them is a recipe for a very expensive and very well organised failure.

"Agile is a delivery rhythm. Empowerment is a leadership choice."

Focusing on Outcomes Not Outputs

Cagan challenges us to stop measuring success by outputs, such as lines of code, features shipped, or roadmaps completed, and to focus on outcomes:

• Did we solve the customer’s problem?
• Did we create real business value?

It sounds obvious.
Yet so many organisations still celebrate delivery milestones even when the product misses the mark.

In Marty’s model, outcomes are the only scoreboard that matters.

Outputs are not the goal. Outcomes are.

• Did we solve the customer problem?
• Did we deliver business value?

"Shipping is not the goal. Impact is."

Common Pitfalls and Misunderstandings in Product Models

There are a few easy traps organisations fall into when trying to adopt a product model:

• It is not just running Agile ceremonies faster.
• It is not an excuse for chaos and a lack of accountability.
• It is not a rejection of deadlines or delivery disciplines.
• It is not about teams doing whatever they like without business goals.

It is also not about removing traditional delivery roles. Project Managers still have a role, but it is at the programme or initiative level, helping coordinate work around empowered teams rather than being inside them.

Change Managers remain critical, ensuring that what gets built is actually adopted and embedded into daily business operations.

In a true product model, Product Managers, Engineers, and Designers are empowered to discover and deliver the right solutions, while Project and Change Managers provide support from the sides rather than commanding from the centre.

• Doing Agile faster, not better
• Using empowerment as an excuse for chaos
• Replacing delivery roles without redefining responsibilities

"Empowerment without clarity is confusion."

RACI at a Glance

In an empowered product model, clear ownership is critical, but it is not about rigid command chains. Instead, different roles are responsible and accountable for different parts of discovery, delivery, and adoption.

To support clear ownership in empowered product teams, it is helpful to use the RACI model:

• Responsible — The people who do the work.
• Accountable — The person who owns the outcome and decision.
• Consulted — People who provide input or advice.
• Informed — People kept updated on progress or outcomes.

Each activity should have one clear Accountable person, while others may be Responsible, Consulted, or Informed as needed.

"Clear accountability builds trust. Shared responsibility builds collaboration."

Building Trust in Product Teams

The real kicker in Cagan’s model is that it demands trust. Leaders have to trust teams. Teams have to trust each other.

Everyone has to be okay with a bit of uncertainty, a few wrong turns, and letting go of the illusion that everything can be planned in advance.

In some companies, that is a cultural shift as big as turning a cargo ship.

But when it clicks, it is transformational. Work becomes faster, more creative, and much closer to what customers actually need rather than what someone guessed six months earlier.

What It All Comes Down To

The world Marty Cagan described in Inspired is not utopian. It is achievable, but only for organisations willing to do the hard work:

• Empower teams.
• Value discovery as much as delivery.
• Measure outcomes rather than outputs.
• Build a culture of trust.

In 2025, with AI rewriting the rules of competition and customer expectations rising faster than ever, you cannot afford to run product the old way.
Marty's product model is no longer a nice to have.
It is the difference between companies that adapt and thrive, and those that drift into irrelevance.

If you are serious about building products customers love, it might be time to stop focusing on delivery speed and start focusing on how empowered your teams really are.