The failure mode isn't building badly. It's building competently for months and then discovering nobody needed it. Validation is the work of finding that out in a week instead.

Talk to five people first

Not "would you use this?" — everyone says yes to hypotheticals, out of politeness. Ask about the past instead:

  • "When did you last have this problem?"
  • "What did you do about it?"
  • "What did that cost you — time, money, annoyance?"
  • "Have you looked for something to fix it?"

Past behaviour is evidence. Future intention is conversation.

If nobody has looked for a solution, they don't feel the problem strongly enough to adopt one — regardless of how enthusiastically they agree it's a problem.

Then put up a page

A landing page describing the finished thing, with a way to register interest. This costs an evening and gives you a real number instead of five opinions.

Be honest that it isn't built. It costs you almost no signups.

Read the alternatives

Whatever people currently do — a spreadsheet, a competitor, doing without — is your real competition. Look at reviews of the closest existing tool. The one-star reviews are a specification for your product written by people who wanted it to exist.

Ask the awkward question

validate.txt
My idea: <one sentence>
The people I think want it: <who>
What they do today instead: <the alternative>

Be sceptical. Specifically:
- Why might this not be a real problem, or not painful enough to
  change behaviour over?
- If it's real, why hasn't someone built it? What's the non-obvious
  reason it's harder than it looks?
- What's the cheapest test that would tell me I'm wrong within a week?

Don't be encouraging. I want the strongest argument against this.

Then build the smallest version

Validation doesn't end at research. Ship a rough version to the five people you spoke to. Whether they use it — not whether they like it — is the answer.

"That's interesting" means no. "When can I have it?" means yes. Most feedback is the first, phrased kindly.