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.
Both books tell you to talk to customers every week. Both are allergic to building on opinion. But only one of them asks you a question most teams can't answer: who, by name, is the last thing you shipped for?
Teresa Torres's Continuous Discovery Habits (2021) and my book Customer-Led Development (2026) get compared a lot, and they should be. They overlap on the core belief. They differ on scope, on the unit of work, and on what happens after the feature ships. That difference matters far more now that AI can build almost anything you can describe.
Here's an honest head-to-head. I wrote one of these books, so weigh my bias accordingly. I'll try to be fair to the other one, because it earned its place on every product team's shelf.
The short answer
- Read Continuous Discovery Habits if you're a product trio that doesn't yet talk to customers weekly and needs a repeatable discovery cadence.
- Read Customer-Led Development if your team already talks to customers but your company still makes decisions that can't be traced to anyone in particular, and your AI-accelerated team is shipping faster than it can decide.
- Read both if you lead product. One is a team habit. The other is a company operating system. They stack.
Continuous Discovery Habits, in one paragraph
Torres's book is a practical guide for the people who decide what a product team builds. Her definition of continuous discovery is roughly this: the team building the product has at least weekly contact with customers, running small research activities in service of a desired outcome. (Paraphrased.) The book is organized around the product trio (a product manager, a designer, and an engineer making discovery decisions together), an outcome the trio is accountable for, and the opportunity solution tree, a visual map that connects that outcome to customer opportunities (needs, pain points, desires), then to candidate solutions, then to the assumption tests that de-risk them. Along the way she teaches story-based interviewing, interview snapshots, automating customer recruiting, and comparing multiple solutions instead of falling in love with one. It's a discovery cadence, and it's excellent.
Customer-Led Development, in one paragraph
Customer-Led Development starts from a blunter question: can you name the specific customers behind your last strategic decision? Not a segment, not a persona, not "our ICP." Names. The book argues that most companies are customer-influenced (they run surveys, track NPS, and "consider" feedback) rather than customer-led (every decision traces to named customers, and those customers hear back when it ships). It 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). The unit of work isn't an opportunity on a tree. It's a traced promise: a decision attached to real customers, real quotes, and a scheduled moment where you close the loop with them.
Side by side
| Continuous Discovery Habits (Torres, 2021) | Customer-Led Development (Shulem, 2026) | |
|---|---|---|
| Scope | One product team's discovery practice | The whole company's decision system: product, sales, support, marketing, leadership |
| Primary reader | Product managers, designers, engineers in a product trio | Founders, product leaders, and anyone who sets priorities across departments |
| Core practice | Weekly customer touchpoints feeding an opportunity solution tree | Attributing every decision to named customers and closing the loop when it ships |
| Unit of work | An opportunity, and the assumptions behind a solution | A decision traced to specific customers, with a promise to follow up |
| Central artifact | The opportunity solution tree | A single shared source of customer truth (the "unified brain") with attribution on every item |
| What it measures | Progress toward a product outcome the team owns | Customer success: did the named customers use it, renew, expand? Plus feedback-to-decision time |
| Failure it fixes | Teams building on opinion with no regular customer contact | Companies that hear customers but decide without them, then never tell them what happened |
Where they agree
More than you'd think from the title of this post.
- Talk to customers continuously, not in projects. Both books reject the big upfront research phase followed by a year of building in the dark.
- The people deciding should hear customers directly. Torres puts the trio in the interview. Customer-Led Development calls this "customer voice is unfiltered": no department gets to translate.
- Outcomes beat output. Shipping isn't success. Torres anchors on product outcomes. My book anchors on customer success: did they use it, did it solve the problem, did they renew.
- Ask about real past behavior, not hypothetical wishes. This is The Mom Test territory, and both books build on it.
If your team does none of this today, the disagreements below are academic. Start talking to customers. Either book will get you there.
Where they differ
1. A team habit vs. a company operating system
Continuous Discovery Habits is deliberately scoped to the product trio. That's a strength: a trio can adopt it next Monday without asking permission.
It's also the ceiling. Picture the trio running a beautiful discovery practice while sales promises a feature to a big prospect, support logs a recurring complaint the trio never sees, and leadership sets the quarterly roadmap in an offsite. The trio's tree is accurate. The company's decisions aren't using it.
Customer-Led Development treats that as the actual problem. It describes the old flow as a telephone game: sales hears the customer and passes along its interpretation, product reinterprets, engineering reinterprets, marketing repositions, and the customer gets "something." Each handoff adds error. The fix isn't better meetings. It's removing the layers of interpretation, so a support rep's observation reaches the PM who can act on it without climbing through three levels of management. The book calls this truth flows horizontally.
The gap between hearing customers and deciding with them is not hypothetical. In a McKinsey survey of more than 500 senior executives, 63% named customer feedback as a top source of growth ideas, but only 15% said they consistently use customer input in their decisions. That gap is a company-level failure. A team-level habit can't close it alone.
2. Opportunity solution tree vs. named-customer traceability
The opportunity solution tree is a synthesis tool. You interview many customers, you abstract their stories into opportunities, and you organize those opportunities in a tree. Abstraction is the point: it lets you see patterns across people.
Customer-Led Development pushes in the opposite direction on one specific thing: the names never fall off. Its second principle is that decisions trace to customer names. Not "mid-market finance teams need X" but "Acme Corp, TechCo, and 47 other customers need X, including three of our top ten accounts."
Why insist on names when patterns are what you're after? Because names do three things abstractions can't:
- They make bad decisions hard to make. If you can't name the customers, you can't make the decision. That's the forcing function against building on intuition dressed up as insight.
- They settle arguments. The book's idea of a unified brain isn't that everyone agrees. It's that everyone disagrees about the same facts, which you can resolve with evidence instead of politics.
- They create someone to call when it ships. An opportunity can't be notified. A person can.
These aren't mutually exclusive. You can keep a tree and tag every opportunity with the customers who voiced it. But the default in most teams is that synthesis erases the names, and by roadmap time nobody can say who asked.
Rule of thumb: If an item on your roadmap can't be read aloud with three customer names attached, it isn't ready to build.
3. Learning loops vs. promise loops
Discovery, as Torres teaches it, is a learning loop: interview, synthesize, test assumptions, decide, repeat. The loop closes inside the team when you learn something.
Customer-Led Development adds a second loop that closes outside the team, with the customer. When a customer tells you about a problem, you've implicitly made a promise: that their input went somewhere. Promise tracking means knowing, for every shipped feature, which customers asked for it and who is telling them. In the book's version of a launch meeting, the first question after "we shipped it" is "who's closing the loop?" and the answer is specific: calls with two accounts this week, a personalized video for the one that prefers async.
This sounds like customer success's job. It isn't, or rather, it can't only be. When the people who decided are also the people who follow up, they see whether their decision actually worked for the humans it was meant for. That's validation you can't get from a dashboard.
4. What each one counts
Torres's trio is measured on a product outcome, ideally one the team can directly influence. That's a sharp, healthy constraint.
Customer-Led Development adds a speed metric most teams never track: feedback-to-decision time, which it argues should be measured in hours, not months. Not every piece of feedback needs action, but the ones that do shouldn't wait three quarters for a planning cycle. The book also offers a blunt diagnostic, covered below.
Why AI changes which book you need first
When Torres published in 2021, building was expensive. A big part of discovery's value was avoiding the cost of building the wrong thing: test the assumption with a sketch before you spend a quarter on code.
That calculus has shifted. When a small team with AI tools can produce a working prototype in an afternoon, the cost of building drops toward zero, and two things happen.
First, the bottleneck moves from building to deciding. If you can build ten things this month, the scarce resource is no longer engineering capacity. It's the judgment about which ten, and the evidence behind it. A team that decides badly now ships its bad decisions faster.
Second, waste scales with velocity. Pendo's 2019 Feature Adoption Report is the source behind the widely cited finding that roughly 80% of features are rarely or never used, which Customer-Led Development translates to up to $8.4 million a year down the drain for a $50M company. That was before AI made features cheap to produce. Multiply output and you multiply the unused pile, plus the maintenance, support, and complexity it drags along.
Discovery habits still matter in this world. Good interviews are more valuable than ever, because they're the input to every decision. But assumption testing partly collapses into "just build a version and see," and the harder questions become organizational: Who gets to decide? On whose evidence? And who tells the customer?
Those are the questions Customer-Led Development was written to answer. That's why, for teams already shipping with AI, I'd argue it's the more urgent read. For teams that don't yet talk to customers at all, Torres is still the better first step.
An old story that explains the new problem
Intuit is the cleanest example of both halves. In its early days, as Inc. reported, employees waited in computer stores until someone bought Quicken, then asked to follow the buyer home and watch them install it. Co-founder Scott Cook treated every stumble as Intuit's fault. That's continuous discovery before it had a name.
But Intuit's own surveys later showed many Quicken customers using the personal finance program at work to keep their company's books. Cook said Intuit ignored that for four years. When it finally built QuickBooks for those customers, the business became, in Cook's words in 2014, 11 times larger than Quicken.
The listening was there. The data was there. What was missing was a system that forced the signal into a decision. That's the gap between discovery and being customer-led, and AI makes it more expensive, not less.
Which to read first, by role and situation
| You are... | Read first | Why |
|---|---|---|
| A PM, designer, or engineer with little customer contact | Continuous Discovery Habits | You need the weekly habit before anything else. Torres makes it concrete and doable. |
| A product trio that already interviews weekly | Customer-Led Development | Your discovery is fine. Your decisions probably still lose the names on the way to the roadmap. |
| A founder or CEO | Customer-Led Development | Your problem is cross-department: sales, support, and product each hold a different version of the customer. |
| A head of product or VP | Both, CLD first if you ship with AI | You own the system the trios operate inside. Torres for team practice, CLD for the operating system around it. |
| A team shipping fast with AI and seeing low adoption | Customer-Led Development | Your bottleneck is deciding and following up, not building. |
| An early-stage founder pre-product-market fit | The Mom Test, then Continuous Discovery Habits | Learn to ask good questions before you build systems around the answers. |
A product discovery bookshelf
If you're building a reading list rather than picking one, here's how I'd stack them for a team in 2026:
- Customer-Led Development by Spencer Shulem (2026). The company operating system: decisions traced to named customers, loops closed when things ship, and three systems (organization, development, growth) for when AI can build anything.
Disclosure: I wrote this one. - Continuous Discovery Habits by Teresa Torres (2021). The definitive guide to a weekly discovery cadence for product trios, built around the opportunity solution tree and assumption testing.
- The Mom Test by Rob Fitzpatrick (2013). A short, practical book on asking customers questions that even people who want to be nice to you can't lie about. The interviewing foundation under both of the above.
- Inspired by Marty Cagan (2008; second edition 2017). The broader case for empowered product teams and the discovery-versus-delivery split that much of modern product practice grew from.
The five-decision test
Not sure which book your team needs? Customer-Led Development offers a diagnostic you can run in fifteen minutes.
Pick your last five major decisions: roadmap items, feature priorities, strategic shifts. For each one, ask:
- Can you name the specific customers who drove it?
- Can you find the exact quotes or feedback behind it?
- Is there a plan to close the loop with those customers when it's done?
Yes to all three on at least four of the five, and you're customer-led. If you're failing on the first question because nobody talks to customers, start with Torres. If you're failing on the second and third because the names evaporated somewhere between the interview and the roadmap, that's the problem Customer-Led Development is built for.
Either way, the result is a diagnosis, not a judgment. Every company sits somewhere between customer-influenced and customer-led. The only question is which direction you're moving.
FAQ
Is Customer-Led Development a Continuous Discovery Habits alternative?
Partly, but complement is the better word. Torres teaches a product trio how to discover continuously. Customer-Led Development covers how the whole company decides, attributes, and follows up. A team can run Torres's practice inside a customer-led organization without conflict.
What is Teresa Torres's book about in one sentence?
Continuous Discovery Habits (2021) teaches product trios to talk with customers at least weekly and use an opportunity solution tree to connect a desired outcome to customer opportunities, solutions, and assumption tests.
Do I still need an opportunity solution tree if I'm customer-led?
It's still a useful synthesis tool. The customer-led adjustment is to keep customer names attached to each opportunity so you can trace the eventual decision back to real people and close the loop with them when it ships.
Why does AI make the company-wide system more urgent?
When building is cheap, deciding becomes the bottleneck. Teams can ship more, which means bad decisions ship faster and unused features pile up faster. Traceability and loop-closing are the brakes on that.
What are the best product discovery books for a new PM?
Start with The Mom Test for interviewing, then Continuous Discovery Habits for the weekly cadence, then Customer-Led Development once you're ready to connect what you learn to how your company actually decides.
Can a small startup be customer-led without heavy process?
Yes. At small scale it's mostly discipline: write customer names next to every roadmap item, keep the quotes, and personally tell those customers when their thing ships. The systems get heavier only as the company grows.
If you want the full system for tracing every decision to a named customer and closing the loop when it ships, it's all in Customer-Led Development.
And if you'd like more essays on deciding well when building is cheap, subscribe to the Context Limit newsletter.