Inspired
How to Create Tech Products Customers Love
by Marty Cagan
The 60-Second Take
Inspired is Marty Cagan's account of how strong product organizations actually operate, drawn from decades at eBay, HP, and Netscape and years advising companies through the Silicon Valley Product Group. Its central distinction is between feature teams that receive specifications and empowered teams that receive problems. The book covers the four risks discovery exists to eliminate, why discovery and delivery run in parallel rather than in sequence, the case against feature roadmaps, and what the product manager, designer, and engineering lead each actually contribute.
Shipping Features Is Not the Same as Solving Problems
Most technology companies have product teams, run something they call agile, maintain a roadmap, and ship regularly. A substantial share of what they ship changes nothing.
Marty Cagan's explanation is that the underlying operating model differs from the one strong companies use, in a way the org chart doesn't reveal. He spent his career in product at HP, Netscape, and eBay before founding the Silicon Valley Product Group, and Inspired, substantially rewritten for its second edition in 2017, is his attempt to describe how the best teams actually work rather than how process frameworks say they should.
The book runs to nearly seventy short chapters and functions well as a reference. Underneath the volume sits a small number of principles, and this summary covers those.
What You'll Learn
The difference between feature teams and empowered product teams
The four risks discovery exists to eliminate, and which ones teams avoid
Why discovery and delivery run in parallel rather than in sequence
What's wrong with a traditional feature roadmap and what replaces it
What the product manager actually owns, distinct from the designer and the engineer
Feature Teams Versus Empowered Teams
The distinction Cagan returns to throughout is between two operating models.
A feature team receives a set of features to build, usually via a roadmap decided elsewhere, and is measured on delivering them on schedule. The team's job is execution. Cagan calls this an order-taking arrangement, and its people mercenaries: paid to produce outputs someone else specified.
An empowered team receives a problem to solve, along with the business outcome it's meant to move, and has the autonomy to determine the solution. It's accountable for whether the outcome improved, not for whether the features shipped. Its people are missionaries: they understand the mission and believe in it.
The consequence is the reframe that matters most: outcomes over output. A feature team that ships everything on the roadmap and moves no business metric has succeeded by its own measure and failed by any useful one. Cagan's position is that this describes an enormous amount of product work.
The requirement for empowerment is that leadership provides genuine context, meaning a compelling product vision, a clear strategy, and objectives expressed as problems or metrics rather than as solutions. Empowerment without that context is abdication, and Cagan is clear that the failure is usually a leadership failure rather than a team one.
The Four Risks
The mechanism that makes empowerment work is discovery, and its purpose is precise: separate good ideas from bad ones as quickly and cheaply as possible, before engineering capacity is committed.
Four risks have to be addressed.
Value risk. Will customers actually choose this, buy it, or use it? Cagan treats this as the hardest and most important question.
Usability risk. Can users figure out how to use it?
Feasibility risk. Can our engineers build this, with the technology, data, and time available?
Business viability risk. Does it work for the rest of the business? Legal, compliance, finance, sales, marketing, and brand all have to be able to live with it, and this is the risk teams most often discover late, when a stakeholder blocks a launch.
Cagan's observation about which risks teams actually tackle is the most useful diagnostic in the book. Teams gravitate toward usability and feasibility because those are the risks they can do something about directly. Value and viability get outsourced to a senior leader or a compliance function, because they're harder, more political, and less tractable. The result is a stream of perfectly usable, well-engineered features nobody wanted.
The corresponding sequence he recommends inverts what most teams do: address value first, then usability, then feasibility, rather than starting with what's buildable.
Discovery and Delivery Run in Parallel
The structural point people most often miss is that discovery isn't a phase preceding delivery. Both run continuously and simultaneously, on the same team, with the same people.
Delivery produces shippable, reliable software. Discovery produces a validated backlog: ideas that have been tested cheaply enough that the team has reasonable confidence before engineering time is committed. The output of discovery is not a specification, it's evidence.
The tools are prototypes rather than documents. Cagan's argument is that most analysis is a poor substitute for putting something in front of a user, and that the great majority of discovery prototypes should be built by product designers, quickly and disposably, specifically to answer a question rather than to demonstrate a solution.
He also emphasizes reference customers, meaning real customers using the product in production, paying for it, and willing to tell others they value it. His point is that in a new product you're developing the customer alongside the product, and a small set of genuine reference customers is worth more than a large set of interested prospects.
Roadmaps, and Who Does What
Cagan's critique of traditional roadmaps follows directly. A feature roadmap commits to solutions before problems are understood, manufactures false certainty about dates and outcomes, and makes it politically difficult to change course when the team learns something. Two things are almost always true of a feature roadmap: at least half the items won't produce the value expected, and the ones that do will take longer than planned.
His replacement is an outcome-based roadmap: commitments to solving specific problems or moving specific metrics, with the team free to determine how. High-integrity commitments to a date exist where genuinely needed, but they're the exception rather than the format.
On roles, he's specific. The product manager owns value and viability, and must have deep knowledge of the customer, the data, the business and its stakeholders, and the market. That's the substance of the job; facilitating a process is not. The product designer owns usability and the experience, and is a partner in discovery rather than a service function receiving requirements. The engineering lead owns feasibility and, crucially, participates in discovery, because engineers who see the problem early frequently produce the best solutions and are the ones who know what's newly possible.
That trio, working together on the same problem, is the unit Cagan considers the foundation of strong product organizations.
Inspired at a Glance
Empowered team. Given a problem and an outcome, with autonomy over the solution and accountability for results.
Feature team. Given a specification to build, measured on shipping it, with the thinking done elsewhere.
Outcomes over output. Success measured by problems solved rather than features delivered.
The four risks. Value, usability, feasibility, and business viability, addressed before committing engineering time.
Continuous discovery. Running alongside delivery rather than preceding it, producing evidence rather than specifications.
Outcome roadmap. Commitments to problems and metrics rather than to a list of features and dates.
The trio. Product manager, designer, and engineering lead working the problem together.
A Quick Start Guide to Moving Toward Empowered Teams
Check what your team is given. If it's a list of features, you have a feature team regardless of what the process is called.
Name the four risks for your next item. Write down how you'll address value, usability, feasibility, and viability, and notice which ones you'd rather skip.
Test value before anything else. Put a rough prototype in front of real customers before you evaluate whether it's buildable.
Bring engineers into discovery. Involve them when the problem is framed, not when the solution is handed over.
Convert one roadmap item into an outcome. Restate a feature commitment as the metric it's meant to move, and let the team choose the solution.
Who Should Read Inspired (and Who Can Skip It)
Read it if you work in product management, particularly in your first few years, since this is the closest thing the field has to a standard reference.
Read it if you lead a product organization and suspect your teams are executing rather than solving. The feature-team diagnosis is aimed exactly there.
Read it if you're an engineer or designer who wants to understand what a good product manager should be contributing, and what to expect from one.
Skip it if you want step-by-step process. Cagan is explicit that this isn't a methodology, and readers wanting a framework to implement will find it frustratingly principle-based.
Skip it if your organization can't support empowerment. Many of these ideas require leadership willing to give teams problems instead of specifications, and applying them from below has limits Cagan acknowledges more in his later books.
Skip it if you're outside technology products. The examples and economics are specific to software, and the transfer is not straightforward.
Final Reflections
The reason this book became the field's default text is that its central distinction is both simple and diagnostic. Asking whether your team receives problems or features answers a great deal about why the work feels the way it does, and it usually reveals that a company running textbook agile ceremonies is still operating a feature factory.
The four risks are the other durable contribution, and the observation about which risks teams avoid is the sharpest thing in the book. Value and viability are harder, more political, and less satisfying to work on than usability and feasibility, which is precisely why so much energy goes into polishing things nobody needed.
Two caveats worth carrying. The book describes how strong product companies work, drawn substantially from well-resourced technology firms with genuine product cultures, and readers in different environments will find the gap between the model and their reality is large. Cagan wrote Empowered and Transformed partly in response to exactly that, so Inspired on its own can leave a reader convinced of the destination without a route. And the second edition's near-seventy chapters make it a better reference than a cover-to-cover read; the core arguments occupy a fraction of the length.
The Bottom Line
If your team is handed features to build, no process change will make it a strong product team. Give it a problem and an outcome, address value before feasibility, and measure whether anything actually improved.
Frequently Asked Questions
What are the four risks in product management?
Value risk, whether customers will choose it; usability risk, whether they can use it; feasibility risk, whether it can be built; and business viability risk, whether it works for legal, finance, sales, and the brand. Discovery exists to address all four before engineering commits.
What's the difference between a feature team and an empowered team?
A feature team receives specifications and is measured on shipping them. An empowered team receives a problem and a target outcome, determines the solution itself, and is accountable for whether the outcome improved.
Why does Cagan object to product roadmaps?
Traditional feature roadmaps commit to solutions before problems are understood, create false certainty about value and timing, and make changing course politically difficult. He advocates outcome roadmaps that commit to problems or metrics while leaving solutions to the team.
Business Floss is reader-supported. When you use our links we may earn an affiliate commission that helps us keep the site running. Thank you for your support!
