The most expensive way to learn that nobody wants your product is to build it, ship it, and watch the silence. Discovery, validation and de-risking are three names for the cheaper alternative: finding out what's likely to be wrong before you spend a quarter building it.

The quick version

  • Discovery is the work of deciding what to build; delivery is the work of building it well. They answer different questions, and skipping the first is why teams build polished things no one wants.
  • Marty Cagan frames the job as clearing four risks before you commit: will people value it, can they use it, can we build it, and does it work for the business.
  • De-risking means finding your single riskiest assumption, the belief that, if wrong, sinks the whole idea, and running the cheapest test that could disprove it.
  • The point isn't more research. It's making fewer expensive bets on faith. A failed five-day test is a win; a failed five-month build is not.

The idea in depth

The cleanest way to think about this comes from Marty Cagan, the former eBay and Netscape product executive whose book Inspired shaped how a generation of teams describe their work. Cagan splits product work into two activities that are often blurred together. Delivery is building and shipping reliable software. Discovery is the separate, earlier job of working out what is worth building in the first place. His sharpest line is that discovery exists to tackle four big risks before a team commits its delivery capacity: value risk (will customers buy it or choose to use it), usability risk (can they figure out how to use it), feasibility risk (can our engineers actually build it with the time, skills and technology we have), and business viability risk (does the solution also work for the rest of the business, sales, legal, finance, brand).

The honest, uncomfortable observation Cagan makes is about where teams instinctively look. People gravitate to the risks they personally know how to attack, usually usability and feasibility, because designers and engineers can do something about those today. Value and viability get quietly outsourced to a senior leader, a compliance review, or a hopeful assumption. Those are precisely the two that most often kill a product. The fix is to invert the instinct: in your next discovery conversation, ask the value and viability questions first and out loud. "What's our evidence anyone wants this?" and "What in our own business would have to be true for this to work?" If those answers are shrugs, you've found where to spend your time, not on the prototype polish that feels productive.

