Consolidated from a four-part series we published in 2021. The method has not changed. The tools for doing it have gotten cheaper.
A common problem among people who build digital products is that they build the thing before they find the people who need it. It is the Field of Dreams plan: build it and they will come. They do not come. You have to find them, and if you funded the build yourself, you cannot afford not to.
Validation is how you find out, before you spend the money, whether there is a real market, a real problem, and a solution people will use and pay for. Here is how to do it, in the order that works.
Start with the questions
Before anything else, write down your answers to these. Be honest. The ones you cannot answer are the ones to validate first.
- What is the biggest problem you are solving?
- Who has it? Who is the customer, and who is the user? They are often not the same person.
- When: why is now the right time for this solution?
- How do people solve it today? Is software even the best answer? How many people have the problem, how big is the market, how will you reach them, and how will you make money?
- Why, asked repeatedly, about all of the above.
Boiled down, you are validating three things: that there is market demand, that the problem is real and painful, and that your solution addresses it. You can validate all three without building anything.
Validate demand
The goal is to answer: how big is the total market, how much of it could you realistically capture, and is that enough to justify the risk and the money?
Get specific about who the user is: role, industry, company size, and how technically comfortable they are. Then size it with real sources. Industry reports, census and labor data, and the research firms if you have access. Search volume tells you how many people are looking for a solution each month. Competitors’ traffic and pricing, and their revenue where you can find it, tell you what the market currently pays.
If the numbers say the market is small, that is a finding, not a failure. Better to learn it now.
Validate the problem
Now talk to real people in that market. Find them in industry groups, at trade shows, in the forums where they complain. In-person conversations are worth more, because someone who gives you an hour has a problem worth an hour. Make sure some of them have buying power.
Ask open questions about the problem and resist steering them toward your solution. Let them show you how they handle it today: the spreadsheet, the workaround, the other app. That is where your design will come from. Questions that matter:
- Do they know they have the problem? Is it top of mind or occasional?
- Are they actively trying to solve it? Have they already tried?
- Do they have budget for it, and what would they pay?
Ask about price directly. It is not a mystery and it should not be treated like one. If someone says they have budget and would pay, get their contact information. They are your first customers.
Sample size depends on the product. Twenty real conversations is a reasonable floor for a business product, a hundred for a consumer one. Weight the answers: a customer who would onboard fifty users matters more than one who would onboard one.
Validate the solution
Only now do you show people something. Still no code. Make the idea visible at the highest fidelity you can manage:
- Have users try your competitors’ products in front of you and tell you what is good and what is missing.
- Sketch the interface with them, one on one.
- Walk them through wireframes of the workflow and watch where they get lost.
- Put click-through mockups in their hands and watch what they do, not what they say.
The goal is not to sell them. It is to find out what has to change. Confusing interactions, too much on the screen, an unclear structure, a feature buried three levels deep: every one you find now is a month you do not spend later. Then iterate and show them again.
The habit that matters
Underneath all of this is a loop you learned in grade school: observe, ask, hypothesize, test, analyze, conclude. The build-measure-learn cycle is the same loop with a startup label on it. It applies to more than the product. A landing page, a slide deck, a one-page brochure, and a mockup are all things you can build cheaply to learn whether an assumption is true.
Validation does not end when development starts. It is how the first release gets scoped, how the second release gets chosen, and how the product avoids becoming a list of features nobody asked for.
Where we fit
This is most of what a VDP Sprint does in three to four weeks: a workshop with your stakeholders, user research, click-through mockups of the key screens, and a roadmap with a real cost on it, before anyone writes production code. It is a fixed fee, and you own everything it produces whether or not you build with us. Some clients leave a VDP having decided not to build, and that is a good outcome.
If you have an idea and are not sure whether it deserves the money, here is how getting started works.