Building a product is exciting. Designing the logo, naming the company, imagining the launch — these feel like progress. But they're not validation. They're the fun parts that happen before the hard part: figuring out whether anyone actually wants what you're building.
The brutal reality of the startup world is that most companies fail not because they built the product badly, but because they built the wrong product. They spent months or years creating something nobody was willing to pay for, or at least not in the way they'd imagined.
Validation is the process of stress-testing your assumptions before you've committed your time, money, and reputation to them. Here's how to do it properly.
Start With the Problem, Not the Solution
The most common validation mistake is falling in love with a solution before deeply understanding the problem.
Before you think about features, pricing, or technology, you need to answer one question: Does the problem I'm solving cause genuine pain, and are people actively trying to fix it?
The best indicator of a real problem is that people are already attempting to solve it — with spreadsheets, workarounds, manual processes, or expensive consultants. If your target customer has a duct-tape solution, that's a strong signal the problem is real. You're not trying to create demand. You're trying to capture it more elegantly.
Talk to 20-30 potential customers before building anything. Not to pitch your idea — to understand their workflow, their frustrations, and what they've already tried. Listen far more than you speak.
Define Your Riskiest Assumptions
Every business idea rests on a stack of assumptions. The job of validation is to identify which assumptions, if wrong, would kill the business — and test those first.
Common risky assumptions include:
- Customers will pay for this (versus expect it for free)
- Customers will switch from their current solution
- The problem is frequent enough to justify a recurring subscription
- You can reach customers affordably through your planned channels
- The unit economics work at scale
Write these down explicitly. Rank them by how lethal they'd be if wrong. Then design the cheapest, fastest test for each one.
The Pre-Sale Test
Nothing validates demand like someone handing over money before the product exists.
Landing pages with a waitlist are table stakes — they signal interest, not intent. A pre-sale or deposit converts interest into commitment. If people will pay for something that doesn't exist yet, you have real signal. If they won't, no amount of positive survey responses should fool you.
The mechanics are simple: build a landing page that explains what you're building, describes the value clearly, and asks for payment (even a small deposit or a discounted pre-order). Drive traffic through ads, personal outreach, or communities where your target customer spends time. Then watch the conversion rate.
A 5-10% conversion rate on cold traffic suggests you're onto something. Under 1% means your messaging, your audience targeting, or the fundamental idea needs work — and you've learned that for $500 instead of $500,000.
The Concierge MVP
Before automating anything, do it manually.
If you're building a software tool that matches freelancers with clients, start by doing the matching yourself via email and spreadsheets. If you're building a meal planning app, manually create personalized meal plans for ten paying customers. If you're building a data aggregation product, pull the data manually and send reports.
This approach — often called the "concierge MVP" — lets you deliver value and collect payment while testing your core assumptions, all without building software. You'll learn more from serving ten real customers this way than from building a full product and launching to crickets.
The goal isn't to do this forever. It's to compress the learning cycle and confirm that the thing you'd eventually automate is actually what customers need.
Distinguishing Signal from Noise
Friends and family will tell you your idea is great. Strangers on the internet will tell you it's terrible. Neither group is your customer.
Real signal comes from your target market — specific people who have the problem you're solving, who can afford your price point, and who you can actually reach. When these people pay money, refer others, or express frustration when you stop providing the service, you have signal. Everything else is noise.
Be especially wary of positive survey responses. People say they'd pay for things they never actually buy. Behavior is what matters, not stated intent. Design your validation tests to measure what people do, not just what they say.
When to Stop Validating and Start Building
Validation isn't infinite. At some point, you need to commit and build.
A reasonable threshold: meaningful revenue or pre-commitments from customers who aren't your personal network, evidence that customers are actively using or returning to whatever provisional version you've offered, and a clear understanding of the problem you're solving and for whom.
You'll never eliminate all risk. But validation narrows it dramatically — and the founders who validate before building dramatically outperform those who don't.
Build the cheapest version of your hypothesis, not the dream version of your product. You can build the dream version once you've proven the hypothesis.