When you're ready for validation
Validation makes sense when you have a specific problem in mind. Not "people struggle with productivity". That's too vague. More like "freelance consultants lose track of which proposals they've sent and when to follow up."
If you're still figuring out the landscape, you're probably in discovery mode. If you have a hypothesis you want to test, you're ready for validation.
The question changes from "what's going on in this space?" to "is this particular problem real, and does it matter enough?"
What "validated" actually means
A validated problem isn't just one that exists. It's a problem that:
- Happens often enough to be worth solving
- Causes enough pain that people notice it
- Matters enough that people have tried to solve it, or wish they could
That last point is useful context. If someone has a problem but has never done anything about it, dig deeper. Sometimes it means they've accepted it as "just how things are." Sometimes they don't know a solution is possible. And sometimes the pain genuinely isn't that bad. The distinction matters.
Look for evidence of effort. Have they tried workarounds? Spent money? Complained to someone? These are signals that the problem is real enough to act on.
What validation interviews should uncover
Validation interviews are more focused than discovery. You're not exploring broadly. You're testing a specific hypothesis about a specific problem.
A good validation interview helps you understand:
- Whether the person has actually experienced the problem
- How often it happens and in what situations
- What they've done about it: workarounds, tools, or nothing at all
- How much it bothers them relative to other things on their plate
The trick is getting to specifics without leading. You want real stories from their experience, not agreement with your framing. That's harder than it sounds, and it's where most validation interviews go wrong.
Red flags
Vague agreement. "Sure, that's a problem" without concrete examples. People are polite. They'll agree with you to be nice. Push for stories.
No past action. If someone has never tried to solve the problem, not even a clumsy workaround, it's worth digging into why. They might be used to it, or unaware that a solution could exist. But it's a signal worth exploring.
Low frequency. A problem that happens once a year is harder to build a business around than one that happens every week.
Easy substitutes. If existing solutions mostly work, you'll need a strong reason for people to switch. "Slightly better" usually isn't enough.
From evidence to decision
After validation, you should have:
- A verdict: validated, invalidated, or inconclusive
- Evidence: how often, how painful, what people have tried
- Confidence to decide: pursue, pivot, or investigate further
Notice what you've validated: the problem exists and matters. You haven't validated that your solution idea is the right one, or that people will pay for it. Those are separate questions.
When sharing with stakeholders, lead with the verdict and the evidence that supports it. Concrete numbers help: "8 of 12 described this exact problem. 3 have built their own workarounds."
A practical example
Say you suspect that small agency owners struggle to keep track of client feedback across email, Slack, and project management tools. That's your hypothesis.
You talk to twelve agency owners. You ask: "Tell me about the last time a client gave you feedback. Where did it come from? What happened next?"
Eight of them describe some version of the same problem: scattered feedback, missed comments, things falling through cracks. Three have tried building spreadsheet systems. Two are paying for tools that half-solve it.
That's validation. Not certainty, but evidence that you're onto something worth exploring further.