Marty Cagan Product Discovery Techniques: AI-Era Guide 2027

You read Inspired years ago and took the four risks to heart. Now an AI tool can build a clickable, sometimes working, prototype in an afternoon, so which of Marty Cagan's product discovery techniques still matter? This guide from the BuildBetter team answers that. It covers the method, a one-week worked example, and the mistakes that cheap prototypes make more likely. You can run it this week with a shared doc and a calendar, with no tools required.

In Marty Cagan's framework at the Silicon Valley Product Group (SVPG), product discovery is the work a product team does to decide what to build before committing engineering time to build it properly. Its job is to reduce four risks before delivery: value, usability, feasibility and business viability.

What Is Marty Cagan's Product Discovery? (Definition and Inspired Summary)

Product discovery, as Cagan defines it, is fast and cheap learning about what to build. Delivery is building it to production quality. Discovery separates good ideas from bad ones, usually with prototypes instead of products. Delivery produces software that is reliable, secure, scalable and maintainable. Cagan argues the two run in parallel, a practice often called dual-track agile or dual-track development.

A five-bullet Inspired summary. Inspired: How to Create Tech Products Customers Love was first published in 2008, and a heavily rewritten 2nd edition came out in late 2017:

• Empowered product teams own problems, not feature lists. Leadership hands the team an outcome to reach, not a roadmap of features to build.
• Each risk has an owner. The product manager is accountable for value and viability, the designer for usability, and the tech lead for feasibility.
• Discovery and delivery run in parallel. The team is always learning about the next thing while shipping the current one.
• Prototypes are the main discovery tool. They are the cheapest way to learn something specific.
• Most ideas will not work. Cagan has written that at least half of ideas won't deliver as hoped, so test many of them cheaply.

Independent data supports that last point. In Trustworthy Online Controlled Experiments (2020), Ron Kohavi and colleagues report that only about one-third of ideas tested at Microsoft improved their target metric. At Bing and Google the reported rates were lower, around 10–20%.

Inspired is the first of four related books. Empowered (2020, with Chris Jones) covers teams and leadership. Loved (2020, Martina Lauchengco with Cagan) covers product marketing. Transformed (2024) covers moving a company to the product operating model.

AI makes prototypes almost free to produce, but it does not make customer evidence or product judgment free. Cagan's four risks still define what discovery must answer.

Why Discovery Breaks When AI Builds the Prototype

Cheap prototypes remove a constraint that used to force teams to think before building. Without it, six failure modes show up again and again:

• Prototype inflation. When a prototype costs an afternoon, teams build five and test none of them properly. Output goes up and learning stays flat.
• Confusing “it works” with “it's valuable.” An AI-built prototype that runs end to end can retire feasibility risk in a demo. It tells you nothing about whether anyone will give up their current workaround.
• Fidelity bias in testing. Polished prototypes get polite approval. Users comment on the surface and keep their real objections to themselves, so value tests return false positives.
• Viability skipped entirely. Pricing, legal, security, sales and support constraints never appear in a prototype. Building faster means teams hit those constraints later, when they cost more to address.
• Evidence detached from the request. The original customer quote, the workaround and the person who asked get lost somewhere between the call, the ticket and the prototype. The team ends up testing its own interpretation instead of the customer's problem.
• The prototype gets promoted. A throwaway prototype quietly becomes production code, and Cagan's line between discovery prototypes and delivery-quality software disappears.

Speed is also harder to judge than it feels. In METR's July 2025 randomized trial, experienced open-source developers using early-2025 AI tools took about 19% longer to finish tasks. Afterward they believed they had been about 20% faster. Measure what the team learned, not how many prototypes it produced.

The Method: Cagan's Four Risks and Discovery Techniques, Updated for AI

The four risks and the technique families come from SVPG and Inspired: framing, ideation, prototyping and testing. Cagan set out the risks in his 2017 SVPG essay “The Four Big Risks.” This section adds what AI changes and what it leaves untouched, plus a manual how-to for each step.

