How to Validate a Product Idea Before Writing a Single Line of Code

The most expensive mistake in product development isn't a bug or a missed deadline — it's building something nobody wanted, and finding that out after months of engineering time. The good news is that validating demand almost never requires code. It requires talking to people and paying close attention to what they actually do, not just what they say.

Start with the problem, not the solution

It's tempting to open conversations with a pitch: 'I'm building an app that does X, what do you think?' This almost always produces polite encouragement, which is worthless as signal. A better approach is to ask about the problem directly — how they currently handle it, what they've tried, what frustrates them about existing options. If people can't describe a real, recurring pain point without being prompted, the idea likely doesn't have a strong enough problem behind it yet.

Watch for evidence of behavior, not opinions

Someone saying 'I'd definitely use that' means very little. Someone spending money, time, or effort on a workaround for the problem right now means a great deal. A landing page that collects real email signups, a waitlist that people actually join, a pre-order that people actually pay for — these are behavioral signals, and they're far more reliable than survey answers.

Build the smallest thing that tests the core assumption

Before a full product, there's almost always a smaller version that tests the riskiest assumption. That might be a single landing page, a manual concierge version of the service, or a clickable prototype used in real conversations. The goal isn't to look impressive — it's to learn whether the core assumption holds before investing in the full build.

That last question matters more than people expect. If there's no answer that would change your mind, it isn't really a validation process — it's a search for permission to build what you already decided to build.