Chapter 1
Choose a real problem
Define the customer, the decision they face and evidence that the problem is worth solving.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Interview five suitable users and record differences, not just agreement. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.
Chapter 2
Name the operator
Separate brand, legal entity, trading name, ownership, contracts and data roles.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Create a one-page identity map before publishing or selling. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.
Chapter 3
Design the offer
Set outcomes, scope, exclusions, acceptance, price logic and change control.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Write one offer that a stranger could accept without guessing. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.
Chapter 4
Build the minimum operating system
Assign delivery, quality, complaints, security, records and improvement responsibilities.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Run a tabletop delivery from enquiry to close-out. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.
Chapter 5
Test safely
Use research, simulation or a bounded pilot appropriate to risk.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Agree stop conditions before the first live test. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.
Chapter 6
Show honest evidence
Attribute founder experience, partner evidence and organisational delivery correctly.
Why this matters
A strong result begins with an explicit decision and a proportionate evidence boundary. Record what is known, what is reported by another party, what is inferred and what remains untested. This prevents enthusiasm, seniority or polished presentation from being mistaken for operating proof.
Do the work
Remove every claim that cannot be traced to a named source. Name the owner, affected people, dependencies, risk and review date. Where another organisation or person is involved, confirm their role, permission and expectations rather than assuming agreement.
Review questions
- What decision will this evidence support?
- Whose experience, data or opinion is it?
- What could make the conclusion inaccurate or unsafe?
- What is the smallest useful next test?
- Who can challenge or approve the result?
Practical checkpoint
Do not move on because a document exists. Sample a real record, observe the process where possible and ask whether a capable third party could reproduce the reasoning. Record a proceed, change, pause or stop decision and the evidence behind it.