The four risks in the AI era

Step 1: Frame the problem before prototyping

Write a one-page opportunity assessment based on Cagan's four questions. What business objective does this serve? How will you know you've succeeded? What customer problem does it solve? Which type of customer is it for? How-to: paste the original request and the customer's workaround in verbatim, with no paraphrasing. AI note: let AI write the draft, but a human has to state the success measure.

Step 2: Name the riskiest assumption per risk

Write one assumption under each of the four risks. Rank them by a single question: if this is wrong, does the idea die? Test the deadliest one first. That is usually value, not feasibility. CB Insights cited “no market need” as a top reason startups fail, at 42% in its 2014 analysis and about 35% in its 2021 update. Teresa Torres makes a related point: test assumptions, not whole ideas.

Step 3: Ideate with customers, not just with AI

Use two Inspired techniques: customer interviews and the concierge test, where you do the job manually for a customer. Ask about specific past behavior, as Rob Fitzpatrick recommends in The Mom Test, not hypotheticals. AI can widen the set of possible solutions. Only customers can narrow it.

Step 4: Match the prototype type to the risk

• Feasibility prototype for technical unknowns. Engineers write it as throwaway code.
• User prototype for usability and some value testing.
• Live-data prototype when real data changes how people behave.
• Hybrid (Wizard-of-Oz) prototype when you need to fake the backend.

Rule: build the lowest-fidelity prototype that can falsify the assumption, even when higher fidelity costs nothing.

Step 5: Test with real users and demand commitment

For a usability test, give users a task with no guidance and record whether they complete it. For a value test, ask for a commitment instead of an opinion. That could be a calendar slot, data access, a pilot signature or a willingness-to-pay signal. Set pass/fail thresholds before the test starts.

Step 6: Check viability with stakeholders before you commit

Run a 15–30 minute review with each affected function, such as legal, security, finance, sales and support. Use the prototype as the thing they react to, not a slide.

Step 7: Decide and record

Choose one outcome: proceed to delivery, iterate on discovery, narrow the scope, or kill the idea. Write down the evidence behind the decision so the next decision can build on it.

Discovery evidence that counts vs. evidence that doesn't

• Counts: observed task completion, behavior with real data, commitments (time, data, pilots, money), repeat use.
• Doesn't count: “I'd use that,” stakeholder enthusiasm, a smooth demo.

Worked Example: One Discovery Week for a Single Feature

This is an illustrative scenario, not a customer case study. A B2B analytics product is considering scheduled report exports.

Monday: framing. The team pulls 14 support tickets and 6 sales-call mentions asking for automated exports. The common workaround is a CSM downloading CSVs every Friday and emailing them. The riskiest assumption is value: customers will rely on scheduled exports instead of the manual email.

Tuesday: value interviews. The team runs 8 story-based interviews with people who asked for the feature. Five of 8 describe the Friday workaround without being prompted. Two say a Slack summary would be enough, and one doesn't actually need it. The pre-set threshold was 4 of 8, so the idea passes, with a note about the Slack alternative.

Wednesday: usability. An AI-built user prototype is ready in about 3 hours. Six participants each get the same task: “schedule the report your finance team needs.” Four of 6 complete it unaided. Two fail on timezone selection, which is a cheap fix, and the team notes it. Six participants is in line with Nielsen Norman Group's guidance that about 5 users surface roughly 85% of usability problems. That guidance applies to usability, not to demand.

Thursday: feasibility and viability. A one-day engineering spike finds that the data API's rate limit caps exports at hourly frequency. Daily and weekly exports are fine. Security review flags data leaving the platform by email, so the team requires signed, expiring links. Finance confirms the feature fits the existing tier, so pricing doesn't change.

Friday: decision. The team ships a narrow version behind a feature flag to 10 accounts that requested it. It supports daily and weekly schedules only, uses expiring links, and leaves out Slack for now. The success criterion was set in advance: at least 7 of 10 accounts create a schedule within 14 days, and the CSM stops sending the manual Friday email.

