Idea validation: test your start-up idea before you build

Idea validation means checking whether an idea solves a real problem that people would pay to have solved, before you spend months building it. It costs a few weeks and little money. This guide shows which assumptions to test, how to get honest answers in customer conversations, and which cheap tests come next.

What is idea validation, and why do it before you build?

To validate an idea, you first break it down into assumptions and test the riskiest ones with real people. The point is not to prove that you are right, but to find out early when you are wrong, while changing course still costs little. Eric Ries calls this validated learning: progress is measured by what you learn about your customers, not by the features you ship.

The data shows why this matters. CB Insights analysed 431 venture-backed start-ups that shut down since 2023. In 43 percent of the cases with a known reason, product-market fit was poor. Running out of money was the most common reason, at 70 percent, but it is usually the consequence rather than the cause. Building something nobody needs is expensive; asking first costs almost nothing.

Which assumptions do you need to test?

Write your idea down as a short list of assumptions, then sort them by risk. Most ideas rest on five assumptions:

• The problem. A clear group of people has this problem, often and urgently enough to do something about it.
• The customer. You can say exactly who these people are and who decides for them.
• The solution. Your approach solves the problem better than what they do today.
• The price. They or their employer pay enough for the business to work.
• The channel. You can reach enough of them at a cost the price can carry.

Always start with the problem, because a great solution to a problem nobody has still fails. Then work through the other assumptions, the riskiest first.

How do you get honest answers in customer interviews?

Ask people whether they like your idea, and most will say yes out of politeness, even if they would never use it. In his book The Mom Test, Rob Fitzpatrick sets three rules against this. Talk about the other person's life instead of your idea. Ask about specific things that happened in the past instead of opinions about the future. And listen more than you talk.

Good questions are, for example:

• When did this problem last come up, and what did you do about it?
• What have you already tried, and what did it cost you?
• What is the most tedious part of it today?
• Who else decides how this gets solved?

Avoid questions like "Would you use it?" or "How much would you pay?". They invite polite guesses. Instead, watch for signs that the problem is real: people bring it up before you ask, they have built their own makeshift fix, or they already pay for a poor solution.

Talk to people from your target group, not to friends and family. Keep having conversations until you stop hearing anything new, and write down what you heard right after each one.

Which tests come after the conversations?

Once the problem holds up, check next whether people act and not just talk. Each of these tests takes days or weeks, not months:

• A landing page. Describe the product as if it already existed, with a button to sign up or request access. Measure how many visitors from your target group click it.
• A service by hand. Deliver the service manually for a few customers, a so-called concierge test. That way you learn what they really need before you automate anything.
• A product behind the curtain. Customers use what looks like a finished product, while people do the work in the background. It shows whether the offer works before you build it.
• A pre-sale or a letter of intent. Ask for money, a signed letter of intent or a paid pilot project. Nothing separates polite interest from a real intent to buy as clearly.

Each of these tests is a minimum viable product in Eric Ries's sense: the smallest thing that lets you learn something. Before each test, write down which result counts as a pass, for example how many sign-ups you expect per hundred visitors, or how many conversations should lead to a paid pilot project. Without a threshold set in advance, any result can be explained away.

When is an idea validated enough?

You can never be completely sure. You have enough to start building when several signals come together. The problem comes up without you asking about it. People in your target group describe it in similar words. Some have committed something: time for a pilot project, a signed letter of intent or money. And you can name your first ten customers.

If the signals are weak, you have three options. Persevere if only one part is missing and you know how to test it. Pivot if the problem is real but your target group or solution does not fit. Or stop if the problem is too small. Stopping after six weeks of tests saves you two years of building in vain.

Which mistakes should you avoid?

• Building first. Code feels like progress, but it answers the question of the solution before the problem is settled.
• Asking friends. They want to support you, so they rarely tell you the whole truth.
• Counting compliments. "Great idea" is not information. A commitment is.
• Testing everything at once. Test one assumption at a time, or you will not know why something failed.
• Keeping it all secret. Someone stealing an early idea is unlikely. Building without feedback is the bigger risk.
• Validating alone. A second person also hears what you do not want to hear.

This is exactly where a co-founder who sits in on the same conversations helps: they are the best guard against wishful thinking. Our guide on whether you need a co-founder weighs this against starting alone. Idea validation is also a good trial project with a potential co-founder. Our guide on finding a co-founder shows where to look, and the founder test shows who would balance you.