Riskiest Assumption Test (RAT): Testing What Could Kill Your Product First

The Minimum Viable Product has been systematically misused for almost twenty years. Eric Ries’s original definition — “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” — was a learning vehicle, not a shoddy release. In practice MVP got collapsed into “the smallest thing we can ship” and then into “the smallest thing we can put a logo on”. Teams shipped rough products, called them MVPs, watched them get no traction, and blamed the market.

Rik Higham’s 2016 piece “The MVP Is Dead. Long Live the RAT” was the corrective. Higham’s argument was that the early-stage question shouldn’t be what’s the minimum product we can build? It should be what’s the single assumption most likely to kill this idea, and what’s the cheapest experiment that tests it? Not a product at all. A test. An experiment. An evidence-generator.

That reframe has only become more important. AI has collapsed the cost of building a minimum product to nearly nothing, which means the old MVP formulation has lost its economic teeth. What it hasn’t done is make the assumptions any less likely to be wrong. If anything it makes them more likely to be wrong, because teams now skip validation and jump straight to shipping.

A Riskiest Assumption Test (RAT) is the smallest possible experiment designed to validate or invalidate the single assumption whose failure would kill an early-stage product. It is not a product, it is not a build, it is an evidence-generating activity. Common RAT formats include concierge services, landing-page smoke tests, Wizard-of-Oz prototypes, explainer videos (Dropbox Houston), and third-party re-sells (Zappos shoe photos). The RAT replaces the MVP as the unit of early-stage work when — as in 2026 — the cost of building is no longer a meaningful filter.

Sign up (free) to run RATs instead of shipping premature MVPs

The Higham Reframe: Test the Assumption, Don’t Build the Product

Higham’s central claim, from the 2016 piece:

“A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. No danger it will prematurely become a product.”

Three things are worth emphasising:

1. It’s not a product. A RAT is an experiment. A product is what you build when the experiments have stopped failing. Running a RAT doesn’t mean shipping something to a few users; it means designing the experiment that produces the evidence.
2. It tests a specific assumption. Not “does this work?” — that’s too vague. A good RAT specifies: if fewer than X% of Y customers do Z when shown W, we kill this idea. The kill criterion goes in before the experiment runs.
3. It is cheap by design. The whole point is to get the evidence before you spend the money. If the RAT is expensive, it probably isn’t a RAT — it’s a scope reduction of the full product.

The canonical examples are worth knowing:

• Dropbox “Houston” video (Drew Houston, 2007): before building sync for multiple operating systems, Houston made a three-minute explainer video showing the intended behaviour. Waiting-list sign-ups jumped from 5,000 to 75,000 overnight. The assumption tested: do people actually want this? The cost: a video.
• Zappos shoe photos (Nick Swinmurn, 1999): Swinmurn photographed shoes in local stores, posted them online, and when an order came in, bought the shoes at retail and shipped them. Lost money on every sale. Proved the underlying assumption: people will buy shoes online.
• Buffer landing page (Joel Gascoigne, 2010): a two-page smoke test — explain the idea, show a “Plans and Pricing” page, measure click-through to an email capture. Measured willingness-to-pay before a line of product code was written.
• Airbnb air mattresses (2007): the founders rented out three air mattresses in their own apartment during a design conference. Assumption tested: will strangers pay to sleep on someone’s floor? Not elegant. Very cheap. Very conclusive.

None of these is a product. All of them are experiments that generated evidence the founders could act on — including the evidence to stop, which is equally valuable.

MVP vs RAT: The Distinction That Matters

A common confusion — even among teams that should know better — is collapsing MVP and RAT into the same thing. They’re different.

The sequence that works in 2026 is: RAT → RAT → RAT → MVP → PMF measurement. You run RATs until you’ve killed every plausible killer assumption. Only then do you build something you could call a product. Skipping the RAT stage and going straight to MVP is how teams burn 18 months on polished products nobody wanted — see the whole problem-solution fit discussion in the PSF article , and the culture of adequacy article on why “minimum” anything is rarely the right goal once you’re past validation.

How to Identify the Riskiest Assumption

Most teams don’t struggle with the concept of a RAT. They struggle with identifying which assumption is the riskiest. The canonical tool is a two-by-two grid — Importance × Uncertainty — with the riskiest assumption sitting in the top-right corner (most important to the business, most uncertain whether true).

Two techniques help surface candidates:

First principles decomposition. Break the product thesis into component beliefs. “Small businesses will subscribe to a £99/month roadmapping tool” decomposes into: small businesses have the roadmapping problem; they will pay to solve it; £99 is a price they’ll pay; monthly subscription is a format they’ll accept; our specific tool solves their version of the problem; they will find us through the channels we can afford; they will renew. Seven assumptions, each testable.

Inversion. For each component belief, ask: what’s the evidence we’d see if this were wrong? A PMF thesis becomes: what would low Ellis scores look like? What would low retention look like? What pipeline shape would indicate we’re pushing not pulling? Now you have falsifiable expectations — the foundation of any honest experiment.

Once you have the candidate assumptions, rank them. David Bland’s Testing Business Ideas (Strategyzer, 2019) is the best operational treatment — his Assumption Map deserves its own article in this cluster (see Assumption Mapping ). For quick use, the rule is: if this assumption is wrong, does the idea die? If yes, it’s a candidate for RAT. Of those, which has the least supporting evidence? That’s the one to test first.

Teresa Torres’s Opportunity Solution Tree is a complementary framework: the bottom layer of the tree is the experiments that test the assumptions underneath each solution branch.

Designing a RAT: The Five-Step Pattern

1. State the assumption in a falsifiable sentence. Not “customers want this”. Instead “at least 15% of our email list will click through to a pricing page within 14 days of the announcement email”.
2. Define the kill criterion in advance. “If click-through is below 5%, we abandon the idea.” This is the Annie Duke / Thinking in Bets discipline of pre-committing so you can’t rationalise afterwards.
3. Pick the cheapest experiment that produces credible evidence for or against. A landing page. A concierge service. A Wizard-of-Oz prototype (human behind a fake backend). A short explainer video. A manual five-customer cohort.
4. Run it. With real target-segment users, not your family. With Mom Test discipline if it involves interviews.
5. Act on the result. Pass → proceed to the next-riskiest assumption. Fail → kill the idea, or pivot on the specific assumption that failed. Stall → the experiment wasn’t decisive enough; redesign.

The Google Ventures Design Sprint (Jake Knapp’s Sprint, 2016) is one practical vehicle for running a bounded RAT in a week. It works especially well when the riskiest assumption is about user behaviour with a proposed solution and you need a high-fidelity prototype to test it credibly.

The 2026 Reframe: Why RAT Matters More Than MVP Now

Pre-AI, the MVP had economic teeth. Building the “minimum viable” anything took at least a few months of engineering, which forced at least some problem-validation discipline before committing the budget. The MVP as a unit of work was a fair compromise between learning and shipping.

In 2026 the economics have flipped. An MVP in the traditional sense — a rough but shippable product — now takes a week. That’s not a meaningful filter. A team with even moderate discipline can produce ten MVPs in a quarter, and ten unwanted MVPs is much worse than one, because each carries its own support burden, its own maintenance debt, and its own opportunity cost on the next thing.

The RAT does what the MVP used to do but doesn’t do any more: it forces specific, falsifiable evidence generation before commitment. You can’t speed-run a RAT the way you can speed-run an MVP, because a RAT’s value lies entirely in the specificity of the assumption being tested. A vague RAT produces vague evidence, and vague evidence can’t kill an idea. The discipline protects itself.

This is consistent with the AI-era framing that threads through the early-stage validation cluster : AI collapsed build cost; sell cost (distribution, trust, references) is unchanged. The assumptions most likely to kill an early-stage product in 2026 are almost never feasibility assumptions. They’re value assumptions (“will anyone care?”), viability assumptions (“will anyone pay enough?”), and channel assumptions (“can we reach them economically?”). RAT is the instrument designed to test exactly those.

Cagan’s Four Risks Mapped to RAT

Marty Cagan’s four product risks map onto RAT cleanly. The job of the RAT is to test the specific risk most likely to kill the idea.

In 2026, feasibility RATs are rarely the ones you need. Value and viability RATs are almost always the ones that actually matter. If a team’s instinct is to run a technical RAT first, ask why — usually it’s because technical risks are the ones the team knows how to investigate, not the ones most likely to kill the idea. Cagan’s product operating model is the structural discipline that pushes empowered teams to run the uncomfortable RAT, not the comfortable one.

Try RoadmapOne to tag RATs as discovery objectives — free sign-up

The PE / NED Diagnostic: “Show Me the RAT”

This is a board question I’ve started using routinely in diligence and new-product reviews. The full version:

“For this bet, what’s the single assumption most likely to kill it, and what’s the experiment you’ve run or are running to test that assumption?”

The answers I get sort into four bins:

1. A clear assumption and a specific, designed experiment with a kill criterion. Rare. When I see it, the bet is credible even if it ultimately fails — the team is learning fast.
2. A clear assumption, no experiment yet. Acceptable if they’re pre-funding; unacceptable if they’ve already spent three months building.
3. A vague assumption, a prototype they call an MVP. The bet is theatre. The team is building because building is what they know how to do, not because they’ve identified what they need to learn.
4. “We’ll know when we ship it.” Kill-list candidate. Silent acceptance of this answer is how portfolios burn money.

Boards that adopt “show me the RAT” as a standing question improve the quality of early-stage bets considerably. Teams learn to arrive at the review with the RAT ready, and the conversation shifts from “how much more should we spend?” to “what have we learned and what do we still need to test?”. That’s a healthier conversation.

The Business Case Test: Discovery Without Rigour Is Theatre

This is the diagnostic I now apply before I take any RAT programme seriously. Has somebody done the actual work of building a proper business case for the bet?

A proper business case sizes the market, segments the customers, works out TAM and SAM by phase (early adopter, early majority, mainstream), models the unit economics at each phase, and — crucially — commits to a revenue line in the actual budget. Not a forecast sitting in an appendix. A line someone will stand behind personally at board reviews, with their name against it, for the next four quarters.

Without that commitment the team isn’t empowered to deliver an outcome. They’re being asked to build features and hoping something works. That’s the Cagan feature-team pathology re-dressed as “discovery”: no outcome ownership, no accountability for whether the bet produces value, just a roadmap of experiments run for their own sake.

Discovery in service of a committed outcome is fine. It’s how you sharpen assumptions, pick the right experiments, and spend the budget well. Discovery without a committed outcome is almost always theatre — a way for the organisation to claim it’s doing something new without anyone being on the hook for whether it works.

The board question: who has signed up for the revenue line this RAT programme is feeding into, and where does it sit in the budget? If the answer is “nobody” and “nowhere”, the programme is theatre and the appropriate intervention is to either get someone to commit — or to kill the programme rather than dress up its optionality.

Products, Not Companies: RAT Inside a Portfolio

Like every framework in this cluster, RAT applies per-product, per-bet. A mature company has multiple early-stage bets running at any one time — some in adjacency moves, some in new geographies, some in entirely new product lines. Each of those bets has its own riskiest assumption. Conflating them — treating them as one “innovation pipeline” — obscures the specific evidence each bet needs.

The Run / Grow / Transform lens and the Three Horizons framework both make this visible. Transform / Horizon 3 bets are exactly the context where RAT thinking earns its keep; Run / Horizon 1 work doesn’t need RATs because the assumptions are already validated by the paying customer base.

The Side-of-Desk Anti-Pattern

The most common failure mode I see is RATs that never get run because the team tasked with running them has a day job delivering the Run product. Discovery work always loses to delivery work when the same people are on the hook for both — delivery has deadlines and visible outputs, discovery has neither.

The fix is the familiar one: dedicated minimum viable team for any Transform bet worth pursuing. Two engineers and a product person, full-time, with a proper business case and a first-90-days plan that consists of RATs, not features. Protect them from interrupt work using WIP limits , measure them on learning outcomes not feature velocity (see outcome-based roadmaps and outcome vs output vs input ), and accept that their output for the first quarter may genuinely be “we’ve killed two assumptions, one is validated, and we’re about to start building”.

Companies that can’t allocate this capacity should kill the bet outright rather than limp along with side-of-desk work. The worst of the three options is the middle path: enough resource to keep the bet officially alive, not enough to actually learn anything. That’s how Transform budgets get wasted without the board ever realising.

RAT, Dual-Track Agile, and the Discovery Backlog

RATs don’t live in the delivery sprint. They live in the discovery track. The dual-track agile model — continuous discovery alongside continuous delivery — is the structural home for RAT work. The discovery backlog is the list of assumptions waiting for RATs. The discovery team prioritises by importance-and-uncertainty, designs the experiment, runs it, and feeds validated solutions into the delivery backlog.

The cadence that works: one or two RATs in flight at any time, each with a clearly specified kill criterion and a time-box of two to four weeks. Any longer and the RAT has probably drifted into becoming an MVP. See the product discovery cluster for deeper treatment of the discovery-track discipline — particularly allocating discovery capacity and leading discovery activities .

How RoadmapOne Helps