Follow-through. If 7 or more accounts adopt, the team rolls out generally and queues the Slack summary as the next iteration. If 3 or fewer adopt, the team interviews the non-adopters before building anything more.

Takeaway: AI cut the prototype from days to hours. It did not produce the 8 interviews, the 6 observed sessions, the rate-limit finding or the security constraint, and those are what decided the scope.

How Cagan's Discovery Compares to Other Discovery Methods

The major discovery methods differ mostly in when they let real usage count as evidence. AI pushes that moment earlier.

Where Ship First Agrees and Disagrees with Cagan

Ship First: How to Build Self-Improving Products is a free 24-chapter book by Spencer Shulem, cofounder and CEO of BuildBetter, who has spent nearly twenty years in product and user research. Its core loop is short. A customer asks for something, you build a small working answer, they try it in their own workflow, and what happens next tells you what to improve.

Where they agree

• Evidence beats opinion. Both books treat customer evidence, not stakeholder preference, as the basis for product decisions.
• Match the test to the question. Ship First's theme of choosing the right experiment (conversations, grounded personas, surveys, prototypes, working releases) parallels Cagan's practice of matching the prototype type to the risk.
• Discovery is continuous. Ship First opens with continuous discovery and shaping the bet.

Where they differ

• Where the line falls. Cagan separates discovery prototypes from delivery. Ship First treats a small working release, used in the customer's own workflow, as a discovery instrument in its own right. That approach is more practical now that AI makes small working answers cheap.
• Provenance of the request. Ship First stresses keeping the real request, the workaround and the person who raised it attached to the work from start to finish.
• After shipping. Ship First's final part, “Make the next release better,” covers the shipping loop, onboarding, nonuse, measurement and adoption. It treats what happens after release as continued discovery.

Where Cagan's caution still applies: a working release does not retire viability or security risk. Run Step 6 before any customer touches real data.

Common Product Discovery Mistakes (and Why They Fail)

Most discovery failures come from testing the easy risk instead of the deadly one. These eight mistakes are the most common:

• Testing feasibility first because it's easiest. AI makes “can we build it?” trivial to answer, so teams answer it and skip value, the risk that actually kills products.
• Asking “would you use this?” Stated intent is not commitment. Ask for time, data, a pilot or money.
• Showing high-fidelity prototypes too early. Polish invites comments on the surface and suppresses objections.
• Setting the pass/fail bar after seeing results. That turns every test into confirmation.
• Letting the PM run discovery alone. Cagan's model assumes PM, design and engineering work together. Without the engineer you lose feasibility insight, and without the designer you lose usability insight.
• Losing the original evidence. When the request, quote and workaround aren't attached to the work, nobody can go back and check why it was built.
• Shipping the prototype as the product. Discovery code skips the reliability, security and maintainability work that delivery requires.
• Treating launch as the end of discovery. If you don't track completion, return use and nonuse, you never learn whether the bet paid off.

When You Need Tooling for Product Discovery

The manual method works well up to roughly 10–15 customer conversations a week and one or two evidence sources. A shared doc per opportunity, pasted quotes and a spreadsheet of tests are enough at that scale.

You've outgrown it when any of these is true:

• You handle more than about 200 tickets, calls and Slack threads a month.
• Evidence lives in 4 or more systems.
• PMs spend more time finding quotes than talking to customers.

At that point, tooling should capture calls, tickets and Slack as linked evidence. It should keep the source attached to every insight, and it should turn evidence into PRDs and tickets without anyone retyping it.

1. BuildBetter: best for keeping customer evidence attached from call to ticket

