Riskiest Assumption Examples
16 real-world assumptions across the four types — each phrased as a testable belief, with the smallest test that would settle it and a success criterion decided up front.
A warning before the list: your riskiest assumption can’t be copied from a website — “riskiest” is a property of your evidence, not of the assumption. Use these examples to calibrate what a sharp, testable belief looks like, then map your own by impact × evidence (or grab the printable kit and do it on paper in half an hour).
Desirability — Do customers actually want this?
The most common killer. Teams rarely doubt demand out loud — it feels disloyal to the idea — so desirability assumptions go untested straight into the roadmap. If the whole bet collapses when nobody cares, this is your riskiest layer.
We believe busy team admins will read a weekly activity digest.
Smallest test: Fake-door: add a “Weekly digest” toggle in settings and measure opt-ins for two weeks.
Success criterion: ≥ 20% of active admins turn it on.
We believe freelancers will hand over invoice chasing to someone else.
Smallest test: Concierge: offer to chase invoices manually for 20 freelancers this month.
Success criterion: ≥ 5 say yes and actually send you an overdue invoice.
We believe shoppers will trust a size recommendation based on their past returns.
Smallest test: Fake-door “What’s my size?” button on the product page, with a one-question survey behind it.
Success criterion: ≥ 15% of viewers click, and survey answers name trust, not curiosity.
We believe developers will let an AI agent open pull requests in their repository.
Smallest test: Ten interviews where you ask them to connect a sandbox repo on the spot — not “would you?”, but “will you now?”.
Success criterion: ≥ 5 of 10 connect the repo in the session.
Usability — Can people figure out how to use it?
Rarely the riskiest at the idea stage — you can usually fix usability with iteration. It becomes the linchpin when the whole value depends on unaided self-serve: onboarding flows, imports, anything where a human helping defeats the point.
We believe non-technical marketers can build a three-step email journey without reading docs.
Smallest test: Prototype sessions with five marketers; no hints, think-aloud.
Success criterion: ≥ 4 of 5 complete it unaided in under ten minutes.
We believe drivers will complete proof-of-delivery photos one-handed at the door.
Smallest test: Field test with five drivers on real routes for one day.
Success criterion: ≥ 80% of deliveries photographed first try, no support calls.
We believe finance teams can map their own CSV columns without a support call.
Smallest test: Usability test with five real customer files — theirs, not your tidy sample.
Success criterion: ≥ 4 of 5 finish the mapping unaided.
We believe users will find export where we put it, inside the share menu.
Smallest test: First-click test on a static screenshot with ten users.
Success criterion: ≥ 8 of 10 first-click the share menu.
Feasibility — Can we build and run it, with our team and constraints?
The type engineers surface naturally — and the one type where the test is often a build. The discipline is timeboxing: a spike is a throwaway experiment with an end date, not the first sprint of the feature wearing a lab coat.
We believe we can return search results in under 300 ms at ten times today’s data volume.
Smallest test: Two-day spike: load a synthetic 10× corpus into a prototype index and benchmark.
Success criterion: p95 latency < 300 ms on realistic queries.
We believe the bank API delivers transactions within 24 hours of posting.
Smallest test: Pull real data for three pilot accounts for one week and measure the lag.
Success criterion: ≥ 95% of transactions visible within 24h — measured, not promised in the API docs.
We believe LLM summaries of support tickets are accurate enough to ship without human review.
Smallest test: Offline eval: summarize 100 historical tickets, have two support leads grade them blind.
Success criterion: ≤ 2% of summaries contain a harmful error (wrong customer, wrong promise, wrong status).
We believe a new tenant can be onboarded without a migration engineer in the loop.
Smallest test: Throwaway self-serve import prototype, run on two friendly customers’ real exports.
Success criterion: Both imports complete without an engineer touching the data.
Viability — Should we build it — does it work for the business?
The type founders test last and regret first. Price, margin, and cost-to-serve assumptions feel like “later problems” — until a validated, desirable, usable product turns out to be a bad business. Viability tests are mostly conversations and spreadsheets, which is exactly why skipping them is inexcusable.
We believe teams will accept per-seat pricing rather than a flat team price.
Smallest test: Quote per-seat in the next ten sales conversations and count the pushback.
Success criterion: ≥ 6 of 10 accept the framing without negotiating toward flat.
We believe we can acquire customers under $200 CAC with content alone, no paid spend.
Smallest test: Spreadsheet first (traffic × conversion × close rate), then one 90-day organic cohort.
Success criterion: The math closes at realistic conversion rates before you commit the quarter.
We believe restaurants will accept a 10% take rate.
Smallest test: Fifteen supply-side conversations with a real one-page agreement, not a hypothetical.
Success criterion: ≥ 8 sign a letter of intent at 10%.
We believe support load stays under one ticket per customer per month at self-serve pricing.
Smallest test: Measure the pilot cohort for a month and price the support minutes against the plan margin.
Success criterion: Support cost < 15% of plan revenue.
Writing your own
What the 16 above have in common — and what to copy when you write yours.
One belief per card
“Admins will find and love the digest” is two assumptions wearing a trench coat. Split it — each gets its own test.
Name a specific actor and behaviour
“We believe [who] will [do what]” is falsifiable. “Users want more engagement” is not — nothing observable could prove it wrong.
Write the success criterion first
Decide what “validated” means before the data arrives, or you will argue any result into a pass.
Prefer behaviour over opinion
Connecting a repo beats saying “sounds useful.” Every type has a behavioural version of its test — reach for it.
Find yours in 30 minutes
The printable kit walks you through the inventory, the impact × evidence grid, and a fillable test card. No email required.
Frequently Asked Questions
Common questions about riskiest assumptions
Keep exploring
How to Test Product Assumptions
The full method these examples come from: surface, map, and test riskiest-first.
Riskiest Assumption Test vs MVP
Why the cheap experiment comes before the small product — and when it doesn’t.
Product Experiments
The experiments behind these examples — how to run a fake door, concierge, spike and more.
Give every assumption a home and a status
In Outcomify, assumptions are first-class nodes under the solutions that depend on them — untested, validated, or invalidated, with the evidence attached.