RoadmapOne lets you tag RATs as discovery objectives alongside delivery objectives on the grid. A Transform squad with three RATs in flight shows up differently from a delivery squad with three features shipping — because the team’s measurable outcome is validated-or-killed-assumptions, not shipped scope. The Run / Grow / Transform analytics tell the board how much capacity is going into RAT-driven learning, which is usually a fraction of what the board assumes.

Frequently Asked Questions

What is a Riskiest Assumption Test (RAT)?

A RAT is the smallest possible experiment designed to validate or invalidate the single assumption most likely to kill an early-stage product. It was coined by Rik Higham in a 2016 HackerNoon article as a corrective to the abuse of “MVP”. Crucially, a RAT is not a product — it’s an experiment. Common formats include landing-page smoke tests, concierge services, explainer videos, Wizard-of-Oz prototypes, and third-party re-sells. The output of a RAT is evidence (pass, fail, or quantified), not a shippable product.

How is a RAT different from an MVP?

An MVP is a rough but shippable product; a RAT is an experiment. MVPs test strengths (“does the value show through?”); RATs test weaknesses (“which assumption kills us?”). MVPs typically have implicit success criteria; RATs have explicit kill criteria defined before the experiment runs. The practical sequence is RAT → RAT → RAT → MVP → PMF measurement . In the AI era, where building is cheap, the MVP has lost its economic teeth and the RAT has become the defensible unit of early-stage work.

How do you identify the riskiest assumption?

Decompose your product thesis into component beliefs (the first-principles method), then for each belief ask what evidence would we see if this were wrong? (inversion). Plot the candidates on an Importance × Uncertainty grid — the riskiest assumption sits top-right, high on both axes. If you need operational tooling, David Bland’s Assumption Map (Strategyzer / Testing Business Ideas) is the best published framework. For quick use, the question is: if this one is wrong, does the idea die? If yes, it’s a RAT candidate.

What are good examples of RATs?

Drew Houston’s 2007 Dropbox explainer video (tested demand before building sync). Zappos founder Nick Swinmurn photographing shoes in local stores and reselling them by hand (tested whether people would buy shoes online). The Airbnb founders renting three air mattresses in their apartment during a design conference (tested whether strangers would pay to sleep on someone’s floor). Buffer’s 2010 two-page landing page with a pricing page click-through (tested willingness-to-pay before building). None of these is a product. All of them generated decisive evidence cheaply.

When should we run a RAT rather than build the product?

Always, at the early stage. The question “should we build this product?” is almost always really a stack of more specific questions: “is the problem real? will anyone pay? can we reach them? will they adopt it?” Each of those has a RAT that answers it more cheaply than building. The case for building directly only exists when the underlying assumptions are already validated (because you have PMF on an adjacent product ) or when the RAT itself would cost as much as the build (extremely rare in 2026).

Who should run the RAT programme?

A dedicated team, not a side-of-desk assignment. The minimum viable composition is two engineers and a product person, full-time, with a proper business case and the autonomy to design and run the experiments. Teams running RATs alongside BAU delivery almost always skip the RATs in favour of the delivery work — discovery has no deadlines; delivery does. This is the same pattern that kills problem-solution fit work and that the dual-track agile model is designed to prevent.

Sign up (free) to tag RATs as dedicated discovery objectives

Conclusion

The Riskiest Assumption Test is Higham’s corrective to a decade of MVP misuse, and in 2026 it matters more than when he wrote it. AI has removed the economic friction the MVP used to provide; the RAT restores that friction in the form of explicit, falsifiable, pre-committed experiments whose design is the discipline.

The board question is always the same: what assumption, if wrong, kills this, and what are you doing to test it? Teams that can answer are ahead. Teams that can’t are theatre, and the longer that theatre runs the more expensive it becomes.

Run RATs. Kill ideas cheaply. Only build when the assumptions have stopped failing. Give a dedicated team the remit to do nothing but this until they have a bet worth taking to build. That discipline is the single biggest advantage an early-stage product organisation can have in the AI era, and almost nobody practises it.

Baxter image prompt (photorealistic, 4:3): Baxter the wirehaired dachshund as a bomb-disposal technician in a kevlar vest and thick protective gloves, leaning in close to examine a small wooden crate on a workshop bench. Stencilled on the crate: “RISKIEST ASSUMPTION — HANDLE CAREFULLY”. Beside the crate, a notebook open to a page with a hand-drawn 2×2 grid labelled Importance × Uncertainty. A single red wire lifted between his paws. Harsh workbench lighting, concentration in the eyes, no sign of showmanship — just craft.