BuildBetter brings together internal team voice (calls, Slack) and external feedback (support tickets, surveys) through 100+ integrations, including Zoom, Slack, Jira, Zendesk, HubSpot and Intercom. Signals analyzes each piece of feedback for severity and business impact. Documents and Tickets generate PRDs and Linear or Jira issues with the customer source still attached, which addresses failure mode 5 directly. Caveat: teams that need deep research-repository workflows, such as tagging and highlight reels, may find dedicated repository tools more mature.

2. AI prototyping tools

These are useful for usability and feasibility prototypes. Remember that they speed up Step 4 and nothing else.

3. A feature-flag system

You need one for the narrow-release decision in the worked example.

FAQ: Marty Cagan's Product Discovery

What are Marty Cagan's four product risks?

Value asks whether customers will buy it or choose to use it. Usability asks whether users can figure out how to use it. Feasibility asks whether engineering can build it with the available time, skills, technology and data. Business viability asks whether it works for the rest of the business: sales, marketing, finance, legal, compliance and support. The PM owns value and viability, the designer owns usability, and the tech lead owns feasibility.

What is product discovery according to Marty Cagan?

It is the work a product team (PM, designer and engineers) does to decide what to build. The team tests ideas quickly and cheaply against the four risks before investing engineering time in a production-quality build.

Is Inspired still relevant now that AI can build prototypes?

Yes. AI makes prototypes nearly free, but Inspired's main contribution is deciding which risk to test and what evidence settles it, and AI changes neither. It speeds up prototyping. It does not speed up customer recruitment, observation, commitment-based value testing or stakeholder viability review.

What are Cagan's main product discovery techniques?

• Framing: opportunity assessment, customer letter, startup canvas.
• Planning: story maps, customer discovery program.
• Ideation: customer interviews, concierge test, customer misbehavior, hack days.
• Prototyping: feasibility, user, live-data and hybrid/Wizard-of-Oz prototypes.
• Testing: usability, demand, qualitative and quantitative value, feasibility, and business viability.

What's the difference between product discovery and delivery?

Discovery decides what to build by learning fast and cheaply, usually with prototypes. Delivery builds the chosen solution to production quality, meaning reliable, secure, scalable and maintainable. Cagan argues both should run continuously and in parallel.

Can a working release count as product discovery?

Yes, if it is small, scoped and given to customers who asked for it, with success criteria set in advance. Business viability and security risks must still be cleared first.

How long should a discovery cycle take?

For a single feature-level bet, about one week is a practical default. That covers framing, value interviews, usability tests, feasibility and viability checks, and a decision.

Get Ship First Free

Ship First: How to Build Self-Improving Products by Spencer Shulem is free: 24 chapters and 6 illustrations, in PDF and EPUB. It follows the loop from customer request to small working answer to the next, better release, in three parts: “The case for a working answer,” “Build with better evidence” and “Make the next release better.”

• Get Ship First free (email signup)
• For the longer treatment, read Customer-Led Development on Kindle

Sources and Further Reading

• Silicon Valley Product Group, Marty Cagan's essays on discovery and the four big risks: svpg.com
• Shape Up by Ryan Singer, free online: basecamp.com/shapeup
• Lean startup overview: Wikipedia
• Customer development overview: Wikipedia
• Ship First (free): buildbetter.ai/ship-first
• Kohavi, Tang and Xu, Trustworthy Online Controlled Experiments (2020); CB Insights, “The Top Reasons Startups Fail” (2014; 2021); Nielsen Norman Group, “Why You Only Need to Test with 5 Users” (2000); METR, early-2025 AI developer productivity study (July 2025)
• Books referenced: Inspired (2008; 2nd ed. 2017), Empowered (2020), Continuous Discovery Habits (2021), The Lean Startup (2011), The Four Steps to the Epiphany (2005), The Mom Test (2013), The Right It (2019)

Make Churn Optional

Discovery runs on evidence, and evidence goes missing when calls, tickets and Slack threads sit in separate systems. BuildBetter keeps every customer request, quote and workaround attached to the PRDs and tickets your team ships, then tells customers when their request ships.

Make churn optional. Book a demo.