Validating a product idea means confirming, before you build, that real people have the problem you think they have — and that they’ll change what they do to solve it. The fastest way isn’t a survey or a landing page with an email box. It’s a handful of honest conversations plus one or two rough tests that put something in front of the exact person you’re building for. You’re looking for pull: people describing the problem in their own words, asking when they can use it, or trying to pay. Most ideas fail not because the product was bad, but because the problem wasn’t sharp enough or the people who had it weren’t reachable. Validation is how you find that out in days, for the cost of a few coffees, instead of months of building the wrong thing.
Start with the problem, not the product
Before you describe a single feature, write the problem in one sentence: who has it, how often, and what it costs them today. If you can’t name a specific person and a specific moment, that’s the first thing to fix. “Freelancers waste an hour every quote fighting a clunky invoicing tool” is testable. “People want better finance software” is not. A sharp problem tells you exactly who to talk to and what to listen for.
Talk to ten people who actually have the problem
Not ten friends, and not ten people who’d be “happy to give feedback.” Ten people who live the problem. Find them where they already are — a subreddit, a Slack or Discord community, a niche newsletter, people who left reviews on the tool they use now. Keep the conversation about the past, not the future. Hypotheticals like “would you use this?” get you polite yeses. Ask instead:
- Tell me about the last time you ran into this. What happened?
- What did you do to get around it? What did that cost you?
- What have you already tried — and why didn’t it stick?
Stories about real, recent behaviour are worth ten opinions about an imaginary future.
Watch what they do, not what they say
Enthusiasm is cheap; behaviour isn’t. The strongest validation signal is that people are already spending time, money, or effort on the problem — a spreadsheet held together with tape, a subscription to a tool they complain about, a manual workaround they repeat every week. If someone has built their own hack, you’ve found a problem worth solving. If they shrug and say “yeah, that’d be nice,” you probably haven’t.
Put a rough version in front of them
Talk only gets you so far. At some point you need to watch someone try to do the core task. That doesn’t mean a finished product — a clickable prototype, a rough landing page, or even a manual “concierge” version you run by hand will do. The goal is to see where they hesitate, what they misunderstand, and whether they reach the moment of value on their own. A five-minute test where you watch someone get stuck teaches you more than fifty survey responses.
Look for the signals that actually matter
Separate real pull from vanity. Pull looks like: “when can I use this?”, an offer to pay, an unprompted referral, or someone finishing the core task and immediately asking for the next one. Vanity looks like: likes, “cool idea,” sign-ups that never come back, and compliments about the design. Compliments feel good and tell you almost nothing. Chase the behaviour that costs the other person something.
Know when to build, sharpen, or walk away
If a few honest tests produce real pull, build the smallest thing that delivers the core value and get it back in front of the same people. If you get nothing but politeness, don’t assume you need more features — more often the problem needs sharpening or the audience needs narrowing. And sometimes the honest answer is that the pull isn’t there, which is a cheap thing to learn now and an expensive thing to learn after launch.
The hardest part of validation is staying honest when you’re close to the idea. That’s exactly where a few outside eyes help — people who’ll actually use what you put in front of them and tell you where it confuses them, not just that it looks great.