How to run problem validation before you build

What problem validation actually is

Problem validation is the work of proving that a problem is real, frequent, and painful enough that people will pay to solve it — before you build the thing that solves it. It replaces the founder's private conviction with public evidence from the people who live with the problem.

Two ideas get collapsed, and separating them is the whole discipline:

• Problem validation asks: is this problem worth solving at all?
• Solution validation asks: does my specific answer solve it?

You do them in that order. A beautifully built solution to a problem nobody actually has is the most common way early startups die, and the cruelest, because every line of code works. The market does not reject your engineering. It rejects your premise.

Why conviction is not evidence

Founders start with a story about a problem. The story is usually where the idea came from — a personal frustration, a pattern noticed at a past job, a complaint heard twice. That origin is valuable as a hypothesis and dangerous as a conclusion.

The trouble is that conviction feels like knowledge. You have thought about the problem for months, so it seems obvious that others feel it as sharply as you do. Validation exists to make the problem falsifiable — to give it a real chance to fail before you spend a year proving it right.

The test is simple: could a set of interviews change your mind? If no evidence would move you, you are not validating. You are collecting quotes to decorate a decision you already made.

Not every real problem is worth solving

A problem can be genuinely real and still not carry a company. Validation is not only asking does this problem exist — it is asking does it exist in a form worth building against. Four tests separate a problem you can build on from one you should walk past.

• Severity — how much the problem costs when it happens. A problem that wastes an afternoon is weaker than one that loses a customer or a deal. Grade the pain by what it destroys, not by how often people mention it.
• Frequency — how often it recurs. A severe problem that happens once a year is hard to build a repeatable business on; a severe problem that happens every week compounds into budget.
• Urgency — whether the people who have it are already trying to fix it. A problem people are actively searching to solve is a market. A problem they have quietly accepted is a lecture you will have to fund.
• Willingness to pay — whether solving it is worth money to someone with the authority to spend it. A painful problem owned by a person with no budget is a problem you cannot sell into.

The strongest problems clear all four: severe, frequent, urgent, and attached to a budget. This is the bar the interviews are trying to measure against — and it is why "everyone agrees it's annoying" is not validation. Annoyance fails severity and urgency at once.

Turn the idea into a hypothesis you can disprove

A validatable problem statement names four things:

• Who has the problem — a specific, reachable segment, not "businesses."
• What the problem is — the concrete situation, in their words.
• How often it happens — daily, monthly, once a quarter.
• What it costs them today — in money, time, or risk.

Write it as one sentence you could be wrong about. "Finance teams at Series B startups reconcile vendor invoices by hand every month, and it costs two days per close." That is falsifiable: if finance teams already automate this, or do not care about two days, the claim breaks. "Businesses want to save time" is not a hypothesis. Nothing could disprove it, which is exactly why it is useless.

Map the goal, the current process, and where it breaks

The hypothesis names the problem. The next step is to understand the situation the problem lives in, because a problem only makes sense against the goal it blocks and the process people already run to reach that goal.

Work it in three passes, in order:

1. The goal. Name the outcome the customer is trying to reach — the thing they would still want even if your product never existed. "Close the books accurately by the fifth business day," not "use accounting software."
2. The current process. Write out, step by step, how they reach that goal today. Be concrete enough that a stranger could follow it. This is where the real problem usually surfaces — not in a single dramatic pain, but in a process that is more manual, more fragile, or more expensive than anyone had described.
3. The pains. Now mark where the process breaks: the steps that take too long, fail silently, need a second person, or get redone. These are the candidate pains, and they are more trustworthy than pains people volunteer, because you derived them from behavior they walked you through.

Mapping the process does two things at once. It grounds the problem in something observable, and it exposes the existing workarounds — the spreadsheet, the manual check, the person whose job is to catch the failure. Every workaround is a piece of evidence: someone already found the problem expensive enough to build a defense against it.

Name the root pain, not the surface symptom

The problem people describe first is usually a symptom. Behind "the report is always late" is "I cannot trust the numbers," and behind that is "I get blamed when the forecast is wrong." Validation that stops at the surface symptom builds a faster report; validation that reaches the root pain builds something people fight to keep.

Two disciplines get you there.

Write the problem in the buyer's language, not the product's. "Manual invoice reconciliation" is your framing; "I spend the last two days of every month afraid I missed a duplicate" is theirs. The buyer's words are what you will later test messaging against, so capture them exactly, in quotes, as they are said.

Quantify the cost of inaction. A problem worth solving has a price attached to leaving it alone — hours lost, revenue leaked, risk carried, deals slowed. Push each interview until the cost is a number or a concrete consequence, not an adjective. "It's a big problem" is not a cost. "It's two people, two days a month, and one missed error last quarter cost us a client" is. The cost of inaction is what your solution will eventually be measured against, and a problem with no quantifiable cost is a problem no one will pay to remove.

Run interviews that produce evidence, not agreement

The interview is where validation lives or dies, and the failure mode is asking questions that fish for a yes.

Ask this	Not this
"Walk me through the last time this happened."	"Would you use a tool that fixed this?"
"What do you do about it today?"	"Does this sound useful?"
"What have you already tried or paid for?"	"Would you pay for this?"
"How much time did that cost you last month?"	"Is this a big problem for you?"

The left column asks about past behavior, which is evidence. The right column asks about future intent, which is flattery — people say yes to be pleasant, then never buy. A rule worth keeping: the moment you describe your solution, the interview stops being research and becomes a pitch. Hold your idea back until the very end, if at all.

