Two founders skip the same conversation. The first is certain customers will want the product and sees research as a delay. The second quietly suspects customers will not want it and sees research as a verdict. Both open their laptops and begin building. One is running from doubt; the other is running on confidence. From the market’s point of view, however, they are conducting exactly the same experiment—only with the most expensive method available.

Validation sounds like paperwork because the word is often attached to surveys, reports, and impressive-looking charts. In practice, it is closer to insurance. A few days spent testing an assumption cannot guarantee success, just as insurance cannot prevent a fire. It can limit the damage when the founder has misunderstood the problem, the buyer, or the urgency. The earlier that misunderstanding appears, the less code, cash, and identity have become attached to it.

The first useful evidence comes from behaviour, not compliments. Ask a potential customer to describe the last time the problem occurred. What triggered it? What did they do next? How long did the workaround take, who else became involved, and did anyone pay to make it smaller? A polite “I would use that” describes an imaginary future at no cost to the speaker. A spreadsheet maintained every Friday, a contractor already being paid, or a process everyone dreads is evidence from a world where the problem has consequences.

Conversation reveals the shape of the problem, but a small action test reveals whether interest survives friction. A landing page can ask visitors to join a waitlist, book a call, or request early access. The number of visitors matters less than the proportion who take the next meaningful step and whether they resemble the intended buyer. A hundred curious clicks from the wrong audience can be weaker evidence than three qualified people who volunteer time to explain their workflow.

The product itself can also begin as a manual service. If the proposed SaaS would produce a weekly report, make the report by hand for two customers. If it would organise a messy approval process, coordinate the first few approvals with forms and messages. This concierge version is deliberately inefficient. Its purpose is to expose the sequence, exceptions, and language users actually need before those choices harden into software. Manual effort is cheap when it prevents automation of the wrong thing.

Not every weak result means the idea should be abandoned. Validation can reveal that the problem is real but the audience is wrong, the promise is vague, or the requested commitment arrives too early. That is why one test is not a courtroom verdict. Look for a pattern across conversations and actions. If people describe the same costly problem, already attempt to solve it, and accept a reasonable next step, the uncertainty has narrowed. If every positive response requires a different product, the idea may still be a collection of wishes rather than a market.

So yes, validate before building—not because research deserves a ceremonial place at the start of a project, but because development amplifies whatever assumption it receives. A good assumption becomes a useful product more quickly. A bad one becomes a polished mistake. The aim is not to remove all risk before writing code; that would take forever. It is to spend small amounts of time and discomfort now so the larger bets on design, engineering, and hiring are made with evidence instead of hope.