Riskiest Assumption Test vs MVP
They are not rivals — they are different tools for different moments. The mistake is reaching for the expensive one first.
Where each idea comes from
The MVP was popularized by Eric Ries in The Lean Startup: the version of a new product that generates the most validated learning for the least effort. The intent was always learning — but in practice the term inflated. "MVP" came to mean "version one with fewer features": still weeks of building, still a launch, still a roadmap defending it.
The riskiest assumption test was Rik Higham's 2015 reaction to that inflation ("The MVP is dead. Long live the RAT."): don't build the smallest product — build the smallest thing that tests your riskiest assumption. Usually that isn't a product. It's a fake door, five interviews, a landing page, or a two-day spike.
The distinction matters because an MVP tests everything at once. When it flops — most do — you can't tell which belief killed it: nobody wanted it, nobody understood it, or nobody would pay. A RAT isolates the one belief that decides whether the rest is worth testing at all.
RAT vs MVP, side by side
It's a sequence, not a rivalry
Take a concrete bet: a weekly activity digest to reduce churn. The MVP-first path builds the digest — templates, scheduling, unsubscribe handling — and learns four weeks later that admins don't open it. The RAT-first path asks: what does this bet most depend on? That busy admins want a weekly digest at all. Test it with a fake "Weekly digest" toggle in settings; success criterion: at least 20% of active admins opt in within two weeks. Two days, one clear signal.
If the toggle stays untouched, you just saved a month — and you know precisely why: desirability failed, not your copywriting or your cron jobs. If it clears the bar, you build the MVP knowing the demand is real, and the next riskiest assumption ("a digest actually changes behaviour, not just opens") becomes the thing the MVP measures.
When to skip the RAT and just build
Honesty clause: testing everything is its own failure mode. Skip the ceremony when:
If support tickets, interviews, or analytics already answer the question, running a test is procrastination. Attach the evidence to the assumption and move on.
If building the thing costs a day and reversing it costs nothing, the build is the test. Ship it behind a flag and watch what happens.
Feasibility assumptions are often tested by building — a spike is a RAT that happens to be code. The trick is timeboxing it and throwing it away.
The reverse trap is more common: calling a six-week build "an experiment." If it has a backlog, a launch date, and no pre-written success criterion, it's not a test — it's a bet you've stopped questioning.
Where the assumptions live
Whichever tool you reach for, the beliefs behind a bet need somewhere to live — or the same argument repeats every quarter. In an Opportunity Solution Tree, assumptions are the bottom layer: each solution carries the beliefs it depends on. In Outcomify they are first-class nodes with a status — untested, validated, invalidated — and the evidence behind it, so "we tested that in March" is a link, not a memory.
Frequently Asked Questions
Common questions about RATs and MVPs
Keep exploring
How to Test Product Assumptions
The full method: surface, map by importance × evidence, and test the riskiest first.
Riskiest Assumption Examples
Concrete examples by type — each with the smallest test and a success criterion.
What is an Opportunity Solution Tree?
The framework where assumptions hang under the solutions that depend on them.
Test the belief before you build the product
Outcomify keeps every solution's assumptions visible — with a status and the evidence behind it — so your team always knows what's been tested and what's still faith.