Building the wrong thing faster is not progress. Here's how to know what's actually worth building before you write a single line of code.
If you're a technical founder, you already know how to build things. That's actually the trap.
The instinct when you have an idea is to open your editor and start shipping. Code feels like progress. But most failed startups don't fail because the product was badly built; they fail because it was a good build of something nobody needed.
Validation is how you find that out before it costs you three months and your savings.
Why "just build an MVP" is bad advice
"MVP" gets thrown around like it's a shortcut to validation, but a badly-scoped MVP is just a slow, expensive way to learn what a good conversation could've told you in a week.
An MVP tests whether people will use and pay for a solution. It does not test whether the problem is real. If you skip straight to building, you're testing both at once and if it flops, you won't know which assumption broke.
Validate the problem first. Then validate the solution. Then build.
Stage 1: Validate the problem exists
Before anything else, confirm you're not solving a problem that only exists in your head.
Talk to 15-20 people in your target market without pitching them. This is the step founders skip because it's uncomfortable. Don't describe your idea. Ask about their life:
"Walk me through the last time you dealt with [problem area]."
"What do you currently use to handle that?"
"What's the most annoying part of that process?"
If people struggle to describe the problem, or shrug it off as a minor inconvenience, that's not something to argue about.
Watch for the difference between polite interest and real pain. "That's a cool idea!" means nothing. "I've literally been Googling for a solution to this" means something. You're listening for evidence of existing workaround behavior: spreadsheets, hacky tools, expensive manual processes. People don't build workarounds for problems they don't have.
Quantify it if you can. How much time or money does this problem cost them? A problem that costs someone 5 minutes a month isn't a business. A problem that costs someone 5 hours a week or real money is.
Stage 2: Validate that people want your solution
Now that you know the problem is real, test whether your specific approach resonates still without full-blown building.
The landing page test. Build a single page describing your product as if it already exists. Clear value prop, one CTA (waitlist signup, "notify me," or even a fake "Buy Now" that leads to a "coming soon" page). Drive a small amount of targeted traffic to it and measure conversion. This tells you if the pitch works before you invest in the product.
The concierge MVP. Manually deliver the outcome your product promises, without automating anything. If you're building a scheduling tool, personally coordinate a few users' schedules by hand. It doesn't scale and that's fine. You're testing demand and refining the workflow, not proving you can build software (you already know you can).
The Wizard of Oz test. Similar to concierge, but from the user's perspective it looks automated. The "AI-powered" feature is actually you behind the curtain for the first few users. This is especially useful for validating AI/ML features where the underlying model is expensive or slow to build.
Pre-sell it. Nothing validates demand like someone paying before the product exists. Even a small deposit or annual-plan-in-advance from early users is a stronger signal than 100 "sounds cool" comments.
Stage 3: Define what "validated" actually means before you start
Vague validation goals let founders rationalize weak signals into "good enough." Set numeric thresholds before you run any test:
- Problem validation: e.g., 70%+ of interviews describe the problem unprompted and mention an existing workaround
- Solution validation: e.g., 5%+ landing page conversion to waitlist from cold traffic
- Demand validation: e.g., 10 people willing to pre-pay or commit to a pilot
- Write these numbers down beforehand. It's much harder to lie to yourself about "did we hit 5%" than about "did people seem excited." Common validation mistakes Only talking to friends and family. They're biased toward being nice to you. Get to strangers as fast as possible.
Asking "would you use this?" People are terrible at predicting their own future behavior. Ask about past behavior instead of what they've already done, tried, or paid for.
Treating a large TAM as validation. A big market size doesn't mean your specific wedge into it is wanted. "The productivity software market is worth $50B" tells you nothing about whether your particular tool solves a real, felt problem.
Validating once and never again. Validation isn't a gate you pass through once. Assumptions change as you build. Keep testing riskiest assumptions as you go, not just at the start.
Confusing engagement with love. People signing up for a free waitlist is a weak signal. People pre-paying, referring friends unprompted, or getting upset when a beta goes down that's love.
A simple framework to take away
Before writing code, be able to answer:
Who specifically has this problem? (Not "everyone" a narrow, describable segment)
What existing workaround are they using today?
How much is the problem costing them (time, money, stress)?
Why now what's changed that makes this solvable today?
What signal would convince you to build vs. walk away and what number defines it?
If you can't answer these with evidence (not assumptions), you're not ready to build. That's not a failure, it's information. Go get the evidence first; it's a lot cheaper than a shipped MVP nobody wants.
The uncomfortable truth
Validation is slower and less fun than building. There's no dopamine hit from a customer interview the way there is from shipping a feature. But the founders who skip it aren't moving faster; they're just moving confidently in a direction they haven't checked.
Build fast. But validate first.
Top comments (0)