Why validate at all

The most common way indie products fail is not bad code. It is building something that not enough people want badly enough to use or pay for. Months of evenings go into a product, it launches, and the response is polite silence.

Validation is the work you do before and during building to reduce that risk. It does not guarantee success. Nothing does. But it can save you from spending half a year on an idea you could have ruled out in two weeks.

The goal is not to prove your idea is good. It is to find out, as cheaply as possible, whether it is wrong.

Start with the problem, not the product

Most validation mistakes come from testing the solution instead of the problem. If you ask people "Would you use a tool that does X?", most will say yes to be nice. That tells you almost nothing.

Instead, find out whether the problem is real, frequent and painful:

  • How do they handle it today? If they have a workaround, it is real. If they do nothing, it may not hurt enough.
  • When did it last happen? Recent, specific stories beat general opinions.
  • What does it cost them? Time, money, stress, lost customers.
  • Have they tried to fix it? People who have searched for a solution, tried tools or built spreadsheets are your best prospects.

If you cannot find people who have the problem and are actively annoyed by it, that is your first signal.

Talk to people

Conversations are the cheapest and most informative validation method. Aim for ten to fifteen short conversations with people who match your intended user.

Finding them:

  • Communities where they gather. Ask if anyone would be up for a short chat about how they handle the problem. Follow the community's rules.
  • Your own network. Friends of friends in the right role.
  • Public posts. People who have written about the problem, contacted politely and individually.

Running them:

  • Listen more than you talk. Aim to speak less than a third of the time.
  • Ask about the past, not the future. "Tell me about the last time this happened" beats "Would you use this?"
  • Do not pitch. If you describe your idea at all, do it at the end.
  • Take notes on exact phrases. The words people use for their problem are the words your landing page should use.
  • Ask who else you should talk to.

After ten conversations you will usually see patterns: the same frustrations, the same workarounds, or the same shrug.

Signals that mean something

Not all positive responses are equal. Rank them by how much they cost the person:

Signal Strength
"That's a cool idea" Very weak. Costs nothing to say.
Joining a waitlist Weak. An email address is cheap.
Agreeing to a follow-up call Moderate. Time is a real cost.
Introducing you to a colleague with the same problem Moderate to strong. They are putting their name on it.
Sharing their current workaround in detail, or their data Strong. They want it solved.
Paying upfront or pre-ordering Strongest.

The further down this list your evidence sits, the more confident you can be. A waitlist of 500 people from a single viral post may be weaker evidence than five people who each asked, unprompted, when they can pay.

Cheap tests before code

Once conversations suggest the problem is real, a few low-cost tests can check the solution and the demand:

  • A landing page. Describe the product plainly, show a price, and ask people to join a list or pre-order. Send traffic from the communities you have been participating in. Measure how many visitors take the action.
  • A manual version. Do the work by hand behind a simple form. If your product will summarize reports, summarize them yourself for the first few users. You learn exactly what they need and whether they come back.
  • A clickable mockup. Show it to people from your conversations and watch where they get confused.
  • A pre-sale. Offer a discounted early price for a product that is not built yet, with a clear delivery date and a refund promise. It is the strongest test, and the most uncomfortable.

Say you put up a landing page and send it to three relevant communities. 400 people visit, 36 join the list, and 4 pay a $29 pre-order. The 4 pre-orders are much stronger evidence than the 36 signups, and they are the people to build with.

Reading a negative result

Validation often returns a "no" or a "not quite." That is the point. Common results and what they suggest:

  • People have the problem but do not care much. It may be a nice-to-have. Consider whether there is a more painful version of the problem.
  • The problem is real but the audience is hard to reach. Look for a narrower group that gathers in a specific place.
  • People want it but will not pay. Check whether you are talking to hobbyists when the buyers are professionals, or whether a different pricing model fits.
  • An existing tool already solves it well. Look for a specific group that tool serves badly. That niche may be your opening.

A negative result on your first idea is common. Many makers go through several before finding one that holds up.

Do not over-validate

Validation can become its own form of procrastination. At some point you have to build. A reasonable threshold for many indie products:

  • Several people describe the problem in specific, recent terms without prompting.
  • You know where to find more of them.
  • At least a few have committed something real: time, introductions or money.

Once you reach that, build the smallest version that solves the core problem, and keep validating as you go. Real usage is the best validation of all.

FAQ

Can I validate by looking at competitors?

Competitors are evidence that a market exists, which is useful. They do not tell you whether you can win a share of it. Use them as a starting point for conversations, not a substitute for them.

What if my idea is for myself?

Building something you need yourself is a great start and a form of dogfooding. It still helps to find out whether others share the problem before assuming it can become a business.

Is it okay to validate with a waitlist only?

It is better than nothing, but waitlists are weak signals on their own. Combine one with conversations or a pre-sale if you can.

Related reading