How I Validate Product Ideas Before Writing Code

product strategy building

Every engineer has a graveyard of projects they built that nobody used. I’ve been there too. After a few expensive lessons, I developed a simple validation process that saves me weeks of wasted effort.

The Problem with “Build It and They Will Come”

Most technical founders default to building first. It feels productive - you’re writing code, making progress. But without validation, you’re just guessing.

My 3-Step Validation Framework

1. Problem Interview (Week 1)

Before anything else, I talk to 5–10 people who might have the problem I’m solving. Not about my solution - just about their pain points. The goal is to hear the same complaint, unprompted, from multiple people.

2. Demand Signal (Week 2)

Can I find evidence that people are already spending time or money solving this problem? I look for:

  • Existing tools with bad reviews (unmet needs)
  • Reddit threads, forum posts, tweets complaining about the problem
  • Competitors who are charging (validates willingness to pay)

3. Smoke Test (Week 3)

A landing page describing the solution with a clear CTA - a waitlist signup, a pre-order button, or a “request access” form. I drive some traffic to it and measure conversion.

When to Build

If at least 3 out of 5 people in interviews mention the pain unprompted, I can find demand signals, and my smoke test converts above 5% - then I build.

What This Looks Like in Practice

I used this exact framework before starting AutoRadar. Used car buyers were frustrated with stale listings and missing price context across fragmented marketplaces. The pain was real, the demand signals were strong, and the smoke test confirmed interest.

The hardest part of this process is resisting the urge to skip ahead. But the 3 weeks you spend validating will save you 3 months of building the wrong thing.