Problem Validation

Problem validation is the work of confirming that the problem you intend to solve is real, frequent, and painful enough that people are already trying to solve it themselves.

It comes before everything else, and skipping it is the most expensive mistake available to a founder. You can build a product people admire, priced correctly, marketed well, aimed at a problem nobody actually has. Every downstream decision inherits that error, and none of them can correct it.

The three things you are testing

Is it real? Not "would this be nice" but "does this happen." Look for evidence the problem occurred, not agreement that it would be bad if it did.

Is it frequent? A problem someone hits twice a year gets tolerated. A problem they hit every Tuesday gets budget. Frequency is usually a better predictor of willingness to pay than severity.

Is it painful enough that they already act? This is the one that matters most. If someone has a problem and has done nothing about it, they do not have a problem — they have a mild preference. The strongest signal in problem validation is a workaround: a spreadsheet doing a job no spreadsheet should do, a part-time contractor hired to paper over a gap, a competitor's product being used badly because nothing better exists.

Where the evidence lives

The useful sources are the ones where people complain without being asked.

Support forums and product reviews for adjacent tools. Subreddit threads where someone describes their setup and someone else replies "same." Job listings, which are the most under-read signal available — a company posting for a role whose description is your product's feature list is a company paying salary to solve your problem manually. Comments under posts about the general topic.

What these have in common is that nobody was performing for you. A person writing a frustrated forum post at 11pm has no incentive to be polite about a problem they do not really have.

Problem validation vs solution validation

They answer different questions and failing to separate them is why a lot of "validated" ideas die anyway.

A fake door test is solution validation. It tells you whether people want your answer. It does not tell you whether the underlying problem was worth answering — a well-designed landing page can pull signups for a problem that turns out to be shallow.

When to stop

There is no clean threshold, and anyone who gives you one is selling something. The practical test is whether you can state the problem in a sentence that a person who has it would read and say "yes, that is exactly it" — and whether you can point at three independent places where someone described it without you prompting them.

If you are still summarising the problem differently each time you say it, you are not done.

How theLab does this

theLab's problem search runs this step automatically before an experiment is built. It searches for real discussions of the problem across public sources, classifies what it finds by signal strength, and returns a market report showing where your audience is and what they are already saying — including when the honest answer is that it found nothing. A silent result is a real finding, and it is cheaper to receive it now than after a year of building.

Once the problem holds up, customer discovery tells you who has it most acutely.

theLab builds the landing page, finds real people who match your audience, runs the outreach, and returns a verdict from real signups. First experiment free, no card.