---
title: "Riskiest Assumption Test: A PM Walkthrough"
description: "A riskiest assumption test finds the one belief that would sink your idea and tests it with the cheapest prototype that could fail. Steps, types and an example."
canonical_url: "https://builderscamp.com/guides/other/riskiest-assumption-test"
date_published: "2026-09-27"
date_modified: "2026-09-27"
author: "Andre Albuquerque"
publisher: "Builders Camp"
guide_class: "other"
---

# Riskiest Assumption Test: What to Prototype First

**TL;DR:** A riskiest assumption test checks the one belief your idea depends on most and has the least evidence for, using the cheapest prototype that could prove it wrong. Find it by listing your desirability, viability and feasibility assumptions, rating each on impact and evidence, and testing only the top one before you build anything else.

Before you prototype anything, decide which question the prototype has to answer. A riskiest assumption test (RAT) is the answer to "what should we prototype first?": the one belief that would sink the idea if it were false, tested with the cheapest thing that could prove it false.

Product manager Rik Higham made the case for the RAT in a 2016 [Hacker Noon post](https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02) arguing that teams build too much too early: "There is a flaw at the heart of the term Minimum Viable Product: it’s not a product." His point was that an MVP is really a test wearing a product's clothes, and treating it as a product invites scope creep. A RAT drops the pretence and asks only whether the biggest unknown holds.

