Back to Home

Why Products Fail: Marty Cagan's Key Insights

•
8 min read
startupproductfailureteams

Why Products Fail: Marty Cagan's Key Insights

Most products fail. Even with good teams, big budgets, and smart people. Marty Cagan, who worked at companies like eBay and Netscape, explains why this happens and how to fix it.

The problem isn't bad technology or lazy teams. It's how most companies think about building products.

Table of Contents

  1. The Wrong Model: Why most companies fail
  2. The Business Case Fallacy
  3. How Great Companies Actually Work
  4. Two Types of Teams
  5. The Discovery Process
  6. Why Engineers Matter More Than You Think
  7. The Real Cause of Product Failure
  8. How to Fix Your Product Process
  9. Real Examples from Top Companies
  10. Common Pitfalls and Anti-patterns
  11. Templates You Can Use

The Wrong Model: Why most companies fail

Most companies work like this:

  1. Management decides what to build
  2. Teams get a list of features to build
  3. Everyone focuses on delivering those features
  4. Success is measured by "did we build it?"

This sounds logical, but it's actually backwards.

The Business Case Problem

Here's what usually happens:

  • Someone has an idea
  • They write a business case with revenue predictions
  • Management approves it
  • Teams build it
  • It fails

Why? Because business cases are just guesses. You can't predict if an idea will work before you test it.

Example: A company might say "If we add this feature, we'll get 20% more users." But they have no proof this is true.

The truth: Business cases kill innovation because they demand certainty where none exists.

How Great Companies Actually Work

Companies like Amazon, Google, and Netflix work differently:

1. They Focus on Problems, Not Features

Instead of saying "build this feature," they say "solve this problem."

Bad approach: "Build a chat feature" Good approach: "Help users communicate better"

2. They Test Ideas Before Building

Great companies:

  • Build small tests first
  • See what users actually do
  • Learn from real data
  • Only build what works

3. They Empower Teams

Strong teams are trusted to:

  • Understand the problem deeply
  • Try different solutions
  • Learn from failures
  • Find what actually works

Two Types of Teams

Weak Teams (Feature Factories)

  • Get told what to build
  • Focus on delivering features
  • Don't learn from users
  • Build things that don't work
  • Act like mercenaries

Strong Teams (Problem Solvers)

  • Understand the real problem
  • Experiment with solutions
  • Learn from users
  • Build things that work
  • Act like missionaries

Key difference: Weak teams build what they're told. Strong teams solve problems they understand.

The Discovery Process

Great companies do "product discovery" before building:

1. Understand the Problem

  • Talk to users every week
  • Watch what they do
  • Find the real pain points
  • Understand the context

2. Test Solutions Quickly

  • Build simple prototypes
  • Test with real users
  • Learn what works
  • Fail fast and cheap

3. Only Build What Works

  • Kill ideas that don't work
  • Double down on what does work
  • Build with confidence

The key: Discovery is not optional. It's essential.

Why Engineers Matter More Than You Think

Engineers aren't just builders. They're problem solvers who:

  • Know what's technically possible
  • Understand what's scalable
  • Can suggest better solutions
  • Often have the best ideas
  • Can help with discovery

Key insight: Let engineers help solve problems, not just build features.

Example: An engineer might say "Instead of building this complex feature, we could solve the same problem with a simple API change."

The Real Cause of Product Failure

Products fail because companies:

  1. Build features instead of solving problems
  2. Don't test ideas before building
  3. Don't learn from users
  4. Focus on output instead of outcomes
  5. Don't empower their teams

The root cause: You're optimizing for the wrong thing.

How to Fix Your Product Process

1. Change Your Mindset

  • Focus on problems, not features
  • Measure outcomes, not output
  • Embrace learning and testing
  • Accept uncertainty

2. Empower Your Teams

  • Give teams real problems to solve
  • Trust them to find solutions
  • Let them experiment and learn
  • Don't tell them what to build

3. Build a Learning Culture

  • Test ideas before building
  • Learn from failures
  • Celebrate learning, not just success
  • Make discovery a priority

4. Focus on Users

  • Talk to users regularly
  • Watch what they do
  • Build what they actually need
  • Measure what matters to them

Real Examples from Top Companies

Netflix: Instead of guessing what shows to make, they test ideas with small audiences first. They use data to understand what people actually want to watch.

Amazon: They constantly test new features with small groups before rolling them out to everyone. They use A/B testing to learn what works.

Google: They run thousands of experiments to find what actually works. They're not afraid to kill ideas that don't work.

Spotify: They use "squads" - small teams that own problems, not features. Each squad is responsible for solving a specific user problem.

Common Pitfalls and Anti-patterns

Here are mistakes to avoid:

  • Building from roadmaps: Don't build features from a list
  • Not talking to users: You can't solve problems you don't understand
  • Not testing ideas: Don't build things you haven't validated
  • Focusing on features: Focus on problems instead
  • Not empowering teams: Let teams solve problems, don't tell them what to build
  • Measuring output: Measure outcomes instead
  • Avoiding failure: Failure is how you learn

Templates You Can Use

Problem Statement Template

Write this for each product idea:

  1. What problem are we solving?
  2. Who has this problem?
  3. How do they solve it today?
  4. Why is our solution better?
  5. How will we know if we're right?

Discovery Checklist

Before building anything, ask:

  • Have we talked to users about this problem?
  • Do we understand why this problem matters?
  • Have we tested our solution with real users?
  • Do we have evidence this will work?
  • Are we solving the right problem?

Team Empowerment Checklist

For each team, ask:

  • Do they understand the problem they're solving?
  • Do they have the skills to solve it?
  • Are they trusted to make decisions?
  • Do they have access to users?
  • Are they measured on outcomes, not output?

Weekly Discovery Questions

Ask these every week:

  1. What did we learn about our users?
  2. What assumptions did we test?
  3. What did we learn from our experiments?
  4. What should we try next?
  5. What should we stop doing?

The Bottom Line

Product failure isn't about bad technology or lazy teams. It's about the wrong process.

Great companies:

  • Focus on solving real problems
  • Test ideas before building
  • Learn from users
  • Empower their teams
  • Measure outcomes

Weak companies:

  • Build features from roadmaps
  • Don't test ideas
  • Don't learn from users
  • Tell teams what to build
  • Measure output

The choice is yours. Will you build features, or will you solve problems?

Key Takeaways

  1. Focus on problems, not features
  2. Test ideas before building them
  3. Let teams solve problems, not just build features
  4. Learn from users constantly
  5. Measure outcomes, not output
  6. Empower your teams
  7. Make discovery a priority

Remember: Building the right thing is more important than building things right.

This article is based on insights from Marty Cagan's talk "The Root Cause of Product Failure" at USI, drawing from his experience at companies like eBay, Netscape, and HP.

Sources and further reading:

  • Marty Cagan's blog: svpg.com
  • Inspired: How to Create Tech Products Customers Love
  • The Lean Startup by Eric Ries
  • The Mom Test by Rob Fitzpatrick
  • Continuous Discovery Habits by Teresa Torres