Assumptions & Risk: What to Test First

Every solution you build rides on a stack of assumptions. Test the one that kills it first.

The rest of this page is just how you find that one.

After you've sifted what you heard in discovery into a few conclusions, that's synthesis, there's a step I'll move past quickly but you shouldn't skip in practice. You take those conclusions and you generate ideas. You brainstorm options, sketch a few solutions, and pick one to chase. Ideation is its own craft, and I won't go deep on it here. Just know it sits between synthesis and what we're about to do, because you don't leap straight from a conclusion to a solution. You come out of ideation holding one, a solution you think will work. And the second you have a solution, you have a problem you can't see. That solution is a tower of things you're assuming are true. Some of them are safe. One or two of them, if they're wrong, take the whole thing down.

The mistake almost every team makes is testing the wrong one. They build the part they know how to build, ship it, and feel productive, while the assumption that actually decides whether the idea lives or dies sits there, untested, until launch day tells them the truth for the price of a launch.

So before you build anything, you do three moves. Write the idea down as a bet. List everything that bet assumes. Then find the one assumption that's both most important and least proven, and go test that one, cheap, before you touch a line of code.

Let's go through it.

"We just need to build the MVP"

You're thinking it. We just need to build the MVP, the minimum viable product, the smallest version of the thing you'd actually ship.

Maybe. Which assumption is it testing? And is that the one that kills the idea if it's wrong?

If you can't answer that fast, you're not running an experiment. You're building on hope and calling it lean.

An MVP feels like progress because it's building, and building is the part that gives you a dopamine hit. Testing an assumption doesn't. It feels like delay. So teams skip straight to the build, pick whatever's easiest to ship, and tell themselves they'll "learn from it in the market." What they learn, six months and a real budget later, is the one thing a two-day test would have told them on day one.

The fix isn't more discipline or more meetings. It's a sequence. Surface the assumptions, find the riskiest, test that one first and cheapest. Do that and the MVP question answers itself, because you'll know exactly what it has to prove.

Step 1: State your idea as a bet

Stop calling it a plan. Call it a bet, out loud, and write it in one sentence:

"We believe that [this group of customers] will [do this specific thing] because [this reason]."

That structure comes from David Bland and Alex Osterwalder's Testing Business Ideas, and it does something a feature list never does. It forces the claim into the open where you can argue with it. "We believe that late-paying B2B customers will click a one-tap pay link in a reminder email, because the reason they pay late is friction, not refusal." Now there's something to test. You can be wrong about that sentence in a way you can't be wrong about "build the invoicing feature."

The word doing the work is believe. You don't know. You believe. Bland and Osterwalder are building on a longer thread here. Eric Ries, in The Lean Startup, named the riskiest of these beliefs the "leap-of-faith assumption," the thing your whole idea jumps off of, that you have no evidence for yet. Writing the bet as a belief is how you stop confusing the two. A plan hides its assumptions inside confident language. A bet wears them on the outside.

So write the sentence. If you can't write it, you don't have an idea yet. You have a feature you like.

Step 2: Sweep all five categories of risk

Now break the bet down into the assumptions holding it up.

The danger here is that you'll list the assumptions you're already worried about and stop. Your worries cluster. An engineer lists feasibility risks. A founder lists desirability risks. Each of you misses an entire class of risk that the other one would've caught, and the one you skip is exactly the one that bites.

So don't free-list. Sweep. Teresa Torres, in Continuous Discovery Habits, lays out five categories of assumption in her chapter on hidden assumptions, and the point of the five is coverage. You walk every category and ask what your bet is assuming inside it, whether or not you're worried about it. Five questions, every idea, every time:

1. Desirability. Does anyone actually want this? If no one wants it, nothing else matters.
2. Viability. Should we build this as a business? Can we make money or sustain it, or does it cost more than it returns?
3. Feasibility. Can we actually build it? With the technology and the people we have, in the time we have.
4. Usability. Can they figure out how to use it? A thing people want and you can build still dies if they can't work out how to operate it.
5. Ethical. Could this cause harm? Should it exist, knowing what it might do to people a few years out.

If you read the design-thinking page, four of these will look familiar. There I run every idea through four lenses, Desirability, Feasibility, Viability, Ethicality, before I commit to it. Same four lenses, one level down, asked about each assumption instead of the whole idea. Torres just pulls Usability out as its own line so it can't hide inside Desirability, and she keeps the ethical lens.

