- Every startup rests on assumptions. The job is to test the riskiest one, the belief that matters most and rests on the least evidence, before you spend money building around it.
- Assumptions fall into three questions: desirability (will they want it), viability (does the money work) and feasibility (can you build and run it). Each has its own experiments.
- Desirability: problem interviews when you have almost no evidence, a fake-door test once you want to measure real demand.
- Viability: a pre-sale or letter of intent for the hardest evidence, a pricing test to find the number the market bears.
- Feasibility: a one-week technical spike to prove you can build the hard part, a Wizard-of-Oz test to prove the experience before you automate it.
- Pick the cheapest experiment that could change your mind. If a result would not change what you do next, it is not worth running.
Most founders test an idea by building it, launching it, and hoping. It is the most expensive way to learn, and by the time the market answers, the money is gone. There is a cheaper way. Every startup is a stack of things you believe but have not proven: that people have the problem, that they will pay, that you can build the thing and run it. One of those beliefs, if it turns out to be wrong, takes the whole company down with it. That is your riskiest assumption, and the entire game early on is to find it and test it for as little money as possible.
The good news is that you rarely need to build anything to get an answer. A handful of well-worn experiments will tell you what you need to know in days, not quarters, if you know which one to reach for. They sort neatly into the three questions every new idea has to answer, and this guide walks through all six: what each one actually is, when it is the right tool, what it buys you, where it lets you down, and a worked example so you can picture running it on Monday.
A quick note on how to read the grid. The left column is for assumptions you have almost no evidence for, where you need to learn something fundamental. The right column is for when you already believe the basics and want to measure or quantify. Work out your riskiest assumption first, tag it as desirability, viability or feasibility, and the experiment more or less picks itself.
Desirability: will they actually want it?
Desirability is the question of whether anyone genuinely has the problem you are solving, and whether your solution is one they would reach for. It is the assumption founders are most likely to skip and most likely to be wrong about, because it is the easiest to convince yourself of on your own. These two experiments make the market answer instead of you.
01Problem interviewsDesirability
What it is
A handful of structured conversations with people in your target market about the problem, before you so much as mention your solution. The discipline that makes them work is simple: you ask about their life and their past behaviour, not about your idea. Done well, they tell you whether the problem is real, frequent and painful enough that anyone would pay to make it go away.
When to use it
At the very start, when your riskiest assumption is a desirability one and you have next to no evidence that the problem exists outside your own head. This is the first experiment most ideas should face, and the cheapest.
What it gets you
A fast, honest read on whether the problem stings, in the customer's own words. You come away with the language they use, the workarounds they already pay for, and a feel for how often the problem bites. That vocabulary alone is worth the exercise, because it is what your landing page and your pitch will later be built from.
Pros
- Almost free, and you can start today
- Kills a bad idea in days, not months
- Surfaces the customer's real language and workarounds
- Deep, qualitative understanding you cannot get from data
Cons
- Small samples, easy to over-read
- People are polite and will tell you what you want to hear
- Leading questions quietly bias the result
- Proves interest in the problem, not willingness to pay
In practice
A founder building for operations managers books five twenty-minute calls. She never pitches. She asks about the last time the problem bit, how they handle it now, and what that costs them. Three of the five describe an elaborate spreadsheet workaround and one has quietly hired a contractor to deal with it. That is a real, expensive problem. If instead they had shrugged and said it was a minor annoyance, she would have saved herself a year of building the wrong thing.
02Fake-door testDesirability
What it is
You advertise the thing as if it already exists, a landing page, a pricing button, an ad, and measure how many people try to get it. When they click to buy or sign up, you tell them honestly that it is coming soon and offer to keep them posted. You are buying a number: real intent, counted, before a line of product code is written.
When to use it
Once you have some reason to believe the problem is real and you want to measure demand at scale, or compare how different value propositions land. It turns the qualitative signal from interviews into something you can count.
What it gets you
Real behaviour rather than stated intent, at a volume interviews can never reach. Because you can run variants, it also tells you which framing of the value proposition actually pulls, which is often more useful than the raw demand number.
Pros
- Cheap and quick to stand up
- Counts real intent: clicks, emails, "buy now"
- Lets you A/B different value props and prices
- Scales far beyond what interviews can reach
Cons
- Measures intent, not actual payment
- A dead-end can annoy people, so handle it gracefully
- Needs enough traffic, which often means ad spend
- Clicks can flatter you if the ad oversells
In practice
A team puts up a one-page site for a feature that does not exist yet, with a clear "Get early access" button, and spends a hundred pounds driving traffic to it. Eight percent of visitors leave an email, against a rule-of-thumb baseline nearer one percent. That is a strong pull, and enough to justify building. Had almost nobody clicked, they would have learned the same thing for a hundred pounds instead of a hundred thousand.
Viability: does the money actually work?
Viability is the question of whether the numbers add up: whether people will pay enough, often enough, through a channel you can afford, for the business to make money. An idea can be wildly desirable and still not be a business. These two experiments put the money question to the test before you have built the thing you are trying to sell.
03Pre-sale or letter of intentViability
What it is
You ask for a commitment before the product is finished. In consumer businesses that means a pre-order or a deposit, real money for something that does not exist yet. In business-to-business it means a signed letter of intent: a written, non-binding commitment to buy at a stated price once you deliver. Either way you are asking the question that matters most, at your real price, and watching what people do rather than what they say.
When to use it
When viability is your riskiest assumption and you have little hard evidence that anyone will actually pay what you need to charge. It is the strongest signal you can get short of live revenue.
What it gets you
The hardest evidence there is, because a person parting with money, or a company putting a commitment in writing, has skin in the game that a survey never will. It forces a real price conversation, it qualifies the genuinely serious buyers, and a pre-sale can even fund the build.
Pros
- Money and signatures are the hardest evidence of demand
- Forces an honest conversation about price
- Can pre-fund development
- Turns your first believers into design partners
Cons
- Hard to get, which is precisely the point
- Letters of intent are non-binding and can fall through
- Usually needs a credible prototype to point at
- A no can be about timing rather than desire
In practice
A B2B founder takes a clickable prototype to five target accounts and asks each to sign a letter of intent at two thousand pounds a month, conditional on delivery by the third quarter. Two sign. That is not just a viability signal, it is two design partners and a reason to build with confidence. The three who declined tell him something too: one was a budget-timing no, two simply did not feel the pain enough, which is worth knowing now.
04Pricing testViability
What it is
You put a real price in front of real buyers and measure the drop-off. That can be pricing-page variants that stop just before payment, an ad-to-checkout flow, or a structured survey that probes what people would expect to pay and at what point it feels too expensive. The aim is to find the price the market will bear, and to check that it is a price your business can actually live on.
When to use it
When you already have some evidence of demand and the open question is the number itself: what to charge, how sensitive buyers are, and whether the price you need is the price they will accept.
What it gets you
A read on willingness to pay and price sensitivity for very little money, and one that feeds straight into the rest of your model. Your price sets your unit economics, so getting it roughly right early de-risks the number the whole business rests on.
Pros
- Quantitative, and cheap to run
- Lets you compare several price points
- Informs the whole model: CAC, LTV, payback
- De-risks the single number the business depends on
Cons
- Stated willingness to pay overstates the real thing
- Needs traffic to reach a reliable answer
- Anchoring and framing can skew results
- Shows they would consider paying, not that they will
In practice
A founder runs three versions of the pricing page at twenty-nine, forty-nine and seventy-nine pounds a month and measures how many reach checkout. The forty-nine holds nearly the same conversion as the twenty-nine while almost doubling revenue per signup, and the seventy-nine falls off a cliff. Forty-nine it is, and the model gets rebuilt on a number that came from buyers rather than a spreadsheet. Feed that into the Unit Economics calculator and you can see whether the whole thing pays.
Feasibility: can you build it and run it?
Feasibility is the quietest of the three questions and the one that sinks companies late, when the money is already spent. It has two halves: can you build the hard part at all, and can you run the thing reliably once it is built. These two experiments answer those halves without committing to the full engineering bill.
05One-week technical spikeFeasibility
What it is
A time-boxed, deliberately throwaway build of the single hardest technical unknown in your idea. Not a feature, not a foundation, a proof. You give one engineer a fixed window, usually a week, to answer one question: can this actually be done? The code is meant to be binned. What you keep is the answer.
When to use it
When feasibility is your riskiest assumption and there is a specific technical thing you are not sure is possible, or possible at the quality or speed you need. Run it before you build anything around that unknown.
What it gets you
It turns "we think we can build it" into a fact, one way or the other. It surfaces the real blockers early, while they are cheap to hit, and it buys that knowledge for a week of one person's time instead of a quarter of a team's.
Pros
- Time-boxed, so the cost is contained
- Produces a clear yes or no
- Throwaway code means no over-engineering
- De-risks the scariest technical unknown first
Cons
- Costs real engineering time
- Working in a week is not the same as production-ready at scale
- Tempting to keep and build on the throwaway code
- Answers "can it be built", not "should it be"
In practice
A team is unsure whether their machine-learning classifier can hit the accuracy the product needs. Rather than architect a whole pipeline on faith, one engineer spends a week building a rough model against real data. It lands at eighty-two percent, comfortably above the threshold, so they proceed knowing the core is sound. Had it come in at fifty-five, they would have rethought the approach before betting the roadmap on it.
06Wizard-of-Oz testFeasibility
What it is
You deliver the full experience to real users while a human quietly does, by hand, the work the product will eventually automate. The user believes it is all software. Behind the curtain, it is you. The name comes from the man behind the curtain in Oz, and the point is to prove that the experience works and is wanted before you spend months building the machine to deliver it.
When to use it
When the expensive part is the automation, and you want to prove the value and learn the workflow first. It answers feasibility in the "can we run this" sense, and doubles as a strong desirability test, because people are using the real thing.
What it gets you
Proof that the end-to-end experience delivers, and a detailed map of what actually needs automating, all for a fraction of the upfront cost. You discover the edge cases by living them, so when you do build, you build the right thing.
Pros
- Validates the whole experience for little upfront cost
- Flexible: you can change the manual process day to day
- Teaches you the edge cases before you code them
- Often doubles as a desirability test
Cons
- Does not prove the automation itself is feasible
- Labour-intensive and will not scale as-is
- Risk of overpromising what the product can do
- Be honest about data handling; do not mislead
In practice
A "smart" meal-planning app launches, and every plan that feels algorithmic is in fact hand-built overnight by a nutritionist. Users love it, renew, and tell their friends. Now the team knows exactly which parts of that manual craft are worth automating and which are not, and they build from evidence rather than guesswork. If users had been lukewarm, they would have saved a year of machine-learning work they never needed to start.
How to choose, and when to stop.
The trap is running experiments for the comfort of activity. The discipline is to run the one that could change your mind. Start from your single riskiest assumption, the belief that matters most and rests on the least evidence. Name which of the three questions it belongs to, then reach for the experiment on the appropriate side of that row: the foundational one when you know little, the measuring one when you know some. Run it, look at the result honestly, and only then move to the next assumption down the list.
One more rule worth holding onto. Before you run anything, ask what you would do differently if the result came back positive versus negative. If the honest answer is the same either way, the experiment is theatre, and you should skip it and build. Good experiments are not the ones that make you feel busy. They are the ones whose result you cannot predict and cannot ignore.