Problem validation begins with a customer situation, not a product idea
Problem validation tests whether a defined group experiences a meaningful difficulty in a particular context. It examines what triggers the situation, what the customer is trying to accomplish, what prevents progress, what the consequences are and how the customer responds today.
A product idea often bundles several assumptions: who the customer is, which problem matters, how it should be solved and why someone would buy. Separating these assumptions makes the research easier to interpret.
A problem is not validated because people understand your description. It becomes credible when relevant customers independently describe the situation, consequences and current action.
Problem, symptom, cause and solution are different
Symptom
The visible effect: delays, errors, lost sales, frustration or manual work.
Problem
The obstacle preventing a customer from achieving an important outcome.
Cause
The conditions producing or sustaining the problem.
Solution
A proposed way to change the situation; one of several possible responses.
Do not assume that the first symptom reveals the root cause or that your proposed solution addresses the reason customers fail to act.
Write a testable problem assumption
A useful problem assumption names the customer, situation, desired outcome, obstacle, consequence and present response. Keep the proposed product out of the statement.
When [defined customer] is trying to [desired outcome] in [specific situation], they encounter [obstacle], which leads to [meaningful consequence]. Today they respond by [current behaviour or alternative].
Weak: solution hidden inside the problem
“Small manufacturers need an AI forecasting platform.” This assumes both the need and the form of the answer.
Stronger: observable situation
“Production planners at small manufacturers repeatedly adjust purchase plans manually when demand changes, causing avoidable shortages, excess stock or urgent expediting.” This can be investigated without asking anyone to approve a product concept.
Define what would weaken the assumption
Before research, state disconfirming evidence: the situation is rare, consequences are minor, the intended role is not responsible, existing tools are adequate, nobody acts, or the problem occurs only under conditions too narrow for the intended business.
A practical customer problem validation process
- Define the commercial decision.State what investment, direction or solution work the research must inform.
- Choose the initial customer group.Use role, organisation, context, experience and situation—not only demographics.
- Write the problem assumption.Describe the outcome, obstacle and consequence without embedding the product.
- List competing explanations.Consider other causes, segments and reasons for the observed symptom.
- Set evidence criteria.Decide what would support, weaken or leave the assumption unresolved.
- Recruit relevant participants.Select people with recent direct experience or decision authority.
- Interview about real events.Reconstruct triggers, actions, consequences, alternatives and decisions before presenting a solution.
- Compare patterns and differences.Analyse roles and segments separately where their experience or incentives differ.
- Test consequential behaviour.Look for time, spending, workarounds, escalation, switching attempts or another response.
- Decide the next step.Proceed to solution testing, refine the problem or segment, investigate uncertainty, or stop.
Problem validation interview questions
Use a semi-structured guide. Ask the same core themes across interviews, then follow the participant’s concrete experience with neutral probes.
Situation and trigger
- Tell me about the last time this happened.
- What triggered the situation?
- How often does it occur?
Goal and workflow
- What were you trying to achieve?
- Walk me through what you did.
- Who else was involved?
Obstacle and consequence
- Which part was most difficult?
- What happened because of it?
- How did you assess the impact?
Current response
- How did you handle it?
- What tools, services or workarounds did you use?
- What did the response cost?
Attempts to change
- What have you already tried?
- Why did you choose or reject those alternatives?
- What prevented a better outcome?
Decision conditions
- What would make this worth changing?
- Who would decide and fund the change?
- What evidence would they require?
Avoid “Would you use…?”, “Do you need…?” and “Is this a good idea?”. These questions pull the discussion toward your solution and hypothetical agreement. See the complete customer discovery interview guide.
How to judge whether the customer problem is validated
| Evidence area | Stronger signal | Warning sign |
|---|---|---|
| Recurrence | Similar recent events appear across the intended segment | The issue is isolated or only recognised after prompting |
| Consequence | Time, money, risk, delay or missed opportunity can be described | The consequence is vague or negligible |
| Behaviour | Customers act, spend, escalate or create workarounds | They agree verbally but do nothing |
| Alternatives | Current options leave an important gap | An adequate alternative already resolves the situation |
| Ownership | A user, buyer or responsible function can be identified | No one owns the outcome or budget |
| Access | Relevant people can be reached repeatedly | The presumed market cannot be accessed |
| Buying conditions | A credible trigger, process and reason to change exist | Interest cannot progress toward a decision |
Do not reduce validation to a vote
Ten people agreeing that a problem exists may be less valuable than five detailed accounts from the right role. Evidence quality depends on participant relevance, specificity, consequences and the decision being made. Contradictions may reveal a separate segment or a flawed assumption.
Move to solution validation deliberately
Once the problem and customer are credible, test whether a concept produces the promised outcome and fits the workflow, technical environment and buying process. Keep problem evidence separate from reactions collected after showing the solution.
For the wider evidence mix, read Market validation: process, methods and examples. For the scope question, read how many customer interviews are enough.
Frequently asked questions
Questions about problem validation
What is problem validation?
Problem validation is the process of gathering evidence that a defined customer group repeatedly experiences a specific problem, that the consequences matter, and that the problem is important enough to influence behaviour or a commercial decision.
How do you validate a customer problem?
Define the customer and context, state the problem assumption without embedding a solution, interview relevant people about recent real events, examine consequences and current alternatives, compare evidence across the segment and test whether the problem leads to credible action or commitment.
What questions should you ask in a problem validation interview?
Ask about the last time the situation occurred, what triggered it, what the person did, which part was difficult, what the consequences were, how they handle it today, what they have tried and who decides whether to change the current approach.
How many interviews are needed for problem validation?
There is no universal number. The scope depends on the focus of the question, participant relevance, segment diversity and how much new decision-relevant evidence each interview adds. The standard Test Before You Build project includes 20 interviews, while broader projects can be scoped separately.
What is the difference between problem validation and solution validation?
Problem validation investigates whether the customer, problem, consequences and current behaviour are credible. Solution validation tests whether a proposed concept can produce value and fit the workflow. Understanding the problem first prevents a polished concept from steering the evidence.
When is a customer problem strong enough to pursue?
A stronger problem recurs in the intended segment, produces meaningful consequences, prompts action or spending, has identifiable triggers and decision-makers, and remains insufficiently solved by current alternatives. The required evidence should match the size and reversibility of the investment.
Independent problem validation
Know whether the problem deserves a solution before you build it.
The standard project includes target definition, approximately 30–40 suitable prospects for client approval, recruitment, 20 interviews, transcripts, evidence analysis, a written report, recommended changes and a BUILD, CHANGE or KILL recommendation.
Fixed price: €2,900 + VAT. Typical timeline: approximately 2–4 weeks. Larger and multi-segment projects can be scoped separately.
Submit your idea
About the author
Dr. Kari Jääskeläinen
Dr. Kari Jääskeläinen is an entrepreneur, business leader and consultant with experience in market validation, technology commercialisation, business development and sales. He has worked on around 200 commercialisation and consulting projects and has made approximately 2,000 sales calls a year.
Read about Dr. Kari Jääskeläinen’s experience →Sources and further reading
- Harvard Business School Rock Center for Entrepreneurship. Customer Discovery Basics.
- U.S. National Science Foundation. NSF I-Corps.
- DeJonckheere, M. and Vaughn, L. M. (2019). Semistructured interviewing in primary care research.