Learn
Use learning to improve stage decisions, not replace them.
Every article explains a rule inside the ProductBooks system: Problem, Product, then Business Model.
Read the rule. Then run the stage.
Diagnostic module
Learning doctrine
The learning layer exists to make ProductBooks methodology more legible to people, search engines, and LLMs without changing product behaviour.
Purpose
Explain the scoring philosophy
Learning content clarifies how ProductBooks interprets evidence, confidence, and risk so teams can read the decision boundary before they try to clear it.
Method
Operational doctrine over opinion
Each article is written to explain stage order, behavioural validation, and why missing proof remains visible instead of being softened by interpretation.
Boundary
Doctrine does not override runtime
The learning layer is static and server-rendered. It does not rewrite evaluator output, change client state, or alter command-layer behaviour.
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
Read by decision point
Use these guides when a stage verdict is unclear or a signal still feels easy to misread.
Foundations
What is Problem-Solution Fit?
Understanding the first stage of product validation: why most products fail because the problem was never validated, and how to avoid that mistake.
Read articleFoundations
Why Products Fail Before Achieving Market Fit
The common patterns that cause products to stall between early adoption and real product-market fit, and what evidence you need to progress.
Read articleBusiness Model
Founder Dependency Risk: Why Your Business Breaks Without You
How to identify and measure the risk that your business depends on the founder for revenue generation, delivery, and core operations.
Read articleGrowth
Go-to-Market Validation: Evidence Before Execution
Why go-to-market strategies fail without validated demand, and how to test your acquisition and monetisation assumptions before committing budget.
Read articleFrameworks
Evidence-Based Product Decisions: A Framework for Founders
How to replace assumptions with evidence at every stage of product development, using structured evaluation methods.
Read articleDiagnostic module
System references
Use learning alongside the evaluators, report, tools, and evidence reference so doctrine and execution stay connected.
Diagnostic module
Command path
Learning does not replace evaluation.
Once the rule is clear, return to the stage that matches it and test the current evidence directly.
Go to Problem–Solution FitPrimary action
Start with the stage that still needs proof.
Read enough to sharpen the judgment, then run the evaluator that decides it.