Books Like Inspired: When to Read Customer-Led Development

If you want a book like Inspired that connects product decisions to named customers and customer commitments, consider Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything by Spencer Shulem. It is a related next read with a different scope: how customer evidence moves through a company, rather than a replacement edition of Marty Cagan's book.

Disclosure: this comparison is published by the author of Customer-Led Development. Choose Inspired for its product-team and discovery framework; choose Customer-Led Development when your question is how sales, support and product carry evidence and commitments into delivery. The detailed comparison below explains the difference.

The ideas here draw on Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.

Marty Cagan's Inspired taught a generation of product managers that the team should decide how to solve a problem, not the stakeholder with the loudest opinion. Customer-Led Development asks a harder question one level up: can anyone in the company name the customers behind that problem?

Both books want the same thing: products people actually use. They disagree about who has to change to get there. This is an honest comparison, written with real respect for Cagan, whose work shaped how most of us think about product.

Each book in one paragraph

Inspired (Marty Cagan, 2008; 2nd edition 2017)

Cagan, founder of Silicon Valley Product Group and a veteran of HP, Netscape and eBay, wrote the book that defined modern product management. Its core argument: most companies run product as a feature factory, where executives and sales hand teams a roadmap of solutions and teams deliver them. That fails, because most ideas don't work the way we hope. Instead, give a small, cross-functional product team (product manager, designer, tech lead) a problem to solve, and let it run fast product discovery to test ideas against four risks before committing engineering time: value, usability, feasibility and business viability. The second edition sharpened this into the case for empowered product teams, a theme Cagan expanded in Empowered (2020, with Chris Jones) and Transformed (2024).

Customer-Led Development (Spencer Shulem, 2026)

Customer-Led Development starts from a different diagnosis: the problem isn't only how product teams work, it's how customer truth moves (or fails to move) through an entire company. Its forcing function is blunt. If you can't name the specific customers behind a decision, you aren't customer-led; you're merely customer-influenced. The book lays out three interlocking systems: the Customer-Led Organization (how the company decides), Customer-Led Development (how it builds), and Customer-Led Growth (how it expands through customers). It's written for a moment when AI can build almost anything, which makes knowing what to build, and for whom, the scarce resource.

Inspired vs Customer-Led Development at a glance

Where they agree

People sometimes frame these books as rivals. On most of the fundamentals, they're allies.

• Feature factories fail. Both books reject the model where a roadmap of solutions gets handed down and teams are measured on shipping it. Velocity means nothing if nobody uses what you ship.
• Value is the hard part. Cagan's value risk (will anyone buy or use this?) is the risk Customer-Led Development is obsessed with. The difference is mostly in how each book reduces it.
• Outcomes over output. Both measure success by what changes for customers and the business, not by what ships.
• Talk to real, specific customers. This is the overlap people miss. Inspired recommends a customer discovery program: building a product alongside a small set of real reference customers, chosen deliberately, who you want to become public advocates. That's names, not personas. Customer-Led Development takes the same instinct and applies it to every decision, not just new products.
• Product managers aren't backlog clerks. Both see the job as owning the outcome, not transcribing requests.

If you've absorbed Inspired, you're most of the way to agreeing with the customer-led argument. The split is about scope and evidence.

Where they differ

1. The team vs. the company

Cagan's model fixes the product team. Give the team a problem, protect it from stakeholder roadmaps, staff it with strong people, and it will out-learn and out-ship a feature factory.

Customer-Led Development argues that a great team inside a broken company still loses signal before it ever reaches them. The book describes the familiar chain: sales hears a need and passes along its interpretation, product reinterprets it against the roadmap, engineering builds what it understood, marketing positions the result. Every handoff adds interpretation, and every interpretation adds error. The customer gets something that resembles what they asked for.

Better communication won't fix that. The book's answer is to remove the layers: build systems where raw customer signal reaches decision-makers intact, and where truth flows horizontally (support to PM, sales to the team that can act) instead of climbing a hierarchy and waiting for a quarterly review.

2. Experiments vs. names

