Riskiest assumption test: one belief to falsify first
Riskiest assumption test
A riskiest assumption test is the habit of naming the one belief that would make your plan pointless if it were false, then running the cheapest experiment that could prove you wrong before you commit to code, hires, or a long roadmap. You are not testing «everything at once». You are sequencing tests so the next month of work rests on evidence, not hope.
This is for founders and innovation leads in Switzerland who already have a direction but several open questions: who hurts, whether they will pay, whether you can reach them, whether regulation blocks the model. For the wider menu of landing pages, concierge tests, interviews, and pre-sales, see how to validate a startup idea. Here the focus is how to choose which assumption to test first and how to know when one round is enough.
- Assumption
- One sentence you could falsify, for example who has the job, how painful it is, or whether they will change behaviour for your offer.
- Riskiest assumption
- The belief with the highest combination of uncertainty and consequence if it is wrong.
- Falsifier
- What you would need to observe to stop or reshape the idea, written before you run the test.
- Experiment
- A short, bounded action that produces behaviour or commitments, not another slide deck.
How to run a riskiest assumption test
Treat the work as a loop you can finish in days or a couple of weeks, not a quarter-long research project.
Write every assumption that must hold
Problem, segment, willingness to pay, channel, regulation, technical feasibility, and timing. One line each. Vague lines are still at idea stage.
Mark uncertainty and consequence
High uncertainty plus high consequence if wrong beats a guess you are already sure about. «People might like this» is rarely the riskiest row.
Pick one riskiest assumption
If only one can be tested this month, choose the row that would kill the business model or the segment choice if it failed.
Design the smallest falsifying test
Match the method to the claim: past behaviour interviews for problem depth, a high-friction landing action for demand, a manual delivery for outcome value. Write the falsifier before you launch.
Run it, then re-rank
Pass or fail against your written rule, not against enthusiasm. The next riskiest assumption may be different once the first row is settled.
Which assumption is usually «riskiest»
Founders often start with features. The riskiest row is more often about who feels the pain, whether they already spend on a workaround, or whether you can reach them without a channel you do not have. Pricing and polish are rarely the first kill switch if nobody has the job yet.
If problem depth is still unknown, problem validation before building belongs before solution tests. If the open question is how to ask without biasing answers, use customer interview questions that stay on past behaviour. A riskiest assumption test does not replace those guides; it tells you which guide to open first.
Test the belief that would end the plan, not the belief that flatters the plan.
What a riskiest assumption test does not prove
One clean falsification or confirmation only covers that row. It does not show product-market fit, safe unit economics, scalable acquisition, or that a team can operate the service for years. It does not protect the idea as such: under Swiss practice, ideas cannot be protected on their own; execution and branding can (IGE overview on ideas).
Passing a cheap test also does not oblige you to build the full vision. It only means the next riskiest assumption deserves the next experiment, or that a build conversation is less reckless than it was last week.
A made-up example: two assumptions, one month
A made-up example: a founder wants a B2B tool that turns supplier email threads into structured delivery notes for office managers in German-speaking Switzerland. They list six assumptions. The riskiest row is not «managers want AI summaries» but «managers are allowed to forward supplier mail into a third-party tool without breaching their employer’s rules». Uncertainty is high; consequence is a dead product. The falsifier is «three managers in target-sized firms say their IT or procurement policy forbids external tools on supplier mail, with no workaround». They run five short interviews that never mention their product, only current process and policy. Four say forwarding to unknown SaaS is blocked or needs IT approval that takes months. The founder stops the build path and reframes to an on-premise or Microsoft-365-only angle, which opens a new riskiest assumption about integration cost. One month, no repo.
Who should run it, and who should skip
Who this is for
- Founders with a written list of beliefs and a build or hire decision in the next quarter
- Innovation leads who need a board slide that names one test, not ten parallel pilots
- Teams stuck debating features while the segment or channel is still a guess
Who should skip or shorten it
- Products with paying users and repeat usage; the riskiest row is usually retention or ops, not discovery
- Mandated internal tools where the sponsor and users are fixed
- Founders who refuse a written falsifier; the test will only collect reassurance
Is a riskiest assumption test the same as an MVP?
No. It is the rule for ordering tests. An MVP is one kind of experiment, usually after problem and segment rows look credible. You can run several assumption tests without shipping code.
How many assumptions should you test at once?
One riskiest row per cycle keeps causality clear. Parallel tests are fine only when they target independent rows and you can read results separately.
When the Product Validation Package fits
The Product Validation Package fits when the current riskiest assumption needs a deployed product, paid acquisition, and measured behaviour, not when the first honest interviews would still change the segment. Weeks 1 to 4 put a real app in users’ hands; later weeks test whether usage matches the assumption you chose. If you are still ranking assumptions on paper, stay in discovery before you book a build conversation on the contact page.
Written by
Aurum Avis Labs
Builds and ships at Aurum Avis Labs. Writes here about what we learn working with founders and SMEs in the DACH region.
Related Articles
You might also be interested in these articles
Customer interview questions: the Mom Test, for founders
Mom Test customer interview questions: ask about past behaviour, not your pitch. A question bank, limits, and who should skip interviews.
Problem validation before building: a practical sequence
Problem validation before building tests whether a real group feels enough pain to act, before you ship code. Steps, limits, and what it does not prove.