The cheapest tests can move fast. In an interview with [Mixergy](https://mixergy.com/interviews/drew-houston-dropbox-interview/), Dropbox cofounder Drew Houston described what happened when the team posted a new demo video to Digg while signups were still going to a waiting list: "the day after we launched that video, we had 5,000 people on the waiting list the day before and 75,000 people a day later." A waiting list measures interest, not payment or retention, and one viral video is not a repeatable method. It still showed demand at a scale no survey would have, before the product was open to everyone.

## How do you find your riskiest assumption?

Five steps take you from an idea to the one assumption worth testing. Use a running example: a gym chain's app team wants to add 15-minute video calls where a personal trainer checks a member's squat or deadlift form.

**1. Write the problem in one sentence.** Name who has it and what it costs them: "Members who train alone don't know whether their form is safe, so they either avoid heavy lifts or risk injury." If you cannot write it without naming your solution, you are testing a feature, not a problem.

**2. List every assumption.** Sort them under three headings, closely related to the risks in the [five risks assessment](https://builderscamp.com/guides/glossary/five-risks-assessment):

- **Desirability:** members worry about their form; they would show their lift to a trainer on camera; a 15-minute check is enough to help.
- **Viability:** members will pay per call or upgrade their plan for it; trainers will take short calls at a rate the gym can afford.
- **Feasibility:** a phone propped on the floor gives a trainer a usable view of a lift; the video works on gym Wi-Fi.

**3. Rate each assumption on impact and evidence.** Impact is how badly the idea breaks if the assumption is false. Evidence is what you already know, from data, interviews or past launches. An [assumption matrix](https://builderscamp.com/guides/glossary/assumption-matrix) is the standard way to plot this: high impact and low evidence is the corner that matters.

**4. Pick one.** In the gym example, the team already has survey data showing members worry about form, so that assumption has evidence. Nobody knows whether members will film themselves lifting and show it to a stranger. It is high impact (without it there is no product) and low evidence. That is the riskiest assumption.

**5. Write it as a test that can fail.** "At least 3 in 10 members we invite will book a form check and join the call with their camera on." The pass line is set before the test runs, so the result cannot be argued into a success afterwards.

## What prototype should you use to test it?

Match the prototype to the assumption, and pick the cheapest one that could fail. Higham's closing question is the filter: "Is this the smallest thing we can do to test our riskiest assumption?"

| Prototype type | What it tests well | Relative cost | What it cannot tell you |
|---|---|---|---|
| Paper sketch or whiteboard flow | Whether the concept makes sense to someone in 30 seconds | Hours | Whether anyone would use or pay for it |
| Clickable low-fidelity prototype | Whether people can find their way through a flow | A day or two | Demand; people click through what you put in front of them |
| Explainer video or fake landing page | Whether people want the outcome enough to sign up | A few days | Retention, real usage, willingness to pay unless you ask for money |
| Wizard of Oz (a person does the work behind a real-looking front end) | Whether people use the service when it looks real | Days to weeks of manual effort | Whether you can automate it at a sane cost |
| AI-generated high-fidelity prototype | Comprehension and usability of a detailed flow | Hours to a day | Demand; polish makes people more agreeable, not more honest |
| Engineering spike | Whether it can be built within real constraints | Days | Whether anyone wants it |

For the gym team, a clickable prototype would be the wrong call: it tests whether members can book a call, not whether they will turn their camera on while lifting. A Wizard of Oz test fits better. Put a "Book a form check" button in the existing app for a small group of members, have two trainers take the calls on an ordinary video tool, and count who books and who shows up on camera. No new video feature gets built unless the pass line is met.

If the riskiest assumption were feasibility instead (can a trainer see enough from a phone on the floor?), the right test would be a trainer and three colleagues filming lifts in the gym on a Tuesday afternoon, not a member-facing prototype at all.

## How do you read the result?

Compare it to the pass line you wrote in step 5, and decide before you look at anything else. Three outcomes are possible:

- **It passed.** Move the assumption into the evidence column and go back to step 3; the next riskiest assumption is now your test.
- **It failed.** Ask whether the assumption was wrong or the test was. If the invitation email went to spam, you tested your email, not your members. If the test was sound, the idea needs to change before anything is built.
- **It was ambiguous.** Usually a sign that the pass line was vague or that you tested two assumptions at once. Rewrite the test, not the result.

Keep the result, the pass line and what you decided in one place. A year later, the list of assumptions you tested and what they showed is more useful than any prototype you built along the way.

## When is a riskiest assumption test the wrong tool?

When the cost of being wrong is small and the cost of testing is not. If a change is cheap to build and easy to roll back, shipping it to a small share of users is itself the test, and running a separate prototype first only adds time.

It is also a poor fit where you cannot fake the experience safely. A Wizard of Oz test for a medication reminder or a financial transfer puts real people at risk if the person behind the curtain makes a mistake. In regulated or safety-critical work, the riskiest assumption may have to be tested with experts, simulations or a limited pilot instead of a mock-up.

## How do you get better at choosing what to prototype?

Run the five steps on the next feature your team is about to build, before anyone opens a design tool. The exercise fits in a single meeting, and a common result is discovering that the team was about to prototype the assumption it was already sure of. For choosing and using AI tools once you know what to test, see [AI-assisted prototyping](https://builderscamp.com/guides/glossary/ai-assisted-prototyping); for testing a whole business idea rather than one feature, see [how to validate a startup idea](https://builderscamp.com/guides/other/how-to-validate-a-startup-idea).

The [Prototyping for Product Managers](https://builderscamp.com/bootcamps/prototyping-for-product-managers) bootcamp is a 1-week programme in the Discovery Expert Track, directed by [Andre Albuquerque](https://builderscamp.com/guides/profiles/andre-albuquerque). Its public curriculum starts with what to prototype and why, choosing the right questions and the right prototype type for each stage, and continues through user flows, low-fidelity and clickable prototypes, testing, and turning what you learned into a build plan. Its [practical challenge](https://builderscamp.com/guides/challenges/prototyping-for-product-managers-design-review-critique) has you review a flawed prototype the night before engineering handoff.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Prototyping for Product Managers bootcamp](https://builderscamp.com/bootcamps/prototyping-for-product-managers?utm_source=guide&utm_medium=organic&utm_campaign=riskiest-assumption-test) for the next cohort and the self-paced version.

## Frequently asked questions

### What is a riskiest assumption test?

A riskiest assumption test (RAT) is the smallest experiment that checks the one belief your idea depends on most and has the least evidence for. Product manager Rik Higham argued for it in a 2016 post as an alternative to building an MVP first.

### How is a riskiest assumption test different from an MVP?

An MVP is a small product; a RAT is a test with no obligation to become a product. A RAT can be a paper sketch, a landing page or a person doing the work by hand, as long as it could prove your riskiest assumption wrong.

### How do you find your riskiest assumption?

Write the problem in one sentence, list every assumption under desirability, viability and feasibility, then rate each on how badly the idea breaks if it is wrong and how much evidence you already have. The riskiest assumption is the one with the highest impact and the least evidence.

### Which prototype should you use to test an assumption?

The cheapest one that could fail the test. Desirability questions often need only a landing page or explainer video; usability questions need a clickable prototype; willingness to pay needs a real price and a real payment step; feasibility needs an engineering spike.

### What is a Wizard of Oz prototype?

A prototype where the user sees what looks like a working product while a person does the work behind the scenes. It tests whether people want the outcome before you build the automation that delivers it.

### How many assumptions should you test at once?

One per test. Testing several at once makes a failed result impossible to read, because you cannot tell which assumption broke. Run the next test after you have an answer to the first.

### Can an AI-generated prototype be a riskiest assumption test?

Yes, if the assumption is about whether users understand or can use a flow. It is a poor choice for testing demand or willingness to pay, because a polished interface can make people say yes to something they would never buy.

## Sources

- [Rik Higham, Hacker Noon: The MVP is dead. Long live the RAT.](https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02)
- [Mixergy: Drew Houston interview with Andrew Warner](https://mixergy.com/interviews/drew-houston-dropbox-interview/)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.