Problem Validation

How to tell whether a problem is real and painful enough to matter.

Start · 6 min

What is this?

Problem validation is the step after customer discovery: deciding, based on what you've actually heard, whether the problem is real, common, and painful enough that people will change behavior — or pay money — to solve it.

A problem can be real without being validated. Plenty of real annoyances aren't painful enough for anyone to do anything about.

Why it matters

Investors and your own future self will ask "why would anyone change what they're doing today?" A validated problem gives you a real answer. An unvalidated one means you're guessing, and guessing is expensive once you start building.

What you're trying to learn

Learn whether the problem is frequent, costly, and urgent enough that someone will actually change behavior — or pay — to fix it.

Before you start

Have your Customer Discovery notes on hand — problem validation works from real conversations you've already had, not fresh guessing.
Write the problem down in one sentence from the customer's point of view, before you look for evidence either way.
Decide who actually owns this problem day-to-day, and separately, who controls the budget that would pay to fix it — they're not always the same person.

Step by step

1Write down the problem in one plain sentence, from the customer's point of view, not yours.
2Identify what people currently do instead — including "nothing" or "a spreadsheet," which are real competitors.
3Look for evidence of existing effort: are people already paying for a workaround, cobbling together tools, or complaining publicly?
4Ask how often the problem happens and how much time or money it costs when it does.
5Separate "annoying" from "painful enough to act on" — painful problems usually already have some kind of (imperfect) workaround being paid for.

What to ask / do

How often does this happen — daily, weekly, monthly, rarely?
What do you currently do instead? (Include "nothing" and "a spreadsheet" as real, valid answers.)
How much time does it cost when it happens? How much money, directly or indirectly?
Has anyone on your team tried to fix or work around this before? What did they try?
What happens if this just never gets solved — what's the actual consequence of doing nothing?
Who would need to say yes to pay for a fix, and who would actually use it day to day?

What the signal looks like

Good signal

The same problem, described independently, comes up across multiple unrelated conversations.
People are already paying for an imperfect workaround (a tool, a consultant, an extra hire) to deal with it.
They describe visible urgency — a deadline, a recurring fire drill, a real cost they can name.
The person you're talking to also controls (or has real influence over) the budget to fix it.

Weak or negative signal

"That's interesting" or "I could see that being useful" with no specific example of it happening.
General enthusiasm that isn't tied to anything they've actually done or spent money on.
The problem only comes up when you ask directly — nobody mentions it unprompted.
The person describing the problem has no real ability to pay for or approve a fix.

Common mistakes

Validating that the problem exists, without validating that it's painful enough to pay for.
Assuming a big total market means the problem is validated for your specific first customer.
Confusing your own frustration with a widely-shared one.
Skipping this step because the idea "obviously" solves a real problem.

Checklist

You can state the problem in one sentence, from the customer's perspective.
You know what people currently do instead of a solution like yours.
You have evidence people already spend time or money working around this problem.
You can estimate roughly how often and how painfully this problem occurs.

You're done when: You can state the problem in one sentence from the customer's perspective, back it with a real workaround people already pay time or money for, and say roughly how often and how painfully it occurs.

What to do next

If the problem looks real and painful: move toward MVP / Prototype Validation to test whether your specific solution actually helps.
If it looks real but not painful enough to act on: that's a legitimate finding — reconsider scope or audience before building.
Use Record What I Learned on the related Mission to capture what you found. This step alone updates your model — reading this playbook does not.