What actually counts as validation
People are kind. Asked whether your idea is good, most will say yes — because the social cost of saying no to an enthusiastic person is higher than the cost of a vague compliment. This is why "I'd definitely use that" is worth approximately nothing, and why so many founders build with confidence straight into a wall.
Real validation is behaviour that costs the other person something: time, money, reputation, or effort. The currency matters less than the fact that spending it required a decision.
| Evidence | What it costs them | Strength |
|---|---|---|
| "That's a great idea" | Nothing | None |
| An email signup | Ten seconds and low-grade spam risk | Weak |
| A 30-minute call about their current process | Real time | Moderate |
| An intro to a colleague who has the problem | Their reputation | Strong |
| A pre-payment, deposit, or signed pilot | Money | Strongest |
The conversation that works
The goal of an early conversation is to learn what already happened, not what might. Past behaviour is fact; future intention is a guess offered politely.
- "Walk me through the last time you did this." — gets you a real sequence, with real friction in it
- "How long did that take?" — turns a vague annoyance into a number
- "What did you use?" — reveals the workaround, and often the budget
- "What did you do when it went wrong?" — finds the part that actually hurts
- "Have you looked for something better?" — a yes means an existing, unmet buying intent
Five to ten of these conversations is usually enough for the pattern to appear. If everyone describes a different problem, that's a finding too: you haven't found one market, you've found several individuals.
Choosing a test that matches the risk
There's no single validation method — there's a menu, and the right item depends on which assumption would sink you if it's wrong.
| The risk you're testing | The test |
|---|---|
| Does anyone have this problem? | Ten conversations about their last attempt at the task |
| Will they pay for a fix? | Pre-sell a pilot, or take a deposit against a delivery date |
| Can I reach these people at all? | One landing page, one channel, measured against a real target |
| Can this be built as described? | A prototype of the hardest 10%, not the easiest 90% |
| Will they use it more than once? | Do it manually for three customers, for a month |
Reading the result honestly
Set the bar before you run the test, in writing. "I'll consider this validated if three of ten people pay a deposit." Deciding afterwards what counts as success is not a test; it's a ritual.
A negative result is a cheap outcome, not a failure. You spent a week instead of a year. The only expensive outcome is a negative result you decide to ignore.
A two-week validation plan
- Write the single riskiest assumptionThe one that, if false, makes everything else pointless. Usually "anyone will pay for this."
- Write the pass bar, in numbers, before startingKeep it somewhere you can't quietly edit later.
- Run ten conversations about past behaviourNo pitching until the end. Take notes in their words, not your summary of them.
- Run one costly-signal testA deposit, a pilot agreement, an intro. Something with a price attached.
- Compare against the bar and write the verdict downThree outcomes are allowed: proceed, adjust the problem, or drop it. All three are progress.
Common mistakes
- Counting compliments as evidence
- Pitching before asking, which contaminates every answer that follows
- Testing the easy assumption instead of the fatal one
- Setting the success bar after seeing the result
- Building a full product because five people said the idea sounded interesting
Key takeaways
- Validation is behaviour with a cost attached, not agreement
- Ask about the last time it happened, not about what someone would do
- Pick the test that matches the risk that would actually sink you
- Write the pass bar down first; decide the verdict against it, not against your mood
Try it yourself
Book one 20-minute call this week with someone who has the problem you think you've found. Ask only about the last time they did the task, and don't mention your idea until the final two minutes. Write down which of your assumptions the call broke.