Guide
How to validate a product idea before you build it
Validation isn't a phase you pass through on the way to building. It's the habit of finding the cheapest way to be wrong — before the expensive way finds you.
Written from twenty-five years of building software, and from the uncomfortable number of times I've watched a good team build a product nobody had agreed to want.
In short
To validate a product idea before building it, write the idea as a testable belief about one specific customer, identify the single assumption that would kill it, then run the cheapest test that could disprove that assumption — ten problem conversations, a demand test, a manually delivered concierge version, or a small paid pilot. Decide the threshold that would make you stop before you begin, and treat only scarce commitments — money, time, data, introductions — as evidence.
What validation actually is
Validation is not proof that your idea is good. It's evidence about a specific belief you've written down — that a particular person has a particular problem, badly enough to pay a particular price to have it removed.
Which means most of the work happens before any test: getting the belief specific enough that a result could contradict it. An idea you can't be wrong about can't be validated. It can only be built.
This sits directly upstream of product strategy. Strategy is the set of choices you make; validation is how you earn the right to make them.
Six steps that do most of the work
In order. Each one is cheap, and each one can end the process early — which is the point.
01
Write the belief, not the idea
An idea can't be tested. A belief can. "Operations managers at small manufacturers will pay to stop rebuilding a spreadsheet" is testable. "A smarter ops tool" is not.
02
Name the one assumption that would kill it
Every idea rests on a stack of assumptions. Only one or two are fatal — usually demand or willingness to pay, rarely feasibility. Test the fatal one first, even if it's the uncomfortable one.
03
Find ten of the exact person
Not ten people who find it interesting. Ten people who currently have the problem this week and are already spending money, time or attention on a workaround.
04
Ask about the past, not the future
"Would you use this?" gets you politeness. "Show me what you did the last time this happened" gets you the truth — and the workaround they already pay for is your real competitor.
05
Charge before you build
A pre-order, a deposit, a paid pilot, an invoice for a manual version delivered by hand. Money is the only signal that survives contact with a busy Tuesday.
06
Decide in advance what would change your mind
Write the number down before you start: how many yeses, how much money, how many days. Without a threshold set upfront, every result reads as encouraging.
Four cheap tests that produce real evidence
Pick the one that attacks your fatal assumption. Running all four is usually procrastination with a spreadsheet.
Concierge test — 1 week, near-zero cost
Deliver the outcome manually for three customers. No product, no code. You learn what the job actually involves and whether anyone will pay for the result rather than the software.
Landing page and demand test — 3–5 days
One page describing the specific problem and outcome, a real price, and a clear action. Send traffic you can attribute. The signal isn't visits — it's the number of people who take a step that costs them something.
Paid pilot — 2–4 weeks
Charge a real, small fee for a scoped version. A paid pilot filters curiosity out of the room faster than any survey, and the objections you hear are the roadmap.
Ten problem conversations — 1–2 weeks
Structured conversations about what happened last time, not what they'd like. If you can't find ten people to talk to, that itself is the finding.
What counts as evidence
A simple rule: evidence is when someone gives up something scarce. Money, a scheduled hour, access to their data, an introduction to their team, a change to how they already work.
Everything else — likes, signups, "keep me posted", warm feedback on a demo — is interest. Interest is pleasant and predicts almost nothing. The demo is not the evidence.
The mistakes I see most
- 01
Validating the solution instead of the problem. Enthusiasm for a demo is not evidence of demand.
- 02
Talking to the wrong people — friends, peers, and other founders will validate almost anything.
- 03
Asking hypothetical questions and treating polite answers as commitments.
- 04
Building the MVP as the test. An MVP is expensive validation; make it the last resort, not the first.
- 05
Moving the threshold after the results come in, so the answer is always yes.
- 06
Confusing signups with demand. Free interest costs nothing and predicts nothing.
Common questions
How do you validate a product idea before building it?
Turn the idea into a written belief, identify the single assumption that would kill it, then run the cheapest test that could disprove that assumption — usually a demand test, ten problem conversations, or a manually delivered concierge version. Decide before you start what result would make you stop.
How long should validating an idea take?
Two to four weeks for a first honest answer. Most validation work is slow because it's vague, not because it's hard. A well-framed assumption can usually be tested in under a week.
How much does it cost to validate a product idea?
Far less than building. Problem conversations cost time only. A demand test with a landing page and a small ad budget is a few hundred euro. A concierge or paid pilot can be revenue-positive. Compare that with the cost of two quarters of development.
What counts as real evidence that an idea is validated?
Someone gives up something scarce: money, a scheduled hour, access to their data, an introduction to their team. Clicks, signups and encouraging conversations are interest, not evidence.
Can you validate a product idea without any code?
Usually yes. Delivering the outcome by hand for a handful of customers tests demand, pricing and the real workflow at once — and it tells you which parts are worth automating later.
What if validation says no?
You've saved the most expensive resource you have. In practice the answer is rarely a flat no; it's usually a narrower customer, a different problem or a different price. That correction is the point.
Where to start
If you want to know how much of this you've already done, the Founder Clarity Score takes two minutes and shows you where the thinking is thin. If you already have something built and want an honest outside read on it, that's the Product Reality Check.
Related reading: product strategy for founders · every prototype is tuition · start here
Want the validation checklist?
Leave an email and I'll send the one-page checklist behind this guide, plus one lesson a month. No newsletter, no offers.