How to validate a product idea before building it

Published 1 October 2026 · By Daily Product Idea · Our methodology

What validation means

Desk research can tell you a problem is real and an idea is worth testing. It cannot tell you the idea works. That needs evidence from the customer: something they did, not something they said they would do. Paying, returning, completing a task, handing over their real data. Opinions, compliments and "I'd use that" are not validation, however enthusiastic.

Every idea on Daily Product Idea is published as "worth testing" at most, never as validated, because the research behind it is desk research. Each one ends with the questions to test first. They show what a good validation test looks like in practice, and this guide uses them as examples. To judge whether an idea is worth testing in the first place, see how to evaluate a product idea.

Start with the assumption that would kill the idea

Every idea rests on a few beliefs nobody has shown to be true. List them, then ask of each: if this is wrong, does the idea fail completely? Test that one first, even if it is not the most interesting.

• Trade Reality Dossiers is a paid report on how a small trade really works, built from interviews. Its first test is a pre-sale: publish a free teardown and see whether a waitlist converts at $79–$149, before doing a single interview. If nobody pays, the interviews would have been wasted.
• Deal Floor works out the lowest price a quoted job can take. It depends on owners knowing their overheads and close rate. So the first test is to ask eight to ten owners to talk through their last three quotes and see whether they can produce those figures at all. If they cannot, the calculator fails at its first input.

Choose a test that can say no

A good test is cheap, fast and able to fail. If no result would change your mind, it is not a test. These are the patterns that come up most often in the ideas published here.

Do it by hand first

Deliver the result manually to a few customers before building the software. Launch Lane, a 30-day plan for getting a side project its first users, starts by hand-building and selling ten plans at £39 and measuring one number: how many buyers are still completing and replying to daily tasks on day 21. That tests payment and engagement together, with no code.

Prove the hardest part works

If one component carries the whole idea, build only that and measure it. LedgerLine turns supplier invoices into spreadsheet rows, so its first test is a blind accuracy bake-off: fifty real invoices from varied suppliers through a vision model, measuring how many fields need correcting, before any interface exists. Flight Deck does the same for its one hard problem, telling an agent that needs you from one that has finished.

Watch what people do over time

Some ideas only work if people keep doing something. Measure the habit, not the first impression. Explain-Before-Merge asks developers to explain AI-written code before it is committed. Its first test is a two-week diary study with five to ten developers using a crude version that only asks questions and records skips. It measures the skip rate over time, not satisfaction.

Check the problem holds still

A product that automates a repeated task assumes the task repeats the same way. ReconSheet saves a mapping for each weekly CSV export, so its first test collects four to six consecutive weeks of real exports and counts how often the column headers, date formats or fee breakdowns change. If they change every week, saved mappings save nothing.

Set the pass mark before you start

Decide in advance what result means stop. Written down beforehand, it is a decision rule. Chosen afterwards, it is a story. Explain-Before-Merge's test states its own failure: if skips trend to 100% by day ten, the concept is dead, whatever else is true. Launch Lane's names a single number to read on a single day.

What does not count as validation

• Friends and colleagues saying it is a good idea.
• Survey answers about what people would pay or use, on their own.
• Likes, upvotes and follows.
• A competitor existing. That suggests a market, not that your version will win it.
• Your own enthusiasm after weeks of research.

Each can be a reason to run a test. None is a result. Waitlist sign-ups are a weak signal on their own, and stronger when the page states a price.

A short checklist

1. List the assumptions the idea rests on, separately from what the research found.
2. Pick the one that kills the idea if it is wrong.
3. Design the cheapest test that measures what people do, not what they say.
4. Write down the pass mark, and the result that means stop, before you start.
5. Run it with real customers, ideally ones who already have the problem.
6. Only then decide whether to build, change the idea or drop it.

Every idea on Daily Product Idea is published with its assumptions and the tests to run first. See how ideas are researched and assessed or browse the researched ideas.