TL;DR
A Riskiest Assumption Test (RAT) identifies the single assumption that would kill your idea if it were wrong, and tests only that with the cheapest possible experiment, before you build anything. An MVP is the smallest real, usable product you build to learn from real users. A RAT removes your biggest single risk for almost nothing; an MVP tests the actual product once building is justified.
They are not enemies, despite the famous framing. A RAT comes first, as a fast "learn then build" experiment; an MVP is the "build then learn" step you take once the riskiest assumption survives. This guide covers the full MVP vs RAT comparison: what a RAT is, where "the MVP is dead" came from, how the two differ, and which you actually need first.
MVP vs RAT: the difference that matters most
If you remember one thing, make it this: an MVP is something you build, a RAT is something you test, and the RAT comes first.
A RAT answers the question "what is the one thing that has to be true for this to work, and is it?" You list your assumptions, find the riskiest one, and run the smallest experiment that could prove it false, often with no product at all. If the riskiest assumption fails, you have saved yourself from building the wrong thing for almost nothing.
An MVP answers the question "does the smallest real version of this product actually work for users?" It is a genuinely usable product, stripped to its core, that real people use so you can measure demand, activation, and retention.
So the two sit at different points on the risk curve. A RAT is a cheap, pre-build experiment aimed at your single biggest unknown. An MVP is a real, if minimal, build aimed at learning from real usage. Confusing them, or skipping the RAT and jumping straight to building an MVP, is how teams spend weeks building something a one-day test would have killed.
What is a Riskiest Assumption Test (RAT)?
A Riskiest Assumption Test (RAT) is the practice of identifying the single assumption most likely to sink your idea, and running the smallest, cheapest experiment that could disprove it, before committing to a build. The term was popularized by product manager Rik Higham in his 2016 article "The MVP is dead. Long live the RAT."
His argument was a reaction to how the term "MVP" had been corrupted. In theory an MVP is the smallest thing that lets you test a hypothesis. In practice, teams heard "Minimum Viable Product" and built a small version of the whole product, spending weeks or months, when the honest question could often be answered without building anything. The RAT reframes the goal: do not build a mini-product, test your riskiest assumption.
Key characteristics of a RAT:
- Purpose: disprove (or confirm) your single biggest assumption, not build a product.
- What you build: whatever is cheapest to run the test, often a survey, a landing page, a manual service, or nothing digital at all.
- Sequence: learn-test first; you build only if the assumption survives.
- Cost: as close to zero as possible, so a failed test is a cheap win.
- Outcome: a clear read on whether the make-or-break assumption holds.
The heart of a RAT is prioritisation. Every idea rests on a stack of assumptions, that people have the problem, that they will pay, that you can reach them, that the technology works. The RAT insists you find the one whose failure would be fatal and is most uncertain, and test that first, rather than building a product that quietly assumes all of them are true.
What is an MVP?
An MVP, or minimum viable product, is the smallest version of your product that lets real users complete the core job your idea promises, so you can learn whether the market actually wants it. The concept was popularized by Eric Ries in The Lean Startup as part of the build-measure-learn loop.
Unlike a RAT, an MVP is a real, working product. It is missing most features, but the ones it has function, and a real user can complete the core flow end to end. Its success is measured in behaviour: sign-ups, activation, retention, and payment.
Key characteristics of an MVP:
- Purpose: learn whether a real, minimal product delivers value and retains users.
- What you build: a usable, minimal, production-grade product.
- Sequence: build-measure-learn; you build first, then learn from usage.
- Cost: a real build, tightly scoped, often around 3-4 weeks.
- Outcome: validated learning and a foundation you keep and grow.
The MVP is kept and iterated, not thrown away. For a fuller treatment, see our guides to the types of MVP and the MVP development process.
"The MVP is dead. Long live the RAT" — what the debate is really about
The provocative title was not really an attack on the MVP concept; it was an attack on how the word gets used. Higham's point was that "MVP" had come to mean "build the smallest product," which pulls teams straight into building, when the original spirit of the lean startup was to test the riskiest part of your hypothesis as cheaply as possible.
Seen that way, the RAT is less a replacement for the MVP and more a correction: a reminder that the goal is validated learning, not shipping a small product for its own sake. Many practitioners point out that a properly scoped MVP is supposed to test the riskiest assumption anyway, which is exactly why the two ideas are complementary rather than opposed. The RAT just makes the priority explicit and refuses to let "build something small" masquerade as "learn something important."
MVP vs RAT: side-by-side comparison
| Dimension | Riskiest Assumption Test (RAT) | Minimum Viable Product (MVP) |
|---|---|---|
| Core question | Is our single riskiest assumption true? | Does the smallest real product work for users? |
| Approach | Learn-test (test before building) | Build-measure-learn (build then learn) |
| What you build | The cheapest possible experiment | A real, usable, minimal product |
| Is it a product? | No, often no code at all | Yes, the core flow genuinely works |
| Cost & speed | Near-zero, hours to days | A real build, tightly scoped (~3-4 weeks) |
| What it de-risks | Your one make-or-break assumption | Value, usability, retention, demand |
| Comes | First, before you build | After the riskiest assumption survives |
| Best when | One clear assumption could kill the idea | Risk is understood; you need a real product |
The comparison categories that matter
Purpose. A RAT isolates and kills your biggest single risk; an MVP tests a real product. If one specific assumption would sink everything, that is a RAT question. If you already believe the idea is broadly sound and need to see a working product in real hands, that is an MVP question.
Sequence. This is the cleanest distinction. A RAT is learn-then-build: you test the assumption first and only build if it holds. An MVP is build-then-learn: you build the smallest real product and learn from usage. The RAT sits upstream of the MVP.
What gets built. A RAT builds whatever is cheapest to answer the question, frequently nothing more than a landing page, a survey, or a manual process. An MVP builds a genuinely working core flow. The moment the thing actually works for a user, you have left RAT territory.
Cost and risk. A RAT is deliberately near-free, so you can run several and kill bad ideas cheaply. An MVP is a real investment. Spending MVP-level effort to answer a RAT-level question is the exact waste the "MVP is dead" argument was warning about.
How to find your riskiest assumption
The hard part of a RAT is not running the test, it is choosing which assumption to test. Nearly every idea rests on four broad kinds of assumption, and the riskiest one is usually hiding in whichever you have thought about least:
- Desirability (demand). Do people actually have this problem and want it solved? The most common fatal assumption.
- Viability (willingness to pay). Will they pay enough, often enough, for the business to work?
- Feasibility. Can it actually be built and delivered with the technology and resources you have?
- Usability. Can people understand and complete the core flow without help?
To find the riskiest one, weigh each assumption on two axes: how uncertain it is (do you have real evidence, or are you guessing?) and how fatal it would be if it turned out false. Your riskiest assumption is the one that is both highly uncertain and would sink the whole idea. Anything you already have strong evidence for, or that would only dent the idea rather than kill it, can wait.
Then match the test to the type of assumption, because each kind is disproved differently:
| Your riskiest assumption is about… | The cheapest way to test it |
|---|---|
| Demand | A landing-page or fake-door test, or a pretotype |
| Willingness to pay | A pre-sale, a real "buy"/pricing page, or a crowdfunding campaign |
| Feasibility | A narrow technical spike — which is exactly a proof of concept |
| Usability | A clickable prototype tested with a handful of users |
Naming the type of your riskiest assumption tells you which experiment to reach for, and stops you running a demand test when your real unknown was whether the thing can be built at all.
How to run a RAT (in five steps)
- List your assumptions. Write down everything that has to be true for the idea to succeed: the problem exists, people will pay, you can reach them, the technology works, and so on.
- Rank by risk and uncertainty. Find the assumption that is both most likely to be wrong and most fatal if it is. That is your riskiest assumption.
- Design the cheapest disproving test. Choose the smallest experiment that could genuinely prove that assumption false, a landing page, a pre-sale, a survey, a concierge run, a fake-door click test.
- Set the pass/fail bar first. Decide before you run it what result means "proceed" and what means "stop or pivot," so you cannot rationalise a bad result afterwards.
- Run it, then decide. If the assumption survives, move on to the next risk, or to building an MVP. If it fails, you have saved yourself an enormous amount of wasted work.
A concrete example: a RAT in action
Imagine a founder who wants to build an app that lets independent restaurants automatically reorder stock from their suppliers. The instinct is to start building the supplier integrations. A RAT stops and asks: what has to be true first?
List the assumptions. Restaurant owners find manual reordering painful enough to change habits; they would trust software to place orders for them; suppliers can be integrated with; owners will pay a monthly fee; the reorder predictions can be made accurate enough.
Pick the riskiest. Integrations are fiddly but clearly feasible — other tools already do it — so that is not the riskiest. The genuinely uncertain, make-or-break assumption is demand plus willingness to pay: will busy owners actually adopt and pay for this, instead of just texting their supplier like they always have? If that is false, nothing else matters.
Design the cheapest disproving test. Not an app. The founder builds a one-page site describing the product with a clear monthly price and a "Start free trial" button, spends a small budget driving local restaurant owners to it, and has a dozen direct conversations. The button does not lead to a real product — it captures the click and an email. That is a fake-door test aimed squarely at the demand-and-pricing assumption.
Set the pass/fail bar first. "If fewer than 8 of every 100 relevant visitors click Start free trial, and fewer than 3 owners agree to a paid pilot in conversations, we do not build." Deciding this before seeing the numbers keeps the founder honest.
Run it and decide. Suppose almost nobody clicks, and owners say they are perfectly happy texting their supplier. That result cost a weekend and a little ad spend — and it just saved months of building integrations for a product the market did not want. The RAT did its job. Had the test passed, the founder would move on to the next risk, and then build a tightly scoped MVP of the reordering flow.
The whole point: the single most dangerous assumption was tested first, for almost nothing, before one line of integration code was written.
RAT and MVP together: the sequence
The healthiest way to use both is in order. Run a RAT (or a few) to kill the biggest assumptions for almost nothing. Once the make-or-break risks survive, build an MVP to test the real product with real users, and enter the build-measure-learn loop.
Notice how the RAT relies on the same lightweight techniques we cover elsewhere: a landing-page MVP, a fake-door test, a concierge MVP, or a wizard-of-oz MVP are all common ways to run a RAT. A pretotype is essentially a RAT whose riskiest assumption is demand, faked rather than built. In other words, RAT is the strategy (which risk to test), and those techniques are the tactics (how to test it). It all feeds the same judgment covered in MVP validation and the build-measure-learn loop.
Which should you build first?
Almost always the RAT, because it is cheaper and answers the more fundamental question. The deciding question: is there one specific assumption that would kill this idea, and am I unsure it is true?
- If yes, run a RAT first. There is no point building even a lean product on top of an assumption you have not checked.
- If your major risks are already reasonably validated and the real question is whether a working product delivers and retains, go straight to the MVP.
The expensive error is skipping the RAT and pouring weeks into an MVP whose whole premise rested on an untested assumption, the precise trap that made "the MVP is dead" such a resonant phrase.
When to run a RAT (and when not to)
Run a RAT when:
- One clear assumption would make or break the idea and you are not sure it holds.
- Building anything real is expensive or premature relative to the question you need answered.
- You can design a cheap experiment that would genuinely disprove the assumption.
Skip straight to an MVP when:
- Your riskiest assumptions are already reasonably evidenced.
- The only way to test the real risk is with a working product (some value simply cannot be faked).
- The build is so small that a tightly scoped MVP is barely more effort than the test itself.
Common mistakes founders make
- Building an MVP to answer a RAT-level question. If a survey or landing page could have settled it, weeks of building were wasted, the original "MVP is dead" complaint.
- Testing a comfortable assumption, not the riskiest one. A RAT is only useful if it targets the assumption that would actually kill the idea, not the one that is easiest to confirm.
- Measuring opinions instead of actions. "People said they liked it" is not a passed RAT. Sign-ups, pre-orders, and payments are.
- No pre-set pass/fail bar. Without deciding the threshold in advance, you will read any result as encouraging.
- Treating RAT and MVP as either/or. They are sequential and complementary, not a choice between camps.
How we approach RAT and MVP
When founders come to us, the first thing we do is name the riskiest assumption. If it can be tested cheaply without building, we will say so, run the RAT first, protect your budget, and only build once the make-or-break risk survives. When building is justified, the MVP itself is built to be kept: production-grade, fully owned code, scoped to the core flow, and shipped in about 3-4 weeks. We would rather run a one-week test that kills a bad idea than a four-week build that discovers the same thing the expensive way.
A quick decision checklist
- Is there a single assumption that would kill this idea if it were wrong?
- Am I genuinely unsure whether that assumption is true?
- Can I test it cheaply without building the product? If yes, run a RAT.
- Have my biggest risks already survived testing? If yes, build an MVP.
- Did I set a pass/fail bar before running the test?
Related guides
- MVP vs Pretotype — faking the product to test demand, a common way to run a RAT
- MVP Validation — proving demand before and around your build
- Build-Measure-Learn — the loop a validated assumption feeds into
- Types of MVP — the lightweight techniques a RAT uses in practice
Frequently asked questions
What is the difference between an MVP and a RAT?
A RAT (Riskiest Assumption Test) identifies the single assumption most likely to kill your idea and tests only that, with the cheapest possible experiment, before you build anything. An MVP is the smallest real, usable product you build to learn from actual users. In short: a RAT tests your biggest assumption before building (learn-then-build), while an MVP is a real product you build to learn from usage (build-then-learn). The RAT comes first.
What is a Riskiest Assumption Test?
It is the practice of listing your assumptions, finding the one that is both most uncertain and most fatal if wrong, and running the smallest experiment that could disprove it, before committing to a build. It was popularized by Rik Higham in his 2016 article "The MVP is dead. Long live the RAT." The test often takes the form of a landing page, survey, pre-sale, or manual service rather than a real product.
Is the MVP really dead?
No, the phrase is deliberately provocative. The argument was against how "MVP" is often misused, to mean "build a small version of the product", rather than against the concept itself. A properly scoped MVP is meant to test the riskiest assumption anyway, so the RAT is best understood as a correction and a complement, not a replacement. Most teams use both: a RAT to kill the biggest risks cheaply, then an MVP to test the real product.
How do you run a RAT?
List every assumption your idea depends on, rank them by how uncertain and how fatal each is, and pick the riskiest. Design the cheapest experiment that could genuinely prove that assumption false, set a pass/fail threshold in advance, run it, and decide: proceed to the next risk or an MVP if it survives, or pivot if it fails. The goal is maximum learning for minimum build.
Can a RAT replace an MVP?
No. A RAT proves whether a specific assumption holds, but it cannot tell you whether a real, working product will deliver value and retain users, because there is no product. Once your riskiest assumptions survive, you still need an MVP to test the real thing. They answer different questions at different stages and work best in sequence.
Is a pretotype the same as a RAT?
They are closely related but not identical. A pretotype fakes the product to test demand specifically. A RAT tests whatever your single riskiest assumption is, which might be demand, but could also be willingness to pay, a channel, or feasibility. A pretotype is therefore one common way to run a RAT when the riskiest assumption happens to be demand.
If you want a partner who names the riskiest assumption first, tests it cheaply when it can be, and only then builds a production-grade MVP you fully own, that is what we do. MVP development at MVP Development tests the right risk at the right time and ships your investor-ready MVP in 3-4 weeks. Book a free scoping call and we will map it with you.
