Problem–Solution Fit

Evaluates whether a real, painful problem exists and whether the proposed solution is meaningfully desired.

About this assessment

Problem-Solution Fit is the first stage of the ProductBooks evaluation framework. It determines whether the problem you are solving is real, painful, and experienced by a defined user group, and whether the proposed solution generates genuine desire. Most product failures begin here: teams build solutions for problems that are assumed rather than validated. This evaluator forces that validation before resources are committed.

Run Problem–Solution Fit Evaluator

Evaluators apply strict evidence definitions.
Evidence that does not meet the definitions scores zero.

Typical evaluation flow

Typical flow

  1. 1Evaluate
  2. 2Identify missing evidence
  3. 3Generate evidence via operators
  4. 4Re-evaluate

Optional overview (3 min)

When to use this assessment

Use the Problem-Solution Fit evaluator when you are in the earliest stages of product development and need to determine whether your core assumptions hold up against real evidence. This assessment is critical before committing to a solution direction, roadmap, or product build.

  • You have a product idea but have not yet validated the underlying problem
  • You have spoken to users but are unsure if the evidence is strong enough
  • You need to decide whether to proceed, pivot, or stop before investing further

Evaluation scope

Decides

Whether a real, painful problem exists for a defined user

Does not do

Give advice

Decides

Whether the proposed solution is genuinely desired

Does not do

Improve your idea

Decides

Whether the problem and solution meaningfully fit together

Does not do

Help you "pass"

Evidence requirements

  • Evidence must come from real users
  • Behaviour outweighs opinion
  • Preference outweighs enthusiasm
  • Willingness to pay outweighs intent
  • Missing evidence scores zero
View full Evidence Definitions →

Interpreting your results

A high Problem-Solution Fit score means you have demonstrated, through verifiable evidence, that a real problem exists for a defined user and that your proposed solution generates genuine desire. A low score does not mean your idea is bad. It means the evidence is not yet strong enough to justify further investment.

The evaluator identifies specific evidence gaps so you know exactly what to test next. Use the operators below to generate the missing evidence, then re-run the evaluator to see how your score changes. This iterative process is how teams build confidence in their product decisions before committing resources.

How missing evidence is generated

If required evidence is missing, ProductBooks uses controlled operators to generate it.

Operators generate evidence. They do not decide fit.

Prototype Evidence Operator

Generates scoreable evidence by exposing real users to a low-fidelity prototype without coaching or explanation.

Run operator

Preference Signal Operator

Forces users to choose between real alternatives to produce unambiguous preference or rejection signals.

Run operator

Willingness-to-Pay Operator

Tests real economic commitment by asking users to accept or reject a concrete paid offer.

Run operator

User Pull Operator

Observes whether users re-initiate engagement without prompting after a pause.

Run operator

Pain Priority Operator

Forces users to rank the tested problem against competing priorities under real constraints.

Run operator

Once you have validated Problem-Solution Fit, the next step in the ProductBooks cascade is to evaluate whether your product achieves repeatable demand and retention. You can proceed to the Product-Market Fit assessment to determine whether users adopt and return without external prompting.

If you have completed all three stage evaluations, use the Fit Report Generator to produce a single, investor-grade summary of your product's current state.

Learn more about validating product ideas in our article on what Problem-Solution Fit really means.

Evaluator contract: This evaluator applies definitions strictly. Disputes do not change scoring.