How to Test Your Product Assumptions (Riskiest First)
Every solution rests on assumptions — and the risky, unchecked ones are where projects quietly die. Here’s how to surface them, map them by importance and evidence, and test the riskiest cheaply, before you’ve built the wrong thing.
Why assumptions are where projects die
When a feature ships and nobody uses it, the problem usually isn’t the code — it’s a belief that was never checked. “Users will want this.” “They’ll understand the flow.” “Sales can position it.” Each is an assumption, and any one of them being wrong can sink the work.
Assumption testing flips the order: surface the beliefs first, find the riskiest, and run a small test before committing. Finding and checking that one belief is the riskiest assumption test — the engine of continuous discovery, and the bottom layer of every Opportunity Solution Tree.
Four types of assumptions
Naming the type points you at the right kind of test.
Do customers actually want this? Will it solve a problem they care about? The most common reason products fail.
Test with: Interviews, fake-door tests, landing pages
Can people figure out how to use it? Does the flow make sense without someone explaining it?
Test with: Prototype tests, usability sessions
Can we actually build and run it, with our team, tech, and constraints?
Test with: Technical spikes, throwaway prototypes
Should we build it — does it work for the business (cost, pricing, model, legal)?
Test with: Pricing tests, business-model math
Map by importance × evidence
Plot each assumption on two axes — how important it is (does the idea collapse if it’s wrong?) and how much evidence you already have. One corner matters most:
Your leap-of-faith assumptions. Test these first.
Safe-ish to build on — keep an eye on it.
Don’t waste a test here yet.
Ignore — move on.
Test the riskiest assumption with the smallest experiment that gives a clear signal — and decide the success criterion before you run it, so you can’t rationalize the result afterward.
A reusable assumption test template
Copy this card for each assumption you decide to test.
- Assumption
- We believe that busy admins will read a weekly activity digest.
- Type
- Desirability
- Importance
- High — the whole solution depends on it
- Evidence today
- Weak — one interview mentioned it
- Test
- Fake-door: add a “Weekly digest” toggle, measure opt-ins over 2 weeks
- Success criteria
- ≥ 20% of active admins opt in
- Result
- Validated / Invalidated / Inconclusive
Prefer paper?
Get the printable kit — this card as a fillable one-pager, plus the assumption inventory and the importance × evidence grid. No email required.
Assumptions as first-class nodes
In an Opportunity Solution Tree, assumptions hang off the solutions that depend on them. Outcomify makes them first-class:
- Add assumption nodes under any solution, each with a status: untested, validated, or invalidated.
- Attach the evidence from each test, so the result — not the opinion — drives the next decision.
- Canopy can suggest the assumptions hiding under a solution — drafts you review, never silent writes.
Frequently Asked Questions
Common questions about assumption testing and mapping
Keep exploring
Product Experiments
The how: 10 experiments — fake door, concierge, spike — with when to use each and what a clear signal looks like.
Riskiest Assumption Examples
16 real assumptions by type — each with the smallest test and a success criterion.
Riskiest Assumption Test vs MVP
Why the cheap experiment comes before the small product — and when it doesn’t.
What is an Opportunity Solution Tree?
Assumptions are the bottom layer — see how the whole tree fits together.
Test the risky beliefs before you build
Outcomify makes assumptions first-class nodes on your tree — mapped, tested, and tracked as validated or invalidated, with the evidence attached.