ValidationAugust 1, 2026By Maarten Follaets

The riskiest assumption test: what to validate first

Cover reading Test the one thing that can kill the idea, with a callout that testing the wrong assumption first is a top way startups waste runway, sourced to Ash Maurya's Running Lean, and the Foxy mascot in the corner

Quick answer: The riskiest assumption test (RAT) means finding the single belief your idea rests on, the one that sinks the whole thing if it turns out false, and testing that first with the cheapest experiment that could prove you wrong. You are not trying to test everything. You rank your assumptions by two things: how likely each one is to be wrong, and how much it costs you if it is. The assumption that scores high on both is your riskiest, and it goes to the front of the queue. Test it before you build, hire, or spend. If it holds, you have earned the right to look at the next one. If it breaks, you just saved yourself months.

Every idea is a stack of assumptions wearing a trench coat.

You just cannot see them yet, because right now they all feel like facts.

Every idea has one load-bearing assumption

Pull any startup idea apart and you find a list of things that all have to be true at once. The problem is real. Enough people have it. They have it badly enough to act. They will pay to solve it. You can reach them for less than they are worth. You can actually build the thing.

Knock out any one of those and the idea falls over. But they are not equally likely to be wrong, and they are not equally expensive to get wrong. That is the whole game.

Most founders test the assumption that is easiest to check, or the one they are most confident about, because it feels good to tick a box. That is backwards. The one you should test first is the one that is both most likely to be false and most fatal if it is.

How to find your riskiest assumption (rank, do not guess)

Start by writing every assumption down in plain language. Not "product-market fit". Say the actual sentence: "small law firms will pay 200 a month to automate intake." Now you have something you can be wrong about.

Then score each one on two axes. How likely is this to be false, honestly? And if it is false, how much does it cost me: a week, or the whole company? Ash Maurya, who wrote Running Lean, puts it simply: you quantify risk by combining the probability of an outcome with the loss if you are wrong, and misjudging which assumption is riskiest is one of the top contributors to waste in a startup. Get the ranking wrong and you pour weeks into testing something that was never going to sink you.

The assumption that sits top-right, likely to be wrong and expensive if it is, is your riskiest. That is the one you test first. Everything else waits.

This is also why validation stops feeling like an ocean. You are not testing forty things. You are testing one, then re-ranking. If you have ever felt buried by it, that is the same idea behind where to start with startup validation: refuse to move until the riskiest thing holds.

Design a test that can actually say no

Here is where most tests quietly fail. They are built to pass.

A good riskiest-assumption test has one property above all: it can come back no. If every possible result would leave you saying "great, the idea is fine", you have not built a test, you have built a comfort blanket.

So pick a signal that costs the other person something. Not "would you use this", which returns a free yes. A deposit, a pre-order, a signed letter of intent, an hour of their calendar, a switch away from what they use today. Something with a price. And keep it cheap on your side: a landing page, a mockup, ten real conversations, a fake door. The cheapest tests carry the most weight, which is the point of testing a startup idea cheaply.

Write the pass and fail lines before you run it. "If fewer than three of ten put down a deposit, the assumption is dead." Decide that in advance, while you can still be honest.

What this looks like in practice

Picture a founder with a scheduling tool for physiotherapy clinics.

The tempting first move is to build the calendar, because that is the fun part and they know they can. But the calendar is not the risk. The risk is the sentence "clinic owners are unhappy enough with their current booking system to switch." If that is false, the prettiest calendar in the world dies on the vine.

So the first test is not code. It is ten calls to clinic owners about what they use now, what it costs them, and whether they will put a small deposit on a switch. Cheap to run, and it can absolutely come back no. If it does, that is a great outcome bought for a week of calls instead of six months of building.

That is the trade the riskiest assumption test makes for you. It moves the failure to the front, where it is cheap.

Where Foxy fits

The hard part is honesty. You are the worst-placed person to rank your own assumptions, because you need the scariest one to be fine. That is the gap we are building Foxy to fill. It is an AI co-founder whose job is not to cheer, but to read your assumptions and your customer conversations and point at the one you are quietly stepping around. If you want your riskiest assumption named before you commit the months, start here.

So before you open the editor, one question. Of everything that has to be true for your idea to work, which single thing would hurt the most if it were false, and have you tested it yet?

Frequently asked questions

What is the riskiest assumption test?

It is a way to decide what to validate first. You list the beliefs your idea depends on, rank them by how likely each is to be wrong and how much it costs you if it is, and test the highest-scoring one first with the cheapest experiment that could prove you wrong. It is often shortened to RAT.

How do I find my riskiest assumption?

Write down everything that has to be true for the idea to work: that the problem is real, that enough people have it, that they will pay, that you can reach them. Then score each one on probability of being wrong and cost of being wrong. The assumption that scores high on both is your riskiest.

Why test the riskiest assumption first instead of building?

Because if that assumption is false, nothing else you build matters. Ash Maurya notes that misjudging which assumption is riskiest is one of the top ways startups waste their runway. Testing it first means you fail cheaply and early, or you earn the right to keep going.

What makes a good riskiest-assumption test?

One that can genuinely return a no. If every possible outcome would leave you saying the idea is fine, you have not designed a test, you have designed reassurance. Pick a signal that costs the customer something, like a payment, a deposit, or real time, not a polite yes.

Is the riskiest assumption always that people will pay?

Often, but not always. For a marketplace it might be whether you can get supply. For a deep-tech idea it might be whether the thing works at all. The point of the test is to find your specific load-bearing assumption rather than assuming it is the same as everyone else's.

How is this different from a full MVP?

An MVP tests a whole solution. The riskiest assumption test isolates one belief and finds the smallest experiment that speaks to it. You usually reach for it before an MVP, so you do not build a product around an assumption that was never true.