flowchart LR
  IDEA(["An idea worth checking"]) --> V("Value: will they choose it?")
  IDEA --> U("Usability: can they use it?")
  IDEA --> F("Feasibility: can we build it?")
  IDEA --> B("Viability: does it work for us?")
  V --> GO{"All four
cleared?"}
  U --> GO
  F --> GO
  B --> GO
  GO -->|"Yes"| BUILD(["Commit to delivery"])
  GO -->|"No"| TEST(["Test the weakest one first"])
  TEST --> IDEA
Discovery clears four risks before delivery starts; the one with the least evidence goes first. Leaders Loop

From risks to the riskiest assumption

Knowing the four risks tells you what to look at. It doesn't tell you where to start, and you cannot test everything. This is where the lean tradition is useful. In The Lean Startup (2011), Eric Ries reframed building a company as a build–measure–learn loop powered by what he called validated learning: every idea contains a few leap-of-faith assumptions, the beliefs you're betting the whole thing on but have the least evidence for. The job isn't to build the product; it's to get through one full turn of that loop, with the least effort, to learn whether those assumptions hold.

David J. Bland and Alex Osterwalder made that practical in Testing Business Ideas with a technique called assumptions mapping. You list every assumption an idea depends on, then plot each on two axes: how important it is (would the idea collapse if this is wrong?) and how much evidence you already have. The assumptions that are important and unevidenced, top-right, are your riskiest assumptions, and they go first. In practice that means something quite concrete: before your next big build, get the team in a room, write every load-bearing assumption on a sticky note, and force a ranking by importance and evidence. The top-right corner is your test backlog. Everything else can wait.

You don't validate an idea. You try to kill it cheaply, and pay attention to what refuses to die.

The companion idea is the Riskiest Assumption Test: rather than building a "minimum viable product" that's really a small version of the whole thing, build the smallest possible experiment aimed squarely at the one belief most likely to be false. Often that isn't software at all, it's five customer interviews, a fake "buy" button that measures intent, a concierge service you run by hand, or a landing page. The discipline is matching the cheapness of the test to the riskiness of the belief, not to how fun it is to build.

Teresa Torres, in Continuous Discovery Habits, adds the rhythm that keeps this from becoming a one-off phase. Discovery, she argues, shouldn't be a gate you pass through once before delivery; it should be a continuous habit, with the team talking to customers every week. Her opportunity solution tree hangs a clear outcome at the top, branches down into the customer opportunities (needs, pains, desires) that could move it, and only then into candidate solutions and the experiments that test them. Used well, it changes the question a team argues about, away from "is this feature good?" and toward "which customer opportunity are we serving, and is it the one most likely to move our outcome?" The tree keeps a team honest that solutions exist to serve opportunities, not the other way round.

flowchart TD
  O(["Outcome: reduce trial-to-paid drop-off"]) --> OP1("Opportunity: users don't reach the 'aha' moment")
  O --> OP2("Opportunity: pricing feels risky at sign-up")
  OP1 --> S1(["Solution: guided first-run setup"])
  OP1 --> S2(["Solution: sample data on day one"])
  OP2 --> S3(["Solution: 30-day money-back offer"])
  S1 --> E1(["Test: concierge onboarding for 10 users"])
  S3 --> E2(["Test: fake-door 'guarantee' on pricing page"])
An opportunity solution tree: outcome at the top, customer opportunities below, then solutions and the cheap tests that probe them. Leaders Loop

An honest limitation. Discovery can curdle into its own kind of waste. Endless interviews, perpetual "validation," and a fear of ever committing are real failure modes, analysis paralysis dressed up as rigour. Two cautions keep it useful. First, much of this canon is practitioner wisdom, not controlled study: Cagan, Ries, Torres and Bland are experienced operators writing from pattern, and academic reviews of lean-startup practice note the empirical base is still thin. Treat the frameworks as sharp lenses, not laws. Second, discovery reduces risk; it never removes it. A test on ten users is a signal, not proof, and people say one thing in an interview and do another with their wallet. The goal is to be less wrong, sooner and cheaper, not to reach certainty before you act. A team that won't ship until it's certain has simply found a slower way to fail.

A worked example

Picture a B2B software team, call it a scheduling tool for clinics, convinced the way to grow is an AI assistant that auto-fills the weekly roster. The roadmap pencils in a quarter of engineering. (Illustrative scenario and figures throughout; this is a teaching example, not a real product.)

Before writing the assumptions down, the team is about to attack feasibility, "can our model produce a good roster?", because that's the interesting engineering problem. Assumptions mapping reorders the work. On sticky notes: (1) clinic managers actually want the roster automated rather than controlled by hand; (2) they'll trust a machine-made roster enough to publish it; (3) the data we hold is clean enough to schedule from; (4) we can build a good-enough model. Ranked by importance and evidence, the top-right danger isn't the model at all, it's assumption (2), trust. A clinic manager who quietly redoes every AI roster by hand gets zero value, however good the model.

flowchart TD
  A(["Idea: AI auto-fills the clinic roster"]) --> B{"Riskiest assumption?"}
  B -->|"Tempting: can we build the model?"| C("Feasibility, fun, but not fatal")
  B -->|"Actually fatal: will they trust + publish it?"| D(["Value/viability, test this first"])
  D --> E(["Cheap test: hand-make 5 rosters,
offer them as 'AI suggestions'"])
  E --> F{"Do managers publish them
or redo by hand?"}
  F -->|"Publish"| G(["Trust is real, now build the model"])
  F -->|"Redo by hand"| H(["Saved a quarter of engineering"])
The riskiest assumption wasn't the hard engineering, it was whether anyone would trust the output enough to use it. Leaders Loop

So the test costs a week, not a quarter. The team hand-builds five rosters for five real clinics and presents them as "AI-suggested" drafts, a concierge test, no model involved. The measure isn't whether managers like them; it's whether they hit publish or quietly rebuild them by hand. If they publish, trust is real and the expensive model is worth building. If they rebuild, the team has saved a quarter and learned the real job is making managers comfortable, not making rosters. Either way, the riskiest belief got cheap before the build got expensive.

Frequently asked questions

Isn't discovery just a slower way to ship? My team has no time.

Discovery isn't a separate phase that delays delivery, done well it runs alongside it, and it's measured in days, not months. A fake-door test or five customer interviews takes a week. The relevant comparison isn't "discovery versus shipping now"; it's "a week of cheap learning versus a quarter spent building the wrong thing." Teams that feel they have no time for discovery usually have plenty of time for rework.

What's the difference between discovery, validation and de-risking?

They overlap but point at different things. Discovery is the broad activity of figuring out what's worth building. Validation is gathering evidence that a specific assumption holds (or doesn't). De-risking is the strategy of sequencing that work so you attack the most dangerous unknown first. In practice: discovery is the room, validation is the experiments you run in it, de-risking is the order you run them in.

How do I find my riskiest assumption?

List every belief the idea depends on, then ask two questions of each: how important is it (would the idea fail if this is false?) and how much evidence do I already have? The assumption that's important and unevidenced is your riskiest one. The common trap is testing the assumptions you know how to test rather than the ones that actually matter.

What counts as a good validation test?

One that could genuinely prove you wrong, is cheaper than building the real thing, and measures behaviour over opinion. A landing page that tracks sign-ups, a concierge service you run manually, or a fake "buy" button beats asking people "would you use this?", because what people say and what they do diverge. If a test can only confirm your hope, it isn't a test.

Does this only apply to startups?

No. The risks are highest where the unknowns are highest, which includes new bets inside large companies, where the cost of a confident wrong build is often bigger, not smaller. Established teams have more data to draw on for some assumptions, but a genuinely new feature, market or business model carries the same leap-of-faith assumptions a startup faces.

Related in the Toolkit

Discovery doesn't happen in a vacuum: it serves a product strategy that decides which bets are worth de-risking at all, and the assumptions you're chasing are usually rooted in unmet customer needs you haven't yet named.

Where to go next