Stage 1
If the problem is weak, the product should not advance.
Use this stage to prove the pain is real, specific, and strong enough to justify a solution.
Start here when the problem, buyer pain, or solution pull is still uncertain.
System Flow
Problem → Product → Model
Problem
Problem–Solution Fit
If the problem is weak, every signal above it misleads.
Product
Product–Market Fit
If users do not return, you do not have product–market fit.
Business Model
Business Model Fit
If margins break at scale, the model fails.
If one breaks, everything above misleads
- Product signals are invalid without a real problem.
- Business signals are invalid without real product pull.
Current Stage
Start here when the problem is still uncertain
Problem–Solution Fit
No painful problem. No valid product confidence.
When to use
Before roadmap commitment, before build, and before hiring around the idea.
How ProductBooks works
- Run the evaluator.
- Identify what still scores zero.
- Generate the missing evidence.
- Re-run the same stage before moving on.
What this stage decides
Keep the decision boundary narrow. Everything outside it stays outside.
Decides
Whether a real, painful problem exists for a defined user.
Does not do
Give product advice.
Decides
Whether the proposed solution generates real pull.
Does not do
Improve the idea for you.
Decides
Whether problem and solution fit tightly enough to continue.
Does not do
Help you "pass".
Evidence Rules
Strict rules only. No interpretation layer.
What counts
- Real users who match the target profile.
- Observed behaviour before stated enthusiasm.
What fails fast
- Preference or payment before polite interest.
- Evidence gaps remain a failing condition.
Generate Missing Evidence
Operators generate proof. They do not soften the verdict.
Prototype Evidence Operator
GENERATEExpose real users to a low-fidelity prototype without coaching or explanation.
Used to improve
The scoreable gaps this evaluator surfaced.
Preference Signal Operator
GENERATEForce users to choose between real alternatives and reveal true preference.
Used to improve
The scoreable gaps this evaluator surfaced.
Willingness-to-Pay Operator
GENERATETest whether users accept or reject a concrete paid offer.
Used to improve
The scoreable gaps this evaluator surfaced.
User Pull Operator
GENERATEObserve whether users re-initiate engagement after a pause.
Used to improve
The scoreable gaps this evaluator surfaced.
Run Problem–Solution Fit
Start with evidence you can show. Missing proof still scores zero.
What to do next
Move to Product–Market Fit only after the problem is proven.
Once users show real pull for the solution, test whether they return, pay, and create repeatable demand.
Go to Product–Market Fit