Most failed startups don't fail because the founders couldn't build the product. They fail because they built something nobody wanted badly enough to pay for. Validation is how you find that out before you spend months and your savings on the wrong thing.
Here's a practical process you can run in a week or two, not a semester of business school theory.
What "validating an idea" actually means
Validation isn't a survey. It isn't asking your friends "would you use this?" — everyone says yes to be nice, and it costs them nothing to say it. Real validation means finding evidence that:
- The problem you're solving is painful enough that people are already trying (and failing) to solve it
- People will change a behavior, pay money, or give up real time to get your solution
- You can reach these people repeatably, not just the five who happen to be in your network
If you can't find evidence of at least the first two, you don't have a validated idea yet — you have a hypothesis.
Step 1: Talk to 10 people who have the problem, not people who like you
The single biggest validation mistake is talking to people who want to support you rather than people who actually have the problem. Friends and family are the worst validation panel you can pick — they're biased toward encouragement.
Instead, find people who:
- Have complained about this problem publicly (Reddit, X, forums, reviews of competing tools)
- Currently use a janky workaround (a spreadsheet, a Notion doc, three disconnected tools) to deal with it
- Have no relationship with you, so they have no reason to be polite
Ten real conversations with strangers who have the problem will tell you more than fifty surveys sent to your network.
Step 2: Ask about their past behavior, not their future intentions
"Would you use this?" is a bad question — people are terrible at predicting their own future behavior, especially with something hypothetical.
Better questions:
- "Walk me through the last time this problem came up for you."
- "What did you try to do about it?"
- "What are you using right now instead, and what do you hate about it?"
- "What would it have been worth to you to solve that, that day?"
You're digging for evidence of past pain and past spending, not future promises.
Step 3: Look for a "hair on fire" reaction
Not every real problem is worth building a company around. You're looking for the difference between "yeah that's mildly annoying" and someone visibly lighting up because you've just described their exact daily frustration. That second reaction is what "hair on fire" means — and it's the signal that's actually worth building toward.
If most of your ten conversations produce polite interest rather than genuine relief or excitement, the idea probably needs to be sharpened, narrowed, or rethought before you build.
Step 4: Test willingness to pay before you build
You don't need a finished product to test whether people will pay. Some low-effort ways to test this early:
- A landing page describing the solution with a "join the waitlist" or "pre-order" call to action, and see if strangers (not your network) actually convert
- A concierge test — manually do the thing you'd eventually automate, for a handful of real customers, and see if they pay for that manual version
- A simple pre-sale or deposit ask, even a small one — money is a much stronger signal than enthusiasm
If people won't hand over $10 or their email for early access, they're unlikely to hand over real money later.
Step 5: Narrow until it's sharp
Most first ideas are too broad. "A tool for small businesses" isn't validated or validatable — "a tool for solo hairdressers who currently book appointments over text message" is. The narrower and more specific your first target customer, the easier it is to find them, talk to them, and know clearly whether you've nailed the problem.
You can always expand later. You can't validate something so broad it doesn't describe a real, findable group of people.
Common validation traps to avoid
- Confirmation bias — only talking to people likely to agree with you
- Feature-first thinking — validating whether people like your solution instead of whether the problem is real and painful
- Sample size of friends — five encouraging conversations with people who love you isn't validation
- Skipping straight to building — the fastest way to "find out" is often the slowest way to actually learn anything
What comes after validation
Once you've got real signal — people describing the pain unprompted, workarounds they're unhappy with, and some evidence they'd pay — the next step is turning that into a scoped first version. That's where prioritization and roadmapping come in, so you build the smallest thing that actually addresses the validated problem instead of everything you can imagine.
This is the kind of groundwork Wedge's canvas helps you work through directly in conversation — turning early validation signals into a scoped roadmap and the first tasks to act on.