How to Validate a Product Idea Before You Build It

Start with the problem, not the idea

Most product ideas get validated backwards. Someone builds a prototype of the solution, shows it to friendly people and counts the nods. That mostly measures how polite people are. It says little about whether the problem hurts enough for them to change what they do today.

So I validate in the order the risk sits: the problem first, then demand, then the solution.

Three questions, in order

1. Is the problem real and painful? Problem interviews with the people who would use it, about the last time it happened rather than what they'd like. On a VAT invoicing service for Indonesian businesses, interviews with tax practitioners, including the indirect tax team at a Big Four firm, found where the process actually broke: invoice numbers running out, invoices that had to be backdated, and the same data keyed in twice. None of that was in the original brief.
2. Will people act on it? Interest is cheap, so test behaviour. A fake-door test with thresholds agreed in advance shows whether people reach for it when it's in front of them.
3. Does this solution work for them? Only then a prototype, on paper or clickable, tested with real users on the tasks that matter, before any production code is written.

What you get

The assumptions behind the idea ranked by how badly they'd hurt if they were wrong, evidence against the riskiest ones, and a clear call: build it, change it or stop. It usually takes a few weeks, against the months a wrong build costs, and it's the first honest step towards product-market fit. It's the kind of work I do with founders and early-stage teams.

If you've got an idea and want to know whether it's worth a quarter of your team's time, let's talk.