Validate the problem

Problem validation gathers evidence that a particular group faces a problem important enough to investigate. It examines real situations, consequences and current workarounds before assuming that your proposed solution deserves building.

Use the methods above to understand the problem. A positive interview is not approval for a feature, and a small recruited group cannot establish how common the problem is across a market.

Choose a problem-research method

Interviews and observation can reveal what you have missed. A survey needs a clear question and an appropriate sample; sending it to supportive contacts does not make the result representative.

Ask about a recent event

Teresa Torres’s customer-interview guide emphasizes learning about people’s goals, needs and context. Invite a specific account rather than asking someone to predict whether they would buy your idea.

Useful prompts include:

• Tell me about the last time this happened.
• What were you trying to accomplish?
• What did you do next, and what did you use?
• What happened because of the problem?
• What have you already tried to change?

Follow the account before introducing your solution. Do not treat every recalled detail as verified fact: distinguish what someone reports from what you observed or checked in records. With permission, ask to see an artifact that helps explain the situation.

Problem validation example: a stock shortage

This shop-owner scenario is invented to illustrate the method. A team is considering a weekly stock-report service. Instead of asking whether a dashboard sounds useful, it asks an owner about the last time stock ran out.

The account describes an event, a workaround and a consequence. It suggests questions about lead times and how ordering decisions are made. It does not show that the owner wants a weekly report, that software would prevent the shortage, or that enough other shops share the situation.

Compare accounts from relevant people, including those who cope successfully or do not experience the expected problem. Record exceptions instead of discarding them because they weaken the pitch.

Decide what to investigate next

Write down the user group, situation, current response, consequence and source for each observation. Separate recurring findings from isolated stories and interpretations. Choose a bounded next action, such as observing an ordering task or investigating an overlooked customer group.

If the proposed solution is the uncertainty, use Validate the product. If reach and demand are unclear, use Validate the market. Payment requires its own willingness-to-pay checks.

There is no universal interview count that certifies a problem. Match the evidence to the decision and the cost of being wrong. Use Product Experimentation to connect the research to a test plan and the Validation Patterns overview to choose another method.