Two Field Guides.

Part III · Sell, Deliver, and Compete — Chapter 19

Build the smallest proof

The Complete Masterbook · pages 66–67

The purpose of an early build is not to impress. It is to answer the riskiest question at the lowest responsible cost.

“Minimum viable product” is often used to excuse poor quality. Minimum means minimal scope, not minimal duty. A healthcare workflow may require strict privacy and human review even in a pilot. A financial tool may require accuracy and auditability before any real use. Reduce breadth, not safety.

Identify the riskiest assumption

Common risks:

  • • desirability: the customer does not care enough;
  • • viability: price, margin, or sales cycle does not work;
  • • feasibility: technology or operations cannot reliably deliver;
  • • adoption: users will not change behaviour;
  • • trust: buyer cannot accept security, privacy, brand, or vendor risk;
  • • compliance: the model creates obligations you cannot meet.

Test the highest combined uncertainty and impact first.

Use the cheapest faithful test

QuestionPossible test
Will buyers pay?Written paid-pilot offer before automation
Can the result be produced?Manual or semi-manual concierge delivery
Will users adopt?Prototype on one real workflow with observation
Can the integration work?Technical spike with sanitized data
Will the economics work?Unit-economics model using conservative ranges
Will security approve?Early review of architecture and requirements

A manual service can validate the result before software automates it. A clickable prototype can validate workflow before engineering. A pre-sale can test commitment only if you are transparent about what exists and can deliver or refund as promised.

Keep the experiment contract

Every build should state:

  • • hypothesis;
  • • customer and situation;
  • • success metric and baseline;
  • • maximum hours and cash;
  • • safety and quality floor;
  • • test end date;
  • • evidence source;
  • • decision rule.

Without an end date and decision rule, a prototype becomes a hiding place.

Quality at the edge

Even narrow work must include clear error handling, access control, backups where needed, observability, and a rollback or exit. Test the unhappy path. Ask: What happens if data is missing, a person makes a mistake, a vendor fails, demand spikes, a payment is delayed, or you are unavailable?

RED LINE Never expose a customer to uncontrolled material harm merely to “move fast.” Fast learning includes safe boundaries, explicit consent, and a recovery path.

· GE ch. 16; TABLE pp. 13–16, 79–81; SALES p. 6. Mechanisms paraphrased; judgment and examples are labelled.