How to Identify the Riskiest Assumptions in Your Startup Idea
Learn how to list the assumptions behind a startup idea, sort them into desirability, feasibility and viability, and test the riskiest one cheaply first.
On this page
Every startup idea is a stack of beliefs. You believe a certain kind of person has a certain problem, that they will notice your solution, that you can build it, and that they will pay enough to keep the lights on. Some are probably true. A few are probably not. The trouble is that from the inside, they all feel equally obvious.
This guide shows you how to pull those beliefs out into the open, decide which ones carry the most risk, and design small, inexpensive experiments to check them before you commit serious time or money. You will finish with a short, ranked list of what to test first and a concrete way to test it.
What a business assumption actually is
An assumption is anything your plan needs to be true that you have not yet confirmed with evidence. “Freelance designers struggle to get paid on time” is an assumption until you have heard it from freelance designers, in their own words, without prompting. “We can build the first version in six weeks” is an assumption until someone who has built something similar agrees.
A useful test: if a sentence starts with “Obviously…” or “Everyone knows…”, you are probably looking at an assumption.
Write each assumption as a testable statement. “People want better invoicing” is too vague to check. “Freelance designers who bill more than five clients a month spend at least an hour a week chasing late payments” can be checked with a handful of conversations.
Desirability, feasibility and viability
Sorting assumptions into three groups helps you see where your blind spots are. It is easy to be comfortable in one group and quietly skip the other two.
| Type | The question it answers | Typical assumptions |
|---|---|---|
| Desirability | Do people want this? | The problem exists, it is painful enough to act on, the target customer is reachable, they prefer your approach to what they do today |
| Feasibility | Can we deliver it? | You can build or source it, at the needed quality, on the timeline you planned, with the skills and partners you have |
| Viability | Does it work as a business? | Customers will pay a price that covers your costs, acquiring them costs less than they are worth, they stay or come back |
Developers often have pages of feasibility notes and one line about desirability; salespeople often the reverse. Fill in all three columns before you rank anything.
Why some assumptions matter more than others
Not every unproven belief deserves a test. An assumption is risky when two things are both true:
- It is critical. If it turns out to be false, the idea breaks or needs a major rework, not just a tweak.
- It is uncertain. You have little or no real evidence for it, only reasoning, enthusiasm or a few friendly opinions.
“Customers will like our logo” is uncertain but not critical. “Our supplier can deliver in two weeks” may be critical but already confirmed in writing. Neither belongs at the top. What does belong there is anything you would hate to discover was wrong after months of building.
A common trap is testing what is easy instead of what is risky. Polishing a prototype feels productive, but it tests feasibility you were already confident about, while the scary question, whether anyone will pay, sits untouched.
How to prioritize uncertainty
Once you have a list, rank it with a simple two-axis exercise:
- Score each assumption for impact. Ask: if this is false, what happens? Use a rough scale: the idea dies, the idea needs a major pivot, or the idea needs adjustment.
- Score each assumption for evidence. Ask: what have I actually observed? Use: nothing but my own belief, a few opinions, or real behavior such as payments, sign-ups or repeated use.
- Pick the top one or two. High impact plus weak evidence goes first. Everything else waits.
- Look for dependencies. Some assumptions only matter if another one is true. There is no point testing whether customers prefer annual billing if you have not confirmed they want the product at all. Test upstream assumptions first.
As a rule of thumb, work on one or two assumptions at a time. Testing ten at once usually means testing none properly.
How to design inexpensive validation experiments
A good experiment is small, fast, and has a pass or fail line you write down before you start. Use this four-part template:
- Assumption: the exact statement you are testing.
- Experiment: the cheapest action that would produce real evidence about it.
- Success signal: what you need to see, written in advance, so you cannot reinterpret the result later.
- Decision: what you will do if it passes, and what you will do if it fails.
The cheapest experiments usually look like one of these:
- Problem interviews about past behavior: what people did the last time they faced the problem, and what it cost them. See how to write customer discovery questions for questions that avoid flattering answers.
- A simple landing page that describes the offer and asks for an email, a booking or a deposit.
- A manual “behind the scenes” version where you deliver the result by hand before automating anything.
- A quote or sourcing request to suppliers or contractors to check costs and timelines.
- A pre-sale or deposit, which is the strongest early signal for viability because it involves real money.
Opinions are the weakest signal. “That sounds great” costs nothing to say; an email costs a little, a booking more, and a payment the most, so it tells you the most.
Examples across three kinds of business
A SaaS idea
Imagine a tool that automatically reminds a freelancer’s clients about overdue invoices.
- Desirability: freelancers chase late payments often enough to want help, and they are comfortable letting software contact their clients.
- Feasibility: you can connect to the invoicing tools they already use.
- Viability: they will pay a monthly fee rather than sending reminders themselves.
The riskiest assumption is probably the second half of desirability: many freelancers worry about damaging client relationships. A cheap test is ten short interviews asking how they currently handle late payers and what they would never want a tool to say. If most say they would only send reminders personally, the idea needs a different shape before any code is written. For more SaaS-specific steps, see how to validate a SaaS idea.
A service business
Say you want to offer weekly dog walking for busy professionals in your neighborhood.
- Desirability: enough local professionals want a regular walker, not just an occasional favor from a neighbor.
- Feasibility: you can walk dogs for a dozen households within the hours you have, with keys and schedules handled safely.
- Viability: the price customers accept covers your time between walks, not just the walks themselves.
Here viability is the likely weak spot, because travel time between homes quietly eats into every hour. A good experiment is to walk for three paying households for two weeks at your intended price and track every hour, including the time spent getting from one door to the next.
A physical product
Picture a collapsible water bowl that clips onto a dog leash.
- Desirability: dog owners actually forget water on walks and see this as the fix.
- Feasibility: a manufacturer can make it durable and light at your target cost.
- Viability: the retail price leaves room for margin after shipping and returns.
Feasibility and cost are critical here because inventory is expensive. Before ordering stock, request quotes and a sample from two or three manufacturers, and run a preorder page to see whether anyone commits money. If quotes come back too high for a sensible retail price, you have saved yourself a warehouse of unsold stock.
Using AI as a first pass, not a verdict
AI tools are good at one part of this process: spotting assumptions you missed because you are too close to the idea. The free checker above lists key assumptions, labels how critical each looks and suggests one practical test. Treat that as a draft to argue with, not evidence. Only real customers, suppliers and payments can confirm or kill an assumption.
If you want a broader early read on how different types of people might react to the concept, you can also explore it with AI-simulated audiences. Those reactions are simulated, not real demand, so use them to decide which assumptions to test with real people, not to skip the test.
Your next step
Write down every belief your idea depends on, sort them into desirability, feasibility and viability, and circle the one that is both critical and unproven. Then design a single experiment for it with a success signal you write down today. Run it this week. If it passes, move to the next assumption. If it fails, you just learned something that would have cost far more to learn later.
Written by the SellTo.us Team. Examples in this article are hypothetical. SellTo.us results come from AI-simulated participants, not real people, and don’t predict sales or guarantee success.
Related articles
How to Roast Your Startup Idea Before Spending Money
A practical way to pick apart your own business idea before you commit savings, time or a team to it, and to turn every weakness you find into a small experiment.
How to Test a Business Idea Before You Build It
Building is the slowest and most expensive way to learn whether an idea works. This method helps you collect real evidence first, one cheap step at a time.
How to Write Customer Discovery Questions That Reveal Real Problems
The wrong questions get you compliments; the right ones get you facts about how people really handle a problem. Here is how to write them, with five examples you can adapt.