What Is a Riskiest Assumption Test (RAT)?
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
A riskiest assumption test, or RAT, is the smallest experiment that checks the one belief your idea can't survive being wrong about. You list what has to be true for the idea to work, pick the assumption with the most to lose and the least evidence, and test only that. You don't build a product to do it.
The term is usually credited to Rik Higham, who put it in print in 2016 as a reaction to how loosely "MVP" had come to be used. It's a simple habit, but it changes what an early team spends its weeks on. This guide covers where the idea came from, how to find the riskiest assumption, how to run a test, and where teams go wrong.
Where the RAT comes from
Rik Higham published "The MVP is dead. Long live the RAT." on Hacker Noon on September 27, 2016. His argument is that the minimum viable product has a flaw at its core: it's not a product. In his framing, it's a way of testing whether you've found a problem worth solving, and a way to reduce risk by quickly testing your biggest assumption.
Higham says "MVP" has been used so often it has lost its original meaning. It gets applied to the first release of a rudimentary product, so the "MVP" ends up far more complex than the quick test it was meant to be, and too shoddy to release as a real product. His proposed fix is to stop asking "what's the minimum product?" and ask "what's my riskiest assumption, and how do I test it?"
He also points to a quote from Tom Chi, co-founder of Google X, about maximizing the rate of learning by minimizing the time to try things. A RAT is that idea applied to a single, specific unknown.
The lineage matters because the RAT isn't a rival to the Lean Startup. It's a sharper reading of it. The official Lean Startup site says the method begins with leap-of-faith assumptions that cry out for vigorous testing, then uses a minimum viable product to test them. Higham's point is that the test should come first, and the product only as large as the test demands.
What counts as an assumption
An assumption is something you believe but haven't checked. Every startup idea is a stack of them. Higham suggests working backwards: express the opportunity as a customer problem, then ask what has to be true for it to exist. Take each of those assumptions and ask what sits behind it. Repeat until you reach root assumptions. He compares this to the 5 Whys.
Assumptions come in different kinds. The framework in Testing Business Ideas by David J. Bland and Alexander Osterwalder sorts them into three lenses, summarized in Strategyzer's book summary:
| Risk type | Core question | Example assumption (hypothetical) |
|---|---|---|
| Desirability | Do customers want this, enough to change behavior? | "Dispatchers at small freight brokers will stop using spreadsheets for load tracking." |
| Feasibility | Can we build, deliver, and operate it? | "We can match invoices to purchase orders automatically with at least 95% accuracy." |
| Viability | Can it make money and keep making it? | "Customers will pay enough that our cost to acquire and serve one stays well below what they pay." |
The Strategyzer summary describes desirability as whether customers will change their current behavior, feasibility as whether you have the skills and resources to deliver, and viability as whether customers can afford it and pricing supports scaling. The examples in the table are invented for illustration.
Most early teams over-test feasibility because it's the risk engineers like to chew on. But a product that works perfectly and that nobody wants is still a failure. At the idea stage, desirability is usually where the biggest unknowns sit.
How to find the riskiest assumption
Once you have a list, you need a way to rank it. Two questions do most of the work: how much does this matter if it's wrong, and how much evidence do we have?
Bland describes this as assumptions mapping on Strategyzer. You plot each hypothesis on a 2x2 grid, with evidence on one axis (from "have evidence" to "no evidence") and importance on the other. The importance question is which hypothesis, if proven wrong, will cause the business idea to fail. The quadrant to test first is the one holding hypotheses that are critical for success and have the least evidence behind them.
Key Facts: The Riskiest Assumption Test
- Rik Higham published "The MVP is dead. Long live the RAT." on Hacker Noon on September 27, 2016.
- Higham's core claim: an MVP is not a product but a way of testing whether you've found a problem worth solving, and the alternative is to identify your riskiest assumption and test it.
- Assumptions mapping plots hypotheses by importance and evidence, and prioritizes the critical ones with the least evidence (Strategyzer, David J. Bland).
- Testing Business Ideas groups hypotheses into desirability, feasibility, and viability.
- The Lean Startup site says the method starts with leap-of-faith assumptions and uses a minimum viable product to test them.
- There is no formal standard for a RAT. Thresholds, formats, and names vary by team.
A practical way to run the ranking session with a small team:
- Write every assumption on its own sticky note or line, one belief per note.
- Tag each as desirability, feasibility, or viability.
- Place each on the grid, arguing only when two people disagree on placement. The disagreement is useful information.
- Circle the top few in the high-importance, low-evidence corner.
- Pick one. If you can't choose, ask which one, if false, would make the others irrelevant.
That last question is the shortcut. Some assumptions are upstream of everything else. If nobody has the problem, it doesn't matter whether your pricing is right.
Steps to run a RAT
A RAT is a normal experiment with a tight scope. Write it down before you run it, especially the pass threshold.
- State the assumption as a testable sentence. "At least 8 of 20 freight dispatchers we interview will agree to a paid pilot" can be wrong. "Dispatchers need better tools" can't.
- Choose the smallest test that produces real behavior. Higham asks, what's the smallest experiment you can do to test your biggest assumption? Prefer actions over opinions.
- Pick one metric. One number you'll read the same way regardless of who's looking.
- Set the pass and fail thresholds in advance. Decide now what result means "go", what means "stop", and what means "inconclusive, run it again differently".
- Run it, then record the result without rewriting the question.
- Decide. Move to the next assumption, adjust the idea, or drop it.
Higham notes that once you've validated the riskiest assumption you can move on to the next largest one, gradually building confidence in the idea. That sequencing is the whole method.
Here's how the table might look for a hypothetical idea: invoice-matching software for small freight brokers. The numbers are invented to show the format, not benchmarks.
| Assumption | Test | Metric | Pass threshold (set in advance) |
|---|---|---|---|
| Brokers feel invoice matching is painful enough to pay to fix | 20 interviews with brokers, ending with an offer of a paid pilot | Number who accept the pilot offer | 6 or more of 20 accept |
| Brokers will send us real invoices | Ask five interviewees to email three anonymized invoices | Number who send them within a week | 3 or more of 5 |
| We can match invoices accurately | Hand-match the received invoices and time it, or run a basic script on them | Accuracy and minutes per invoice | 90% or better, under 2 minutes each |
| Brokers will pay a monthly fee | Quote a price in the pilot offer | Share who agree at the quoted price | At least half of those who accept |
Notice that the cheapest tests don't involve software. They're conversations, a manual service, or a sketch someone clicks through.
Example tests by risk type
Bland and Osterwalder's book describes a library of experiment types, organized by cost, time, and strength of evidence, per the Strategyzer book page. You don't need dozens. A handful of common choices cover most early tests:
| Risk type | Test | What it tells you | Typical effort |
|---|---|---|---|
| Desirability | Customer interviews about past behavior | Whether the problem is real and recurring | Low |
| Desirability | Landing page with a clear promise and a signup or preorder | Whether a targeted audience takes a small action | Low |
| Desirability | Paid pilot offer or letter of intent | Whether anyone commits money or time | Medium |
| Feasibility | Manual or concierge delivery of the service | Whether the work can be done and what it costs | Medium |
| Feasibility | Technical spike on the hardest component | Whether the hard part works at all | Medium |
| Viability | Price test with real quotes | Whether customers accept the price | Low to medium |
| Viability | Unit-cost sheet built from actual pilot costs | Whether margins can work | Low |
The authors summarize one principle as "behaviour beats opinions": what customers do is stronger evidence than what they say. A signup is weak, a paid pilot is stronger. Match the test to how much risk you're trying to remove.
RAT vs MVP
People often use the two terms as synonyms. Higham's point is that they should not be.
| RAT | MVP (as commonly practiced) | |
|---|---|---|
| Starting point | The riskiest unknown | A first version of a product |
| Question | "What must be true, and is it?" | "What's the least we can ship?" |
| Output | An answer: pass, fail, or inconclusive | A product people can use |
| Typical form | Interview, mock-up, manual service, landing page | A working but minimal build |
| Scope risk | Small, because the test defines the scope | Grows, because it's a product |
| Pass criteria | Set before the test | Often vague |
Higham writes that a RAT is explicit: there's no need to build more than what's required to test your largest unknown, no expectation of perfect code or design, and no danger it will prematurely become a product. He contrasts that with the MVP, which can seduce a team with a false sense of a clear, linear path to an optimized solution.
None of this means MVPs are bad. Once your riskiest assumptions have survived testing, building a real minimum viable product is the logical next move. The RAT just keeps you from building one to answer a question you could've answered in a week with a spreadsheet and a few phone calls.
When you've run a RAT, what next
There are three honest outcomes.
- Pass. The result cleared the threshold you set. Move to the next riskiest assumption. Don't declare the whole idea validated, because one passed test removes one risk.
- Fail. The result missed the threshold. You can adjust the idea (a pivot or a narrower segment), or drop it. Both are good outcomes compared with finding out after launch.
- Inconclusive. The sample was too small, the wrong people were asked, or the test didn't measure the thing you cared about. Redesign the test; don't relabel it a pass.
Repeating RATs over time is how a team builds toward problem-solution fit and, later, product-market fit. If you want to run these as a regular rhythm, a growth experimentation framework gives you a place to log hypotheses and results. For where this sits in a company's life, see the stages of a startup, and for talking to the right people, customer discovery covers interviews in depth.
Common mistakes
- Testing the safe assumption. Teams pick the one they can test easily, not the one that matters. Rank on importance and evidence first.
- Treating a prototype as the test. If the test needs weeks of development, it isn't small enough. Higham's warning about scope increases applies: the team should keep asking whether this is the smallest thing they can do to test the riskiest assumption.
- Setting the threshold after seeing the data. Any result can be explained as a success once you've seen it. Write the pass line down first.
- Measuring opinions. "People said they liked it" costs the speaker nothing. Look for a signup, a deposit, a pilot, a shared document.
- Testing on friends. They're polite. Recruit from the segment you plan to serve.
- Bundling several assumptions in one test. If it fails, you won't know why. One assumption per test.
- Testing once and stopping. Passing a test removes one risk. Assumptions have a way of replacing themselves with the next one down the list.
- Ignoring the all-or-nothing ones. Some assumptions, like "customers will pay at all", can end the idea by themselves. Test those early.
Higham also argues this isn't only for startups. Established companies are at risk too: after years of success you can be lulled into a false sense of security, and into building something nobody wants to use. A RAT is cheap insurance in either setting.
Quick checklist
Before you run your next test, check that you can answer these:
- Which risk type is this: desirability, feasibility, or viability?
- Why is this the riskiest assumption, not just the easiest one?
- What's the smallest test that produces real behavior?
- What single metric will we read?
- What result means pass, fail, or inconclusive, written down before we start?
- What will we do differently depending on the answer?
For founders still choosing which problem to chase, the article on startup idea sources helps with the step before any of this.
Related reading
