Most products that fail do so because not enough people want them, not because the code was bad. Validation is the work of finding out, early and cheaply, whether real customers have the problem you think they have and will pay for your solution. It takes weeks, not months, and it can save the entire cost of a build.
This guide covers practical methods, from conversations to pre-sales, and how to read the results honestly.
Validate the problem before the solution
Start by confirming that the problem is real, frequent and costly for a specific group of people. Talk to potential customers about how they handle it today. Ask what it costs them in time or money, what they have tried and why it did not work. Do not pitch your idea yet: you want their honest experience, not polite agreement.
Running good customer interviews
Aim for ten to twenty conversations with people who match your target customer. Keep them short and open. Useful questions include:
- How do you handle this today?
- When did it last cause a problem? What happened?
- What have you tried to fix it?
- What does it cost you, in time or money?
- Who else is involved in this decision?
Take notes, look for patterns and pay attention to emotion. Problems people describe with frustration are worth more than ones they mention in passing.
Test demand with a landing page
A simple page that describes the product, its benefits and a call to action, such as joining a waiting list or requesting early access, tests whether your message attracts interest. Drive a small amount of targeted traffic to it, through ads or communities where your customers gather, and measure the conversion rate.
Treat sign-ups as a weak signal: interest is cheap. It tells you the message resonates, not that people will pay. See landing pages.
The strongest signal: pre-sales
The best evidence is money. Offer early customers a discounted plan, a paid pilot or a deposit before the product exists. For business products, a signed letter of intent or a paid pilot agreement is strong evidence. If people will not pay anything in advance, even with a discount, take that seriously.
Concierge and manual tests
Before building software, deliver the service by hand for a few customers. If your product will generate monthly reports, produce them manually. If it will match buyers and sellers, do the matching yourself. You learn exactly what customers value, which steps matter and what the software must do, and you earn revenue while learning.
Many successful products started this way, with the founder doing the work that software later automated.
Clickable prototypes and no-code tools
A clickable prototype, made from wireframes or designs, lets customers try the flow without any real code. Watching people use it reveals confusing steps and missing features. No-code tools go further, letting you build a working version for a small group. They are ideal for testing, even if the final product will be custom. See no-code vs custom development.
Learn from competitors and alternatives
Competitors are evidence that a market exists. Read their reviews, especially the negative ones, to find what customers still struggle with. Also consider the non-software alternatives people use today, such as spreadsheets, email and paper. Your product must be clearly better than those, not just better than other software.
Using AI to speed up validation
AI tools help with the research side of validation: summarizing interview notes, grouping feedback by theme, drafting landing page variations and analyzing competitor reviews at scale. They do not replace talking to customers, but they make it faster to learn from those conversations. See customer feedback analysis.
Decide what success looks like before you start
Set clear criteria before running tests, so you cannot talk yourself into a result later. For example: "We build if at least five of twenty target customers agree to a paid pilot." Or: "We change direction if fewer than a set share of visitors join the waiting list." Written criteria keep validation honest.
Reading the results
Strong signals: people pay or commit before the product exists, describe the problem without prompting, ask when they can start and introduce you to others. Weak signals: compliments, likes, sign-ups without follow-up and "let me know when it is ready". Mixed results often mean the problem is real, but the target customer or the solution needs adjusting.
Validating business products
For products sold to businesses, validation has a few extra steps. Find out who feels the problem, who pays for the solution and who approves the purchase, because they are often different people. Ask about budgets, buying processes and the tools the product would replace or connect to. A paid pilot with a small group of companies is often the clearest test: it proves both value and the willingness to pay, and it shows what integrations and security questions buyers will ask.
Business customers also tend to ask for features that suit only them. Look for the needs that repeat across several customers, and treat one-off requests with caution until you see them again.
From validation to MVP
Once the evidence is strong, move to a focused MVP that solves the validated problem for the validated customer. Your validation work becomes the brief: the problem, the users, the workflow and what they will pay. See how to plan a SaaS MVP and how to write a software requirements document.
Validation checklist
- Target customer described in one sentence.
- Ten or more problem interviews completed.
- Landing page tested with real traffic.
- Pre-sales, deposits or paid pilots attempted.
- Manual or concierge version delivered to a few customers.
- Success criteria written in advance and results compared.
- Decision made: build, change or stop.
Keep validation time-boxed
Validation can become a way to avoid deciding. Give it a clear time box, often four to eight weeks, and a decision date. At that date, look at the evidence against your criteria and choose: build, change the idea and test again, or stop. Each of those is a good outcome, because each is based on evidence rather than hope.
Keep a short record of what you tested, what you learned and why you decided. It will be useful for investors, future team members and your own next idea.
Finally, share what you learn with the people you interviewed. Many will be glad to hear how the idea developed, and some will become your first customers or your best source of introductions.