All 29 modules are open from the start — nothing here is
locked, and nothing costs anything. Sign in so your progress, titles and
credentials stay with you, on every device you use.
Free forever, with your Google account. No password, no payment.
Make sure you're building the right thing, before building it right
Delivery answers "are we building it right?" Discovery answers the more dangerous question: "are we building the right thing at all?" This guide covers how to shrink risk cheaply, before you commit a team of engineers to the wrong idea.
Ready?
1
Discovery vs. Delivery
Discovery is the work of deciding what to build and whether it is worth building. Delivery is the work of building it well. The mistake in the story is not that the team did discovery — it is that they treated it as a phase that finishes.
When discovery is a phase, three things go wrong reliably. Learning arrives too late to change anything, because the build has started. Engineers are excluded from the questions they are best placed to answer. And the specification becomes a contract, so new evidence during the build feels like scope creep rather than information.
The alternative is usually called dual-track, which sounds like two teams and is not. It is one team running both activities continuously: a few customer conversations each week alongside the building, so that what you learn on Tuesday can change what you build on Thursday. The tracks are parallel, not sequential, and the same people are in both.
The practical difference is small and the effect is large. A team doing a handful of interviews every week finds the fatal problem in week one rather than week nine — and cancelling something in week one costs almost nothing, which is precisely why teams that discover continuously look braver than teams that do not.
One team handed over a specification and an engineer found mid-build that the integration could not support the core interaction. The information existed the whole time. The process had put a wall between the people who could ask and the people who knew.
Everyday example, measure twice, cut once
A carpenter who measures twice before cutting wastes almost no wood. One who cuts first
and measures after throws away expensive planks. Discovery is the measuring
, cheap, quick, done before you commit. Delivery is the cutting, costly
and hard to undo. Teams that skip straight to cutting (building) look busy and fast, but
they burn months producing beautifully-made things nobody asked for.
Right thing?
Discovery
Reducing uncertainty about what to build. Fast, cheap experiments and research to decide whether an idea is worth building at all.
Thing right?
Delivery
Building the chosen thing well: engineering, quality, shipping. Expensive and slow, which is exactly why discovery should come first.
The whole point of discovery is to fail cheaply on paper, so you don't fail expensively
in code.
Discovery as a phase, and what it cost
A team ran eight weeks of discovery, produced a specification, and handed it to delivery. Halfway through build, an engineer found the integration could not support the core interaction. The information existed the whole time; the process had put a wall between the people who could have asked and the people who knew.
Quick check
A team spends six months beautifully building a feature, ships it, and almost no one uses it. Which job did they skip?
2
The Four Big Risks
Before any idea deserves engineering time, four separate things have to be true. They are usually called the four big risks, and they fail in a predictable order of expense.
Value risk: will anyone want this? Usability risk: can they work out how to use it? Feasibility risk: can we build it with the people, data and systems we actually have? Viability risk: can the rest of the business carry it — can it be sold, supported, priced, and is it legal?
Most teams handle three of these reasonably well, because each has an obvious owner and an established method. Value gets research, usability gets prototypes, feasibility gets a spike.
Viability is the one that gets skipped, and the reason is structural rather than careless. It sits between product, finance, legal, support and sales, which in practice means it sits with nobody — and unowned risks are not evaluated, they are simply assumed.
Its failures also arrive late, after design and often after build, when the cost of being wrong is highest.
The habit worth building is boring and effective: for every significant bet, write one sentence per risk and put a name beside each. The risk with no name next to it is the one that will surprise you.
These fail in order of expense. Value is the cheapest to test and the most often skipped, because it is the only one that can tell you not to build the thing at all.
Everyday example, opening a food truck
Before you buy the truck, four questions decide whether it works.
Value: will people actually want to buy this food? Usability:
can they find you, read the menu, and order without confusion? Feasibility:
can you actually cook each dish fast enough during a lunch rush? Viability:
do the numbers work for you, ingredients cheaper than the price, permits legal,
a good spot to park? A truck can nail three and still fail on the fourth. Every product
feature faces the same four.
Value
Will they want it?
Does it solve a real need people care about enough to use or pay for? The most common killer.
Usability
Can they use it?
Can people actually figure out how to use it without a manual?
Feasibility
Can we build it?
Can engineering deliver it with the tech, time, and skills available?
Viability
Should our business?
Does it work for the business, legal, cost, sales, brand, strategy?
The risk that was never named
Three of the four risks were retired carefully: people wanted it, they could use it, it could be built. Nobody asked whether support could carry it, and the feature generated enough tickets to consume a third of the support team. Viability is the risk with no obvious owner, which is why it is the one that gets skipped.
Quick check
Users love a proposed feature and it's easy to use, but every unit would cost more to deliver than customers will ever pay. Which risk failed?
3
Assumptions & the Riskiest One
Every plan rests on assumptions. Most of them are safe, one or two are not, and the entire outcome usually depends on which ones you check first.
Imagine a plan for a lemonade stand. It assumes children like lemonade, that you can borrow a table, and that anyone walks down that particular street. Two of those are near-certain. The whole plan rests on the third, and it costs one Saturday morning to check before you buy any lemons.
The dangerous assumption has a name — the leap of faith assumption — and it is the one where being wrong invalidates everything downstream. Finding it is a two-question sort. For each assumption ask: how badly are we hurt if this is false? and how confident are we, honestly, on evidence rather than instinct? The ones that are high-impact and low-confidence go first.
Teams naturally test in the wrong order, and the reason is human rather than analytical: we test the assumptions we are most comfortable testing. Confirming that users want a faster import is pleasant, well-understood work, and it takes five weeks. Checking whether the third-party system permits bulk reads takes an afternoon and might end the project, so it drifts to the bottom of the list.
One team tested nineteen assumptions in the order they were written. The one that killed the project was fourteenth, reached in week six. Sorted properly it would have been first. Ending a bad project early is a win, and the order decides whether you get to have it.
Everyday example, crossing a frozen lake
You wouldn't test the ice by the shore, where it's obviously thick and safe. You'd check
the spot in the middle that's most likely to be thin, because that's the one that can
kill you. Your riskiest assumption is that thin patch: the belief that,
if it's wrong, sinks the whole idea. Don't spend your energy confirming the things you're
already fairly sure of. Go straight for the scary unknown, and test it with the smallest,
cheapest step you can.
1
List the assumptions
Everything that must be true for the idea to work. "Users will trust us with their bank login."
2
Find the riskiest
The one that is both most uncertain and most fatal if false. That's your riskiest assumption.
3
Test it cheaply
Design the smallest experiment that could prove it wrong, before building anything real.
Ranking assumptions by what they would cost
A team listed nineteen assumptions and tested them in the order they had been written down. The one that killed the project — that a partner would agree to share data — was fourteenth on the list and reached in week six. Sorted by "how bad if wrong, how sure are we", it would have been first and the project would have ended in week one for a fifth of the cost.
Quick check
You're building a feature that only works if users will connect their bank account. Which assumption should you test first?
4
Continuous & Dual-Track
The phrase dual-track causes more confusion than almost any other term in product, because it sounds like an organisational structure. It is not. It is one team, doing two kinds of work in the same week.
The discovery track asks what is worth building and whether the risks are retired. The delivery track builds and ships. They run continuously and in parallel, and crucially the same people move between them — the engineer who joins two customer calls a month is the reason feasibility problems surface in the conversation rather than in the sprint.
What it is not: a discovery team handing specifications to a delivery team. That is the phase model with new vocabulary, and it recreates every problem the approach exists to solve.
The rhythm in practice is modest. A few customer conversations each week, a prototype tested while the previous feature is being built, a running list of the riskiest assumptions that gets shortened every Friday. Nothing about it is dramatic; what changes is the gap between learning something and being able to act on it, which falls from months to days.
One team that switched cancelled two features mid-build on evidence that, under their previous quarterly cycle, would have arrived after launch. That is the whole argument: the value of discovery is not the research, it is how early the research can still change your mind.
Not a discovery team handing specifications to a delivery team — that is the phase model with new vocabulary. The value of discovery is not the research, it is how early the research can still change your mind.
Everyday example, GPS vs. a printed map
An old printed map is planned once and never updates, if a road closes, you're stuck.
A GPS keeps checking traffic and re-routes you as things change. One-time
discovery is the printed map: you decide everything on day one and hope the part
holds still for a year. Continuous discovery is the GPS: you keep
checking in with real users and adjust course while it's still cheap. The road always
changes, so keep looking at it.
Dual-track, not two phases
In dual-track work, a discovery track and a delivery track run at the
same time. While engineers build what's already validated, the PM, designer, and a tech
lead keep talking to users and testing what's next.
Teresa Torres' rule of thumb: touch base with real users every week. Discovery is a
steady habit, not a gate you pass through once.
Two tracks, one team
A team split discovery and delivery into alternating quarters and spent every delivery quarter building things learned about three months earlier. Running both tracks weekly — a few interviews alongside the build — cut the gap to days, and two features were cancelled mid-build on evidence that would previously have arrived after launch.
Quick check
A team does one month of "discovery," then eleven months of heads-down building with no further user contact. What's the risk?
Drill what you learned
Scenario 1
easy
A stakeholder is certain a new AI assistant feature will be a hit and wants engineering to start a three-month build tomorrow.
What's the discovery-minded response?
Scenario 2
easy
Your proposed feature scores well on value (users want it) and usability (easy to use), but legal flags that it may violate data-privacy rules in your biggest market.
Which risk is unresolved, and what does it mean?
Scenario 3
easy
Your team ran a thorough discovery phase before the project and hasn't spoken to a user in the four months of building since.
What should change?
Scenario 4
easy
Your riskiest assumption is "small businesses will pay $50/month for this." To test it, a teammate proposes fully building the product, then launching to see if anyone subscribes.
What's wrong with that test?
Scenario 5
easy
In a usability test, five of five users can't find the "share" button, even though every one of them said they wanted a share feature.
Which risk did this surface, and which did it complete?
Scenario 6
medium
A feature depends on three assumptions: (1) users want it, (2) it can be built in our current stack, (3) the button should be top-right. You have time to test only one this week.
Which do you test first?
Scenario 7
medium
To gauge demand for a feature that doesn't exist yet, a PM adds a button for it in the live app. Clicking it shows "Coming soon — want this? Leave your email." They measure click-through.
What is this technique, and what's the one caution?
Scenario 8
medium
Engineering says a proposed feature is technically impossible with the current architecture and would need a year-long rebuild. Users, however, love the concept.
Which risk is the blocker, and what's the discovery move?
Scenario 9
medium
A PM runs a survey: "Would you use a feature that saves you time?" 92% say yes. They cite this as proof the feature will succeed.
Why is this weak discovery evidence?
Scenario 10
medium
A designer wants to test a new checkout flow. She proposes building a clickable prototype in a design tool and watching five users attempt to buy, rather than shipping code first.
Is this good discovery practice?
Scenario 11
hard
Leadership treats "discovery" as a two-week phase on the Gantt chart, after which the design is frozen and cannot change no matter what building reveals.
What's the flawed assumption?
Scenario 12
hard
A feature completes value, usability, and feasibility — but shipping it would cannibalize your highest-margin existing product and confuse the sales team's pitch.
Which risk is unresolved?
Scenario 13
hard
You have three feature ideas and limited discovery time. One is a tiny tweak everyone agrees on; one is a bold bet the whole roadmap depends on; one is a nice-to-have.
Where should discovery effort concentrate?
Scenario 14
hard
A test of your riskiest assumption comes back negative: users clearly won't do the key behavior the feature depends on. The team is disappointed and wants to ignore the result and build anyway.
What's the right framing?
Scenario 15
hard
Your CEO says: "We already know what customers want — we've been in this industry 20 years. Discovery is just slowing us down."
What's the strongest, respectful reframe?
Drilled it. Now apply it to a real situation.
Put it to work
From lesson 1
Segway built it perfectly and nobody came
Segway
The Segway launched in 2001 amid extraordinary secrecy and expectation —
Dean Kamen's self-balancing transporter was reported to have been
described by early backers as potentially bigger than the personal
computer. The engineering was genuinely remarkable and delivery was
flawless.
Sales were a fraction of projections. It was reported that the company
had hoped to sell tens of thousands in the first year and sold on the
order of thousands.
Delivery worked. What did not?
What actually happened
The secrecy is the part worth noticing. It made discovery structurally
impossible: you cannot test desirability with customers you are not
allowed to show the product to. The launch was the first real test, by
which point the money was spent.
Discovery and delivery answer different questions and cannot substitute
for each other. Building it beautifully is not evidence that anyone
wanted it.
From lesson 2
Four risks, four different tests
A telehealth startup
The plan: video consultations with a GP within thirty minutes, any hour.
Four risks sit under it, and each needs a different kind of evidence.
Match each risk to the test that actually addresses it, in the order the risks are listed. 1. Will patients use video instead of waiting for an in-person slot? 2. Can we route a patient to an available clinician in under 30 minutes? 3. Can a GP practice's staff work our triage screen mid-shift? 4. Does the unit economics survive at £29 a consultation?
Drag the rows, or use the arrows, then check.
Desirability — offer the service manually to 50 patients and count who takes itRisk 1. Whether people want it is answered by watching people choose it, with real stakes, before anything is built.
Feasibility — a technical spike on the routing and availability modelRisk 2. A question about whether the thing can be built to work at all, answered by engineers rather than by customers.
Usability — sit with reception staff during an actual shift and watch them use a prototypeRisk 3. Whether people can use it is answered by watching them try, in the conditions where they will actually try — a busy morning, not a quiet demo room.
Viability — model the clinician cost per consultation against the priceRisk 4. Whether the business works is arithmetic plus assumptions, and it can be done in a spreadsheet before a line of code.
What actually happened
The viability model killed the £29 price in an afternoon: at realistic
clinician utilisation it lost money on every consultation. The service
launched at £45 with a subscription option, and the desirability test was
re-run at the higher price before anything was built.
Value, usability, feasibility, viability. Each has its own kind of
evidence, and the cheapest one to test is usually the one that kills the
idea.
From lesson 3
Which assumption would sink it
A second-hand furniture marketplace
Six assumptions underneath the plan. The team can test one properly this
month.
The assumptions, as written on the wall
#
Assumption
Confidence
If wrong
1
People will buy used furniture online without seeing it
Medium
Fatal
2
Sellers will photograph items well enough to sell them
Low
Fatal
3
We can arrange collection within 5 days
Medium
Serious
4
The listing form is easy enough to complete
High
Minor
5
People will pay a 12% seller fee
Low
Serious
6
Our brand name is memorable
High
Trivial
Which assumptions are the leap-of-faith candidates?
Select all that apply — there are 2 to find.
What actually happened
They tested seller photography by asking thirty real sellers to list an
item with nothing but the instructions they planned to ship. Eleven
produced unusable photos. The product that launched included a guided
camera flow that had not been on the roadmap at all.
Plot assumptions on fatal-if-wrong against how sure you are. The leap of
faith is high on both, and it is almost never the one that is easiest to
test.
From lesson 4
Discovery that stopped when delivery started
A B2B expense tool
The team ran good discovery for six weeks, chose a direction, and moved
into build. Four months later the feature shipped and adoption was 8%.
Nobody had spoken to a customer since week six.
Work out what continuous discovery would have changed.
Step 1 of 3
What is the structural problem with discovery as a phase that ends?
So the fix is not more discovery up front. It is discovery that never stops.
Step 2 of 3
What does "continuous" actually require in practice?
Dual-track means both, continuously — not discovery, then delivery, then discovery again.
Step 3 of 3
The team adopts a weekly interview. Six weeks in, they learn approvers — not submitters — decide whether the tool gets used. What should happen?
They rebuilt the approval flow before launch, which was two weeks of work rather than the two quarters it would have been afterwards.
What actually happened
Relaunched with the approver flow, adoption reached 54%. The team kept
the weekly slot; the most-cited reason it survived was that it was in the
calendar as a recurring event nobody had to defend each week.
Discovery and delivery run together, not in sequence. A finding that
arrives after the build is a lesson; one that arrives during it is a
saved quarter.