Recruit ten to fifteen people who genuinely fit the segment. Not friends, not your network's easy yeses — those people agree because they like you. You need strangers who have the problem, reached through communities, referrals, and cold outreach.

Interviews are the core method, not the only one

Interviews are the spine of problem validation because they let you follow a pain to its root in real time. But they are one instrument among several, and the strongest validation triangulates — it confirms in a conversation what it first saw in behavior somewhere else.

Method	What it gives you	What it cannot do
Customer interviews	Depth: the goal, the process, the root pain, in the buyer's own words	Scale, and protection from your own leading questions
Shadowing sales, support, and success calls	The problem as it surfaces unprompted, when no one is performing for a researcher	Reach beyond the customers you already have
Surveys	Breadth: whether a pattern from ten interviews holds across a hundred people	Nuance — a survey cannot ask the follow-up question
Reviews and community complaints	Unsolicited pain, written by people with no reason to flatter you	Certainty that the complainer is in your reachable segment
Product usage and analytics	What people actually do, stripped of what they say they do	The why behind the behavior
Internal experts — sales, support, success	The objections and pains the front line already hears every week	Freedom from internal bias about what the problem "is"

Desk research — reviews, search behavior, competitor traction — is genuinely useful, and it is where most validation should start, because it is cheap and it narrows the field. But it tells you a problem exists somewhere, not that it is acute for the segment you can actually reach and sell to. The interviews are what confirm the target. Skipping them is how you validate an illusion at scale.

Find the pattern, and know when you've heard enough

A single vivid interview is a story, not evidence. The work of validation is separating what recurs across conversations from what one memorable person happened to say. Do it deliberately: transcribe every call, then tag the transcripts for recurring pains, workarounds, and the triggers that made the problem urgent that week.

Two counts matter more than any quote:

• How many people described the same pain — the pattern, not the anecdote.
• How many of them did something about it — the workaround, the spend, the assigned person. This is the number that separates a real problem from a popular complaint.

The stopping rule is saturation, not a target count. When three interviews in a row surface no new pain, no new workaround, and no new objection, you have heard the pattern and more conversations will only confirm it. Fewer than five interviews is anecdote. Running past twenty is usually a sign you are avoiding the decision the pattern already points to — collecting more evidence to postpone a verdict you can already read.

Grade the signal by what people do

Not all evidence weighs the same. Rank it by cost of the behavior — what someone has already given up tells you far more than what they claim they would give up.

• Strongest — they already pay for a workaround, built a spreadsheet, or assigned a person to the problem. Money and effort are spent. The problem is real and budgeted.
• Medium — they describe a clear, repeated pain and an active workaround, but nothing spent yet. Real problem, unproven willingness to pay.
• Weak — they agree the problem is annoying, but do nothing about it. Interest without action. This is the signal most founders mistake for validation.

A demand signal is any observable behavior that shows the problem is costing someone something now. Grade the whole set — strong, mixed, or weak — and be honest about which column most of your evidence sits in.

The strongest signal is a commitment made before you build

Grading tells you how strong the existing evidence is. There is one more test available, and it is the most honest one: ask for a commitment before the product exists. What people do when a real ask is on the table beats anything they say in an interview.

Three asks, in rising order of proof:

• A waitlist with a cost attached. Not an email address — those are free and mean little. Require something that takes effort: a booked call, a completed intake form, a stated budget. Intent that costs nothing proves nothing.
• A design partner commitment. Ask the people with the strongest signal to commit — in writing or on a call — to using and shaping the thing before it is built. A yes here is worth more than ten enthusiastic interviews, because it is given with something at stake.
• A concierge test. Deliver the outcome by hand, manually, for one or two customers, before you automate anything. If they will not accept the outcome even when you do all the work invisibly, no amount of engineering will make them want it. If they will, you have validated demand and learned exactly what to build.

None of these is building the product. All of them are cheaper than building the product, and each one converts a warm opinion into a behavior you can grade. A "build" verdict backed by a committed design partner is a different thing than a "build" verdict backed by nodding.

The output: a discovery plan and a signal grade

Validation ends in an artifact, not a feeling. The discovery plan is the written record of the test, and it has a fixed shape:

• Goal — the problem hypothesis you set out to test, written so it could fail.
• Segment — the specific, reachable group you targeted.
• Who you talked to — the actual people you interviewed, and how you reached them.
• Evidence heard — what they said and, more tellingly, what they had already done about the problem.
• Pattern — what recurred across the conversations once the one-offs are set aside.
• Verdict — the signal grade, and the decision it points to.

The signal grade is that one-line verdict, and it points to one of three decisions:

1. Build — strong signal, a reachable segment, evidence of spend. Proceed to scoping a minimum viable product.
2. Pivot — the segment has a real problem, but not the one you assumed. Rewrite the hypothesis and re-test. This is a success, not a failure; you found the true problem before building the wrong thing.
3. Stop — weak signal across the board. People dislike the problem but do nothing about it. Save the year.

The discovery plan is also the thing you hand your next self. Six months on, when the roadmap drifts, it is the record of why you chose this problem — and the standard the drift has to argue against.

What weak validation looks like from the inside

The dangerous state is not "no signal." It is a warm signal that never converts to behavior — friendly interviews, lots of nodding, "this is definitely a problem," and not one person who has spent a dollar or an hour on it. That warmth feels like traction. It is the sound of people being nice.

The discipline is to keep asking "and what did you do about it?" until the answer is either a real workaround or an admission that they did nothing. The second answer is not a rejection of you. It is the cheapest lesson your company will ever buy, delivered before you wrote a line of code.