In Inspired, the primary evidence is learning from discovery: prototypes, user tests, and quick experiments that tell you whether an idea survives contact with reality. Cagan is skeptical of building what customers ask for, because customers often don't know what's possible. (Paraphrased.)

Customer-Led Development adds a different kind of evidence that comes before and after the experiment: attribution. Every feature has customer names attached before development starts. Every decision can say which customers drove it and where their words are. When it ships, those customers hear about it directly, not through a generic release note.

These aren't contradictory. Names tell you whose problem you're solving; experiments tell you whether your solution works. But the emphasis matters. A team can run beautiful experiments on a problem no paying customer has.

Rule of thumb: Experiments tell you if a solution works. Names tell you if the problem was worth solving.

3. Who sees the customer

In Cagan's world, the product trio does discovery and carries customer understanding into decisions. Other functions are important stakeholders.

Customer-Led Development wants what it calls a unified brain: a single source of customer truth everyone sees. Not so everyone agrees, but so everyone disagrees about the same facts. That turns arguments that used to be settled by politics into arguments you can settle with evidence. Its five-part CLO Constitution makes this operational:

1. Customer voice is unfiltered. No department translates; the raw signal stays accessible.
2. Decisions trace to customer names. Not segments, not personas.
3. Success equals customer success. Departmental metrics matter only as far as they serve customer outcomes.
4. Truth flows horizontally. Straight to whoever can act on it.
5. Feedback loops are immediate. Hours, not months, for the feedback that warrants action.

4. The gap between saying and doing

Cagan focuses on what great product companies do. Customer-Led Development spends a lot of energy on the gap between what companies say and what they actually do. It cites a McKinsey survey of more than 500 senior executives in which 63% named customer feedback as a top source of growth ideas, but only 15% said they consistently use customer input in decisions (McKinsey Quarterly). That gap is the book's whole target: the distance between customer-influenced and customer-led.

Where Inspired assumes resources most teams don't have

This isn't a knock on Cagan. He's candid that most companies don't work the way he describes, which is a big reason he went on to write Empowered and Transformed. But if you read Inspired from inside an ordinary company, you'll notice its model quietly depends on things many teams lack:

• A real product trio. Many teams share one designer across several squads, or have none.
• Leadership that hands out problems, not features. Plenty of PMs receive a dated roadmap from executives and have no authority to question it.
• Engineers with time for discovery. In understaffed teams, every hour of discovery competes with a delivery commitment.
• Strong product leaders who coach. Cagan puts a lot of weight on managers developing PMs. Many PMs report to someone who has never held the role.
• Easy access to customers. In sales-led B2B companies, the account owner often controls the relationship.

When those conditions are missing, a PM who reads Inspired knows what good looks like but can't get there alone. Here the customer-led approach offers a different kind of leverage. You don't need permission to be empowered to ask, in a roadmap meeting, which customers this is for. Attribution is a question anyone can raise, and it's hard to argue against in public.

Rule of thumb: If you can't win the argument for empowerment, start with the argument for names. It needs no reorg.

What changes when AI builds

Inspired's second edition arrived before AI coding tools changed the cost of shipping. Cagan's four risks still hold, but their weights are shifting:

• Feasibility risk is shrinking fast. More things are buildable, by fewer people, in less time.
• Usability risk is partly easing, as iteration gets cheaper.
• Value risk doesn't move at all. AI can build the feature; it can't make a customer need it.
• Viability risk remains a judgment call about your business.

The line between discovery and delivery also blurs. When a working version costs roughly what a prototype used to, the discipline of testing cheaply before building expensively loses some of its economic logic. What remains scarce is knowing what's worth building.

That's the bet at the center of Customer-Led Development. If building gets cheap, the cost of building the wrong thing doesn't disappear; it multiplies, because you can now build wrong things faster. The book points to Pendo's research finding that 80% of features are rarely or never used, which it translates into up to $8.4 million a year in waste for a $50M company (Pendo, 2019 Feature Adoption Report). Cheaper production makes that number easier to hit, not harder.

In an AI-built world, the forcing function shifts from "can we build it?" to "who, by name, needs it?" Inspired's value risk becomes the whole game, and attribution is the most direct way to manage it.

