Problem Validation vs Solution Validation: What Founders Need to Test

Problem validation asks whether a meaningful problem exists for a defined group of people. Solution validation asks whether a particular product or service helps those people enough to change behaviour.

They are related, but they are not interchangeable. A well-designed product can fail because the underlying problem is unimportant. A serious problem can remain a poor opportunity because customers prefer an existing alternative or the buying friction is too high.

What problem validation examines

Problem validation investigates the customer’s current reality:

• when and how often the problem occurs;
• who feels the consequences;
• what happens if nothing changes;
• which workarounds exist;
• what time or money is already spent;
• who owns the budget and decision;
• which customers experience the problem most intensely.

The strongest evidence is behavioural. Repeated manual work, paid substitutes, risk controls, switching attempts and escalation to management reveal more than agreement with a founder’s description.

A useful problem statement includes a segment, situation and consequence. “Small retailers need better software” is vague. “Independent retailers lose margin when purchase orders and stock counts diverge, so managers reconcile them manually each week” can be investigated.

What solution validation examines

Solution validation begins after the problem is sufficiently clear. It asks whether the proposed approach fits the customer’s workflow, constraints and buying process.

Evidence can include:

• customers completing a realistic prototype task;
• continued use of a manual or concierge version;
• agreeing to a pilot with named success criteria;
• involving the economic buyer or technical approver;
• sharing data or integrating a system;
• signing a commercial commitment;
• paying.

The closer the test is to the real behaviour required after launch, the stronger it becomes. A clickable prototype tests comprehension and workflow. It does not by itself test willingness to pay, procurement or retention.

The danger of testing both at once

A founder may show a polished product concept and ask, “Would this solve your problem?” The customer is now reacting to the pitch, the design and the desire to be helpful. It becomes difficult to know whether the problem was important before the proposed solution appeared.

Start with the past:

• Tell me about the last time this happened.
• What did you do next?
• Who else became involved?
• What did the workaround cost?
• What prevented you from fixing it?
• Which alternatives did you consider?

These questions produce evidence about behaviour without asking the interviewee to predict the future. The customer-discovery question guide provides a fuller interview structure.

How much problem evidence is enough?

There is no universal number of interviews or mentions. Evidence quality depends on the market, frequency of the problem, customer value and cost of the next step.

You are looking for convergence: different sources and customers describing similar situations, consequences and workarounds. You also need evidence about exceptions. A problem may be severe for one segment and trivial for another.

Define a threshold before collecting more information. For example: three customers in the same segment independently describe the same weekly workaround, and at least one already pays to reduce it. A threshold does not prove the market; it protects you from moving the goalposts after seeing the results.

Move from problem to solution deliberately

Once the problem is clear, write down the constraints the solution must satisfy:

• speed or accuracy required;
• systems it must fit;
• trust and security requirements;
• who must approve it;
• what behaviour must change;
• the value of the outcome;
• the cost of switching.

Then test the smallest version that exposes the biggest risk. If trust is the risk, a polished interface may not matter. If workflow change is the risk, a demo is too weak. If willingness to pay is the risk, a free pilot may produce misleading adoption.

When to return to problem validation

Solution tests often reveal that the original problem framing was wrong. Customers may value a different outcome, use the product in an unexpected situation or refuse to change a deeply embedded process.

That is not failure. Return to the problem evidence, narrow or change the segment and update the hypothesis. Validation is a loop, not a gate that an idea passes once.

Use both forms of evidence

Problem validation reduces the risk of solving something unimportant. Solution validation reduces the risk of building the wrong response. Commercial validation then examines whether the acquisition, price, delivery and retention model can work.

Start with the evidence-based business idea validation guide, then use the market opportunity assessment framework to connect problem, solution and commercial risk.