Assumption Testing: Find and Test Your Riskiest Assumptions

Why good ideas still fail

Most product ideas don't fail because the team built them badly. They fail because something the team took for granted wasn't true. Customers didn't have the problem. They had it, but not badly enough to change their behavior. They wanted the solution, but couldn't figure out how to use it. Or it worked, but cost more to run than it earned.

Assumption testing is how you find those weak spots before you spend months building. Instead of testing a whole idea at once, you break it into the beliefs it depends on and test the riskiest ones first.

Why test assumptions instead of whole ideas?

The traditional way to validate an idea is to build a version of it and see what happens. That works, but it is slow and expensive, and when the result disappoints, it is hard to tell why. Was it the wrong problem, the wrong design, or the wrong audience?

Testing assumptions one at a time solves both problems. Each test is small enough to run in days, and each result tells you something specific. If the test of a desirability assumption fails, you know the issue is demand, not the interface. And because assumptions are often shared between ideas, a single test can tell you something about several solutions at once.

Five types of assumptions

Teresa Torres groups assumptions into five types in Continuous Discovery Habits. Walking through each one is a reliable way to make sure you don't miss a category of risk:

Desirability: do customers want this, and will they choose it over what they do today?
Viability: does it work for the business: can we sell, support and sustain it?
Feasibility: can we build it with the time, technology and skills we have?
Usability: will customers understand it and be able to use it?
Ethical: could it cause harm, and would we be comfortable if everyone knew how it works?

Teams naturally gravitate to the assumptions they are most comfortable with. Engineers think about feasibility, designers about usability, product managers about desirability. Going through all five types as a team balances those blind spots.

How to surface assumptions

Assumptions are hard to see because they feel like facts. A few techniques help:

Story map the solution: walk through every step a user takes and ask what has to be true at each one
Run a pre-mortem: imagine the solution launched and failed, then list the reasons it might have
Question each layer of the tree: does this solution really address the opportunity, and does the opportunity really drive the outcome?

Story mapping is especially effective. Lay out the steps a user takes from discovering the feature to getting value from it. At each step, ask: what must the user know, want and be able to do here? What must our systems do? Each answer is an assumption. Our guide to user story mapping explains how to build that map.

Write assumptions you can prove wrong

Write each assumption as a specific, falsifiable statement. "Users will like the reminder" is too vague. "At least 30% of users who receive the Sunday reminder will plan their week within an hour" can be proven wrong, which is exactly what makes it useful.

A few rules of thumb:

Name the customer: which users, in which situation?
Name the behavior: what will they do, not what will they think or feel?
Name the threshold: what result would make you believe it?

If you can't imagine a result that would prove the assumption false, rewrite it until you can.

Prioritize: importance and evidence

You can't test everything, and you don't need to. Plot each assumption on two dimensions:

Importance: if this turned out to be false, would the solution fail?
Evidence: how much do we already know, from data, research or past experiments?

Your riskiest assumptions are the ones that are important and have little evidence. Test those first. Assumptions that are unimportant, or already well supported, can wait.

Be honest about evidence. "The sales team says customers ask for it" is weak evidence; "12 of the last 15 interviewees described this problem unprompted" is stronger. Opinions, including senior opinions, are not evidence.

Design small experiments

A good assumption test is small, fast and cheap. It tests one assumption, not the whole idea. Common types:

One-question survey: ask a single, targeted question in the product to check how common a behavior is
Fake door test: show an entry point to a feature that doesn't exist yet and measure how many people try it
Prototype test: watch five to ten customers try a clickable prototype and note where they struggle
Data mining: look at what customers already do in your product for evidence for or against the assumption
Concierge test: deliver the value manually to a handful of customers before automating anything
Technical spike: build a throwaway proof of concept to check a feasibility assumption

Choose the cheapest experiment that could change your mind. If a one-day data query can answer the question, don't run a two-week pilot.

Matching experiments to assumption types

Some experiments fit some assumption types better than others:

Desirability: fake door tests, one-question surveys, concierge tests
Usability: prototype tests with real customers
Feasibility: technical spikes and conversations with engineers who know the system
Viability: conversations with sales, support, legal and finance, and simple cost models
Ethical: reviews with people outside the team, and asking how the feature could be misused

Define success criteria before you start

Decide what result would count as a pass before you run the experiment. "At least 30% plan within an hour" is a success criterion; "we'll see what happens" is not. Writing it down first protects you from reading what you want into the results.

Also decide who you will test with and for how long. A test with the wrong audience, or one that stops as soon as the numbers look good, produces confident answers that are wrong.

When the experiment ends, record what you observed and what you learned. Then make a decision: keep going, change the solution, or drop it and try another one.

A worked example

A meal-planning team wants to send a Sunday reminder to help users plan their week. Their assumptions include:

Users want help remembering to plan (desirability)
Users who get the reminder will plan within an hour (desirability)
A weekly push notification won't cause users to turn notifications off (usability)
The reminder can use the existing notification service (feasibility)
Sending one extra notification per user per week fits within the notification budget (viability)

The second assumption is the most important and has the least evidence, so they test it first. They send the reminder to 10% of users for two weeks, with the success criterion "at least 30% plan within an hour". The result: 18%. The idea isn't dead, but the team learns that a reminder alone isn't enough and tries pairing it with a one-tap "repeat last week" plan.

The feasibility assumption, meanwhile, needed no experiment: a short conversation with the engineer who owns the notification service confirmed it. Not every assumption needs a formal test.

Common mistakes in assumption testing

Testing the whole idea at once: a pilot of the full feature is slow and its results are hard to interpret
Testing only the comfortable assumptions: easy tests of low-risk assumptions feel productive but teach you little
No success criteria: without a threshold set in advance, every result looks like a success
Asking customers what they would do: people are poor predictors of their own behavior; observe what they do instead
Not acting on results: an experiment that doesn't change a decision was not worth running

Keep assumptions connected to your tree

Assumption tests are most valuable when they live next to the solutions and opportunities they belong to. In an Opportunity Solution Tree, each solution carries its assumptions and experiments, so everyone can see what has been validated and what is still a guess.

That connection also helps you measure what matters. Each experiment should ultimately help you move your product outcome; if a test can't influence that, ask whether it is the right test.

Frequently asked questions

How many assumptions should we test per solution?

Usually only a few. Surface many assumptions, but test the two or three that are both important and poorly supported. The rest can wait or be accepted as known risks.

How long should an assumption test take?

Days, not weeks. If a test would take longer than a couple of weeks, look for a smaller version that answers part of the question sooner.

What if a test fails?

That is a good result: you learned something important cheaply. Decide whether to change the solution, try a different solution under the same opportunity, or revisit the opportunity itself.

Product Planner lets you add assumptions with their category, importance and evidence under each solution, design experiments with success criteria, and record what you learned. When a solution is validated, you can take it straight into a user story map. Start free and test your riskiest assumption this week.