The honest weaknesses of each

Inspired

• It can create excellent teams that are islands, doing rigorous discovery while sales, support and marketing operate on different versions of the customer.
• In weaker hands, "empowered" drifts into "trust the PM's taste," with discovery as decoration.
• Its staffing assumptions are a reach for small or under-resourced organizations.

Customer-Led Development

• Attribution can tilt toward the loudest or largest accounts if you weight by revenue without judgment.
• Named customers are, by definition, current customers. You need deliberate effort to hear from the people who didn't buy.
• It asks a lot of the whole company, which is harder to start than changing one team.

The best counter to the "you'll only build what customers ask for" worry is a story the book tells about Intuit. Early on, Intuit employees waited in computer stores until someone bought Quicken, then asked to follow them home and watch the install. Later, surveys showed many customers using Quicken at work to keep their company's books. Scott Cook said Intuit ignored that for four years; when it finally built QuickBooks for them, the business became, by Cook's 2014 account, 11 times larger than Quicken (Inc.). Nobody requested QuickBooks. Paying close attention to specific customers revealed it.

A five-minute test for which book you need

Customer-Led Development includes a simple diagnostic. Take your last five major decisions (roadmap items, priorities, strategic shifts) and ask three questions of each:

• Can you name the specific customers who drove it?
• Can you find their actual words?
• Is there a plan to close the loop with them when it's done?

Yes to all three on at least four of five, and you're customer-led. If not, the book frames it as a position on a spectrum, a diagnosis rather than a verdict.

Now pair that with a Cagan-style question: does your team get problems to solve, or features to deliver? Your two answers point to your bottleneck:

Which to read first

If you're a product leader building a product organization from scratch, Inspired remains essential. Nothing explains the roles and the discovery mindset as clearly. If you're a founder, executive, or a PM stuck inside a company where customer truth gets lost between departments, start with the customer-led argument. Here's the reading order I'd suggest for most teams in 2026:

1. Customer-Led Development by Spencer Shulem (2026). The company-wide system for tracing every decision to named customers, written for an era when AI can build anything.
   Disclosure: I wrote this one.
2. Inspired by Marty Cagan (2008; 2nd ed. 2017). The foundational text on empowered product teams, product discovery and the four big risks.
3. Empowered by Marty Cagan and Chris Jones (2020). The leadership side of Inspired: how managers coach teams and hand out problems instead of features.
4. Continuous Discovery Habits by Teresa Torres (2021). A practical, weekly cadence for customer interviews and mapping opportunities.
5. The Mom Test by Rob Fitzpatrick (2013). A short, sharp guide to asking customers questions that produce truth instead of compliments.

FAQ

What is Inspired by Marty Cagan about?

Inspired argues that great products come from empowered, cross-functional product teams that are given problems to solve rather than features to build, and that use rapid product discovery to test ideas against value, usability, feasibility and viability risks before committing to build.

Is Inspired still relevant in 2026?

Yes. Its case against feature factories and its emphasis on value risk have aged well. What's changed is the cost of building: with AI, feasibility matters less and value matters more, which raises the stakes on knowing exactly whose problem you're solving.

Is customer-led just building whatever customers request?

No. Customer-led means decisions trace to specific, named customers and their real words, and that success is measured by whether those customers succeed. You still decide the solution. The Intuit QuickBooks story shows attention to specific customers revealing opportunities nobody explicitly asked for.

Can you use both approaches together?

Easily. Use attribution to decide which problems deserve a team's time, and use Cagan's discovery practices to find solutions that work. Names pick the problem; experiments validate the answer.

Which book is better for a small team or startup?

Small teams rarely have a full product trio or dedicated product leadership, so Inspired's staffing model can feel out of reach. Customer attribution costs nothing but discipline, which makes the customer-led approach easier to start on day one. Read Inspired when you're ready to build out a product org.

If you want the full system behind naming the customers behind every decision, from the CLO Constitution to closing loops at scale, it's all in Customer-Led Development.

And if comparisons like this, ideas small enough to carry into your next roadmap meeting, are useful, subscribe to the Context Limit newsletter.