Fail cheaply and detect failure early

An experiment is not a vibe with a deadline. It is a bounded collision between a belief and reality, followed by a changed system.

“Fail fast” is one of those phrases that sounds practical until it becomes permission for careless work. A founder can fail fast by shipping unsafe software, wasting customer attention, burning reputation, or calling random motion “learning.” That is not experimentation. That is negligence with startup vocabulary. The standard is stricter:

Belief → Boundary → Smallest faithful test → Measurement → Decision → System change

Write the belief so it can lose

A useful experiment begins with one falsifiable sentence:

We believe [specific customer] will make [specific commitment] for [specific result] because [observed pain] currently costs [time, money, risk, delay, or trust].

If the sentence contains “people,” “businesses,” “AI,” “better,” or “interested” without a defined buyer, event, and commitment, it is still fog. Fog cannot fail. It only drifts. The belief must name the riskiest assumption. Early founders often test the comfortable assumption: “Can we build it?” They avoid the lethal one: “Will a buyer with authority pay, switch, adopt, and keep using it?” Technical feasibility matters, especially in sensitive domains, but most young companies die from a missing buyer, weak urgency, poor economics, unsafe delivery, or slow adoption.

Bound the damage before you learn

Every test needs limits:

Do not put tax money, payroll, emergency reserves, sensitive customer data, or regulated decisions on the experiment table. A small test should buy information. It should not transfer hidden risk to customers, family, employees, or future you.

Choose the smallest faithful test

Small does not mean fake. It means the minimum version that preserves the decision reality.

A customer interview can test language and pain. A paid diagnostic can test willingness to spend. A manual service can test the result before software automates it. A clickable prototype can test workflow. A technical spike can test integration. A pilot can test delivery and adoption under written scope.

The test must include the behaviour you need evidence about. If the future business requires payment, a free demo is incomplete evidence. If the future product requires customer data, a toy dataset is incomplete evidence. If the future sale requires a manager, finance reviewer, or security reviewer, praise from a friendly user is incomplete evidence.

Detect failure before it becomes dramatic

Failure rarely arrives first as a final event. It arrives as a pattern:

• • qualified customers describe the problem as annoying, not costly;
• • meetings happen, but no buyer accepts a next commitment;
• • proposals are sent without decision dates;
• • one enthusiastic user cannot identify the budget owner;
• • the pilot works only because the founder personally rescues every step;
• • usage, repeat purchase, renewal, or referral is absent after initial politeness;
• • rework consumes the margin;
• • invoices age while new work continues;
• • security, privacy, legal, or employment questions appear and the team bluffs;
• • metrics are changed when they become uncomfortable.

Do not wait for a collapse to call this evidence. The point of the experiment is to notice while the cost is still small.

Run the after-action review while evidence is fresh

Ask:

1. What did we expect? 2. What actually happened? 3. Which facts are reliable?

4. Which parts are interpretation? 5. Was the hypothesis wrong, the test weak, or execution poor? 6. What customer, employee, vendor, or family member bore cost? 7. What must be repaired?

8. What will we repeat, change, stop, or test next? 9. Who owns the change? 10. When will we confirm the lesson entered the system?

“Customers are not ready” is not a finding. A useful, explicitly illustrative finding sounds like this: “In this test, fifteen qualified operations leaders already solved the workflow inside their current tool; five described material pain but lacked budget authority; none accepted the paid diagnostic.” The numbers are not a benchmark. The structure tells you whether to change segment, buyer, timing, offer, or thesis.

Persistence or stubbornness

Persist when the problem is real, commitments grow stronger, delivery improves, contribution has a credible path, and loss remains survivable. Change or stop when repeated qualified evidence contradicts the thesis, safety or legality cannot be met, economics worsen with scale, or the main reason to continue is that stopping would embarrass you.

Persistence stories from successful people are useful only when they include adaptation and affordability. Enduring ten years without evidence is not heroic. It is a slow transfer of life into an unexamined belief.

· GE chs. 31–32 · LG pp. 78–80, 102–109 · TABLE pp. 79–81 · ASC pp. 116–120. Experiment gates and failure signals are operating heuristics; thresholds must be set from the actual business.