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.
Diagnostic module
Stage doctrine
This static explanation layer clarifies the methodology around the Problem-Solution Fit evaluator without changing evaluator logic, inputs, or scoring behaviour.
Methodology
Operational truth before build confidence
Problem-Solution Fit tests whether pain and solution pull are observable in real users before the team commits roadmap, hiring, or product narrative to the idea.
Scoring
Observed behaviour outranks opinion
ProductBooks weights source evidence, forced preference, payment, and real re-engagement above stated intent, encouragement, or founder interpretation.
Decision boundary
Do not move up without proof
If the problem is still assumed, later product and model signals become less trustworthy. Missing proof remains a block, not a soft warning.
Diagnostic module
Problem to Product to Business Model
The system advances upward only when the lower layer holds under evidence.
Problem
01Problem–Solution Fit
If the problem is weak, every signal above it misleads.
Product
02Product–Market Fit
If users do not return, you do not have product–market fit.
Business Model
03Business Model Fit
If margins break at scale, the model fails.
If one layer breaks, every layer above it becomes less trustworthy.
- Weak problem evidence invalidates product confidence.
- Weak product pull invalidates business confidence.
Diagnostic module
Current Stage
Start here when the problem is still uncertain
Problem layer
Problem–Solution Fit
System state
Current layer
Evidence quality
In review
Risk weighting
Moderate
Operational recommendation
No painful problem. No valid product confidence.
Next action
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.
Diagnostic module
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".
Diagnostic module
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.
Diagnostic module
System references
Move from the current stage to the report, evidence definitions, or tools without breaking the ProductBooks stage order.
Diagnostic module
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.
Improves
The scoreable gaps this evaluator surfaced.
Preference Signal Operator
GENERATEForce users to choose between real alternatives and reveal true preference.
Improves
The scoreable gaps this evaluator surfaced.
Willingness-to-Pay Operator
GENERATETest whether users accept or reject a concrete paid offer.
Improves
The scoreable gaps this evaluator surfaced.
User Pull Operator
GENERATEObserve whether users re-initiate engagement after a pause.
Improves
The scoreable gaps this evaluator surfaced.
Primary action
Run Problem–Solution Fit
Start with evidence you can show. Missing proof still scores zero.
Diagnostic module
Command path
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