What does ProductBooks evaluate?

ProductBooks evaluates product decisions across Problem-Solution Fit, Product-Market Fit, and Business Model Fit using evidence-led diagnostic rules rather than narrative optimism.

How does ProductBooks treat missing evidence?

Missing proof does not receive interpretation credit. Evidence gaps remain visible in the system and affect confidence, verdict quality, and risk weighting.

What do PASS, CONDITIONAL, and FAIL mean in ProductBooks?

PASS means the current stage is supported by strong evidence, CONDITIONAL means important proof gaps remain, and FAIL means the layer is unresolved or structurally weak enough to block progression.

ProductBooks system

Most businesses scale before they prove they make money.

Validate problem reality, product pull, and model resilience using evidence-led operational diagnostics before scale, hiring, or fundraising.

StateScanning

ConfidenceEvidence-led

UpdatedCurrent

Run evaluator Open stage one

Takes 3-5 minutesNo setup requiredPrivate

System output

Live doctrine

PASS

Economically sound

Scale with governance

Low risk

CONDITIONAL

Evidence incomplete

Close evidence gaps

Moderate risk

FAIL

Structurally broken

Repair the failing layer

High risk

Diagnostic module

Operational doctrine

This semantic layer explains how ProductBooks evaluates product decisions without changing the evaluator runtime itself.

Methodology

Evidence-led product diagnostics

ProductBooks evaluates operational truth using source evidence, observed behaviour, and stage-specific decision boundaries instead of narrative confidence.

Scoring

Interpretation does not replace proof

Missing proof does not receive interpretation credit. Observed behaviour is weighted above stated intent, and unresolved gaps remain a live risk signal.

Decision system

Pass, conditional, fail

Verdicts reflect confidence, evidence completeness, and risk exposure so founders can see what holds, what fails, and what must be tested next.

Failure patterns

Why most businesses fail to scale profitably

If the problem is weak, later product signals mislead.
If demand is forced, product-market confidence is overstated.
If margins are hidden, the business model remains unproven.
If contribution is not positive, scale amplifies the failure.

ProductBooks system

Problem → Product → Business Model

If one layer breaks, everything above it becomes less trustworthy.

Problem truth

Demand truth

Model truth

Diagnostic module

Evaluator stack

Run the lowest unresolved layer first. ProductBooks does not reward confidence without proof.

Problem layer

Problem-Solution Fit

FAIL

System stateUnresolved

ConfidenceLow

Evidence qualityIncomplete

Risk weightingHigh

Evidence system

Truth test for problem pain and solution pull.

Score 0

Unresolved signals

Problem pain is still unproven.
Solution pull has not been scored.
Real user evidence is still missing.

Next action

Run the stage to test whether the problem is real enough to continue.

Operational recommendation

Do not advance until evidence is generated.

Run evaluator

Product layer

Product-Market Fit

FAIL

System stateUnresolved

ConfidenceLow

Evidence qualityIncomplete

Risk weightingHigh

Evidence system

Truth test for return behaviour, demand, and payment.

Score 0

Unresolved signals

Retention has not been validated.
Demand may still be launch-driven.
Payment behaviour is not confirmed.

Next action

Run the stage once real users exist and repeat behaviour needs to be tested.

Operational recommendation

Do not advance until evidence is generated.

Run evaluator

Model layer

Business Model Fit

FAIL

System stateUnresolved

ConfidenceLow

Evidence qualityIncomplete

Risk weightingHigh

Evidence system

Truth test for margins, founder load, and scale resilience.

Score 0

Unresolved signals

Unit economics are not verified.
Founder dependency may still distort the model.
Scale resilience is still unknown.

Next action

Run the stage before treating growth, spend, or hiring as justified.

Operational recommendation

Do not advance until evidence is generated.

Run evaluator

Diagnostic module

Evidence and verdict rules

Strict inputs only. Missing proof does not receive interpretation credit.

What counts as evidence

Real users with verifiable source material.
Observed behaviour before stated opinion.
Payment or commitment before intent.

What scores zero

Team belief, summary, or interpretation only.
Enthusiasm without behaviour change.
Forecasts used as proof of current demand.

Diagnostic module

Generate the evidence you do not have

Tools exist to improve the score. They do not replace the score.

User Survey Generator

GENERATE

Build behaviour-led surveys that expose real pain and current alternatives.

Improves

Problem existence and frequency evidence.

Generate User Survey

User Interview Generator

GENERATE

Build interview prompts that test pain, context, and failed workarounds.

Improves

Observed problem intensity and user context.

Generate User Interview

Prototype Test Generator

BUILD

Set up low-friction prototype tests that force real reaction instead of polite interest.

Improves

Solution reaction and behavioural validation.

Run prototype test

Diagnostic module

System references

Use the main stages, report, tools, and evidence reference as one linked operational graph rather than isolated landing-page sections.

Stage 1

Problem–Solution Fit

Validate whether the problem is real, painful, and strong enough to justify moving forward.

Problem–Solution Fit

Stage 2

Product–Market Fit

Check whether users return, demand persists, and payment behaviour holds without pressure.

Product–Market Fit

Stage 3

Business Model Fit

Test whether unit economics, cost structure, and founder load support scale.

Business Model Fit

Report

Product Fit Report

Combine stage verdicts, evidence gaps, and next actions into one decision-ready system view.

Product Fit Report

Reference

Evidence Definitions

Use the canonical rules for what counts as proof, what scores zero, and how confidence is interpreted.

Evidence Definitions

Build

All Tools

Generate missing evidence only after a stage identifies the exact proof gap to close.

All Tools

Diagnostic module

Command path

Most teams should start with Problem–Solution Fit.

Validate the problem first. Product and model signals mean less if the foundation is still assumed.

Go to Problem–Solution Fit

Primary action

Run the first stage before you commit more cost.

ProductBooks is built to show what still holds, what fails, and what evidence is still missing.

No persuasion layerSystem output

Run evaluator