Validation is not a survey where people tell you your idea is nice. Nice is free, and it's the most misleading data you can collect. Real validation is the process of trying hard to disprove your idea and failing — watching people who have the problem take a small, costly action toward your solution when they had every reason to say no. If you go looking for encouragement, you'll find it, and it will fund a year of building the wrong thing.
What you're actually testing
Under every idea sit three assumptions, and they fail in order. First: does a specific group of people have this problem badly enough to notice it? Second: are they already doing something about it — a spreadsheet, a workaround, a competitor, duct tape — that you could replace? Third: will they pay you to make it go away? Most people skip straight to building a product that answers the third question without ever confirming the first two. Validation is just checking those assumptions in the cheapest order possible.
The single most useful reframe: stop asking "would you use this?" and start asking "what did you do the last time you had this problem?" The first is a hypothetical people answer to be polite. The second is a fact about their real behavior — and behavior is the only thing you can trust.
The conversation that tells you the truth
Good validation interviews barely mention your idea. You're a detective, not a salesperson. You find someone who plausibly has the problem and you ask them to walk you through the last time it happened: what triggered it, what they tried, what it cost them in time or money or stress, and how they felt about the fix they settled for. If they describe a painful, recent, recurring problem they've already spent money trying to solve, you're onto something. If they shrug and say it'd be 'nice to have,' you have a hobby, not a business.
People will lie to your face to be encouraging. They will not lie with their calendar, their wallet, or their existing workarounds. Chase the evidence they can't fake.
A practical path from hunch to evidence
- 1Name one person, not a market. Write down the specific human who has this problem — their job, their day, the moment the pain shows up. "Everyone" is not a customer. If you can't picture one real person, that's your first finding.
- 2Find ten to fifteen of them and talk. Not friends, not people who love you — actual sufferers. Ask about their last experience with the problem, never about your solution. Take notes on the words they use; you'll need them later for your landing page.
- 3Look for existing spend. The strongest signal is a problem people already pay to solve badly. A clumsy competitor, a $2,000 consultant, an army of virtual assistants — that's a market with its hand up.
- 4Put a fake front door in front of them. A one-page site describing the offer and a real price, with a button that captures an email or a pre-order. Send a handful of the right people to it. What they click tells you more than what they said.
- 5Ask for a commitment that stings a little. A refundable deposit, a signed letter of intent, ten minutes of their calendar to be a design partner. The size of the commitment they'll make is the truest measure of the pain.
Where validation quietly lies to you
Two failure modes trap smart people. The first is validating a vitamin — a mild, occasional annoyance people agree is real but would never reorder their week to fix. It'll pass every friendly interview and still not sell, because nobody buys a solution to a problem they've comfortably lived with for years. The second is over-validation: running interview after interview because talking is safer than shipping. At some point more conversations stop teaching you anything and become a way to avoid the risk of building. The goal is enough evidence to justify the next small bet, not certainty. Certainty doesn't exist here, and waiting for it is its own way of failing.
There's also a class of idea that resists cheap validation — regulated products, marketplaces that need both sides at once, things whose value only appears at a scale you can't fake in a weekend. For those, validation shifts to the mechanism: can you hand-assemble a tiny version, serve five customers manually, and prove the unit economics before you automate anything? If even a manual, ugly version can't win five people, no amount of polished software will.
When the evidence is finally there — real people, real pain, real commitments — the bottleneck usually becomes turning it into working software without quitting your job to do it. That's the part we help with: taking a validated idea from a founder who has the customers and the domain knowledge but not the engineering, and building and running the product with them. Do the validation first, though. It's the cheapest work you'll ever do, and it decides whether everything after it is worth doing at all.
Common follow-up questions
How many customer interviews are enough to validate an idea?
There's no magic number, but patterns usually emerge by the tenth to fifteenth conversation with people who genuinely have the problem. If the same pain, the same workaround, and the same trigger keep showing up, you've heard enough to act. If every conversation sounds different, you haven't found a tight enough audience yet — narrow who you're talking to before you talk to more of them.
Can I validate an idea without talking to anyone?
Partly. A landing page with a real price and paid traffic tells you whether the offer earns clicks and emails, and that's genuine behavioral data. But it can't tell you why people didn't convert or what they'd actually pay. Numbers show you what's happening; conversations tell you why. Serious validation uses both, and the interviews usually come first so you know what to put on the page.
What's the difference between validating the problem and validating the solution?
Validating the problem confirms that people have a painful, recurring need worth money — that comes first and is done through interviews and evidence of existing spend. Validating the solution confirms that your specific approach actually removes that pain, which you test with a landing page, a mockup, or a hand-built version. Founders who skip problem validation often build an elegant solution to something nobody urgently needs.
Want this answered for your exact situation?
We build and co-found software for people who have the idea and the network but not the technical team. Tell us where you're stuck and we'll give you a straight read — even if the honest answer is "don't build it yet."
See how we work