How to do it
Find three people already paying to solve it
Not people who agree it is a problem — people who have spent money. A competitor subscription, a freelancer, an offshore VA, a plugin, a consultant. If after a week of looking you cannot find three, that is your answer and it cost you a week.
Interview five to eight of them about history, not hypotheticals
Ask what happened the last time the problem occurred, what they used, how long it took and what it cost. People are unreliable about what they would do and accurate about what they did. You are listening for the same workaround described independently by different people.
Put up a priced page and count who reaches checkout
One page: the promise, the price, a button. Drive a few hundred of the right visitors to it from a community, a search ad or a partner list. Measure how many reach the payment step. Be honest on the next screen — say it is not built yet and when it will be. A test that leaves people feeling tricked has bought a number and cost you your first customers.
Deliver the outcome manually for three to five customers
Do the work by hand and charge for it. This is slower than building and teaches more, because it surfaces the parts of the problem nobody mentions in an interview. Most failed products were technically fine and solved a slightly different problem than the real one.
Worked example
Four tests, by what they cost and what they prove
Run them in this order. Each is cheaper than the next and each can end the process — which is the point of running them at all.
Why 'build a small MVP first' is the expensive option
There is no MVP small enough to cost less than a conversation. The cheapest credible build is several lakh and several weeks; the four tests above cost about thirteen thousand rupees and two weeks, and they answer a question the build cannot.
A build tells you whether people use a thing. Validation tells you whether they wanted it before you turned up. Those are different questions, and only the second one predicts whether anyone will pay next year.
What to do when the tests disagree
The common pattern is strong interviews and a weak landing page. Usually that means the problem is real and your framing of the solution is not — the same people who described the pain vividly did not recognise it in your headline.
The opposite pattern, weak interviews and a strong page, almost always means the traffic was wrong. Check who actually saw the page before you conclude anything from the conversion rate.
What goes wrong
- Building a 'small MVP' first — there is no MVP small enough to be cheaper than a conversation
- Counting waitlist signups, which cost the other person nothing
- Driving untargeted traffic to the fake door, so the conversion rate measures the wrong audience
- Interviewing friends and people in your own industry bubble
- Running all four tests at once, so you cannot tell which one produced the signal
Is your number plausible?
Each check catches a different way the arithmetic can be right and the answer still wrong.
- If nobody in your test gave up money, time or reputation, you have collected opinions rather than evidence
- If you cannot name the three people already paying, you are still validating a solution rather than a problem
- If the answer came back yes on every test, check whether any of them could have produced a no
Related answers
How long should the whole thing take?
Two to three weeks of focused effort. Longer usually means the tests have turned into research, which is comfortable and produces no decisions.
What if I already started building?
Run the tests anyway, and be honest about the fact that the result may be inconvenient. Evidence collected after you started building is worth less because you will read it more generously — write down in advance what would make you stop.
Do I need a co-founder to do this?
No. Every test here is a one-person job. What you do need is somebody to tell the result to honestly, because the failure mode of solo validation is a founder marking their own homework.