How to Test Your Product Assumptions (Assumption Mapping)
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. It’s 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
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
What is an Opportunity Solution Tree?
Assumptions are the bottom layer — see how the whole tree fits together.
Customer Interviews to Opportunities
Where the opportunities (and many assumptions) come from in the first place.
Opportunity Discovery Workshop
Surface opportunities and the assumptions behind your solutions as a team.
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.