Where these come from, because people muddy it. Marty Cagan and his team at SVPG teach four big product risks, and Torres's first four map onto those almost cleanly. The fifth, Ethical, is not Cagan's. It's the lens Torres includes and the one I added to my own four because the cost of skipping it has gotten too high to leave out. Credit where it's earned. The four risks are Cagan's, the five-category sweep is Torres's, and the ethical lens is on you to not skip, because no framework will force it.

Run the sweep and you'll have a list. Eight assumptions, twelve, however many fall out. Most of them are fine. The job now is to find the one that isn't.

Step 3: Map them on importance versus evidence

You can't test all twelve. You don't need to. You're hunting for the two or three that are dangerous, and then for the single worst one inside that handful. The way you find them is a simple picture.

Draw a 2x2. This is Assumptions Mapping, straight out of Bland and Osterwalder.

• The horizontal axis is evidence. Left is "we have lots of evidence this is true." Right is "we have almost none."
• The vertical axis is importance. Bottom is "if this is wrong, no big deal, we can work around it." Top is "if this is wrong, the whole idea is dead."

Now take each assumption from your sweep and place it on the grid. You're not measuring anything. You don't need a score. You need each assumption sitting where it lands relative to the others, this one's more proven than that one, this one's more dangerous than that one. Relative placement is enough to make the next move obvious.

Watch what the four corners tell you.

Bottom-left is the assumption you've basically already proven and that wouldn't matter much anyway. Ignore it. Top-left is important, but you already have strong evidence for it. Trust it and move on. Bottom-right you have no evidence for, but it also doesn't matter much, so it can wait.

Then there's the top-right.

Step 4: Test the top-right corner first, inward

The top-right corner is the assumption that's both most important and least proven. Most important. If it's false, the idea is dead, no workaround. Least proven. You have almost no evidence either way.

That's your leap-of-faith assumption, Ries's term from Step 1, and it sits dead center on purpose. It's the one that decides everything and the one you currently know the least about.

So that's where you start. Test the top-right corner first, then work inward toward the safer ones. Not the assumption that's easiest to test. Not the one you already half-believe. The riskiest one, the one in the corner, the one that, if it's wrong, means none of the rest matters.

And you test it with the cheapest, fastest experiment that could prove you wrong. Before you build. This has a name product teams actually use. The RAT, the Riskiest Assumption Test, not the MVP. An MVP, even a real one, is a fair amount of work and it tends to wrap several assumptions together so you can't tell which one moved. A RAT does the opposite. It isolates the single most dangerous belief and aims the smallest possible test straight at it.

What does the smallest possible test look like? That depends on how early you are. The earlier you are, the lower-fidelity your test should be. If your riskiest assumption is desirability, that nobody's even confirmed people want this, you don't need a working product to find out. You need a conversation, a fake door (a button or page for a feature that doesn't exist yet, so you can count who clicks), a landing page, a video. Back in Part 04, you saw the cheap-prototype kill. A rough prototype stood up on a fifteen-dollar-a-month server proved, in under a week, that a hundred-thousand-dollar build wasn't worth making, before anyone spent the real money. Spending three months building to test a desirability assumption is using a wrecking ball to hang a picture. You're testing the right thing with a tool that costs a hundred times too much.

The fidelity matches the question. Early and unproven gets a scrappy, throwaway test. The closer you get to "we know people want this, can they actually use it," the more your test has to look and feel like the real thing, because now you're testing something a sketch can't answer. Low fidelity early, higher fidelity as the dangerous assumptions fall.

Why this beats just building

You're thinking it. This is a lot of process to avoid writing some code.

It's three sketches on a whiteboard and an afternoon. Two days and almost nothing to learn your idea is wrong, or two quarters, a real budget, and a team's worth of trust to learn the same thing. That's the trade.

Run the sweep on something your team is building right now. Write it as a bet. List what the bet assumes, across all five categories so you don't miss a class. Map the assumptions on importance versus evidence. Find the one in the top-right corner, and ask one question. Have we tested this, or have we just been hoping it's true?

If you haven't tested it, you don't have a plan. You have a tower of assumptions with the load-bearing one untested. Pull that one out first, with the cheapest test that could prove you wrong, and find out cheap whether the whole thing stands.

That smallest test has a discipline of its own. The actual menu of fake doors, landing pages, and concierge tests lives in Lean Experiments, over in the Toolbox (Part 06). And why it's a thing you run to learn, not a tiny product you ship, is the next page. What is an MVE? The MVE, the Minimum Viable Experience, is the smallest thing you put in front of a real customer to learn whether they want the solution, not a shrunken version of the product everyone confuses it with.