Evidence-Based Product Decisions: A Framework for Founders

The problem with assumption-driven development

Most product development is driven by assumptions. Teams assume the problem exists because it seems logical. They assume the solution is desired because early conversations are positive. They assume the market is large because industry reports say so. Each assumption introduces risk, and the risks compound as the product progresses.

The alternative is evidence-based product development: a systematic approach to testing each critical assumption before committing the resources that assumption would justify. This is not about being slow or cautious. It is about being precise about what you know and honest about what you do not.

What counts as evidence

Not all information is evidence. In the ProductBooks framework, evidence must be externally verifiable, must originate from real users who match the defined target profile, and must demonstrate observable behaviour, stated preference, or measurable outcome.

• Recorded user interviews with timestamps and participant consent qualify as evidence
• Payment receipts and transaction logs qualify as evidence
• Paraphrased summaries without source material do not qualify
• Beliefs or assumptions from the team do not qualify
• Projected future behaviour without historical data does not qualify

The full classification system is documented in the ProductBooks Evidence Definitions, which serve as the canonical reference for all evaluators.

The Product Fit Cascade

ProductBooks organises product validation into three sequential stages, each building on the evidence from the previous stage. This is the Product Fit Cascade:

1. 1
   Problem-Solution Fit validates that a real problem exists and the solution is desired. This must be established before anything else.
2. 2
   Product-Market Fit validates that users adopt, retain, and pay without external prompting. This depends on Problem-Solution Fit being established.
3. 3
   Business Model Fit validates that the economics support sustainable operation. This depends on both previous stages.

The order is enforced because each stage depends on the evidence from previous stages. Attempting to validate Business Model Fit without Product-Market Fit produces unreliable results.

The iterative validation process

Evidence-based product development is not a one-time assessment. It is an iterative process: evaluate, identify evidence gaps, generate the missing evidence, and re-evaluate. Each cycle produces a clearer picture of where your product stands.

ProductBooks provides operators for each stage that help you generate missing evidence through controlled methods. These are not advice tools. They are structured research protocols designed to produce scoreable evidence.