A forward plan answers "how can it succeed"; inversion thinking answers the other half of the question: "how can it inevitably fail". Once the failure paths are thought through clearly, the avoidance checklist naturally emerges. Taleb's Via Negativa puts it bluntly: getting better comes from subtracting mistakes, not from stacking on techniques. What keeps a gold prospector alive is avoiding 100 fatal mistakes, not learning 10 success techniques.
When to use it
- Do a premortem before a major decision: the money is about to go out, the team is about to go all-in—first assume it has already died, and work backward to the cause of death
- You only have a forward plan and no line of defense: the PRD, roadmap, and growth targets are packed full, but no one has asked "what would make this thing collapse"
- Reviewing a failure case and wanting to abstract the lesson into reusable avoidance rules, rather than stopping at "we were unlucky this time"
Workflow
Step 1: Clarify the goal, then invert it. Flip the goal from "I want to make X happen" to "if I wanted to guarantee this fails, what would I do". This angle of questioning itself is the operationalization of Munger's line: invert, always invert.
Step 2: Exhaustively list failure paths, at least 8. Go through the following eight categories of failure studies one by one and see which ones your current plan is exposed to. Don't just pick the two or three that are convenient; go through all eight—the one you miss is often the fatal one:
- Bad product—the core functionality is a mess, yet time is spent polishing pretty details that account for 20% of the value (the Pareto principle used in reverse)
- No one wants it / the map as territory—falling in love with your own map (business plan, PRD, roadmap) and refusing to compare it against the territory (real user feedback, real execution data). Starting work on the product side without validation, and on the progress side still pushing forward according to the original plan even though the data has already diverged, are essentially the same "trust the map, not reality" bias
- Cash flow dries up—the account can't last until the day validation holds; the runway was miscalculated
- Single-point dependency blows up—only one customer, one channel, one person carrying all the risk, with no diversified redundancy
- Outside the circle of competence—a tech geek insists on making a consumer product he doesn't even use, and dies in a field he doesn't understand
- All-in symmetric bet—staking your entire fortune and time on one direction, doubling if you win and going to zero if you lose, instead of a barbell allocation: put most resources in a certain, safe position, and a small portion in high-risk, high-payout asymmetric opportunities, without entering the middle ground
- Compliance/legal liability—crossing hard red lines in data privacy protection, platform terms, or industry regulation. This is not a matter of subjective motive; it is objectively illegal or in breach of contract, and no matter how good the intentions, when told to stop, you stop
- Ethical overreach—the product data looks great, but it was bought by damaging user trust, such as false advertising, induced payments, or algorithms manipulating emotions. With no moral moat, it deserves to be wiped out
Step 3: Turn each failure path into a checkable avoidance rule. Use the negation method: rules should clearly state "what not to do" and "what to subtract," rather than vaguely saying "pay more attention." For example, the avoidance rule corresponding to "single-point dependency blows up" is not "pay more attention to risk," but "no single customer's revenue share may exceed 30%; if it exceeds that, a second channel must be developed."
Step 4: Output the failure checklist and mark the status of each item against the current plan. Check each avoidance rule against the current situation and mark it "safe," "risk," or "hit." Items marked "hit" are the pits that must be dealt with before this decision, not objects to review only after something goes wrong.
Output template
| Failure path | Avoidance rule | Current status |
|---|---|---|
| Bad product | Before core functionality passes preset acceptance benchmarks (such as match rate or accuracy against a manual benchmark), investment in edge feature development must not exceed 10% of total work hours | Safe / Risk / Hit |
| Nobody wants it / Mistaking the map for the territory | Before starting work, at least 10 target users must have seen the demo and at least 3 clear purchase intentions must have been obtained. After launch, calibrate the roadmap against real conversion/retention data every two weeks; if the deviation exceeds 30% twice in a row, the direction must be reassessed | Safe / Risk / Hit |
| Cash flow runs out | Savings must cover the development cycle plus at least 1 month of validation and adjustment, and after adding the two together, leave another 20% buffer; it must not run out right as the development cycle ends | Safe / Risk / Hit |
| Single-point dependency blows up | No single customer/channel/supplier may account for more than 30%; if it exceeds that, a second one must be developed as a replacement | Safe / Risk / Hit |
| Outside circle of competence | Before entering a field where you have no experience, one external validation must be completed: either a paid AB test that produces data, or a written review opinion from someone with hands-on experience; choose one, and do not launch until it is completed | Safe / Risk / Hit |
| Symmetric bet all-in | The maximum loss from a single bet must not exceed 50% of disposable resources (savings plus time budget); any bet exceeding that proportion must be split into phased validation and must not be staked all at once | Safe / Risk / Hit |
| Compliance/legal liability | Before launch, complete a data compliance checklist (PII storage method, whether cross-border transfer occurs, platform terms, industry license requirements) and check off each item; if any item is not passed, launch is prohibited | Safe / Risk / Hit |
| Ethical overreach | If metric growth comes from data use without user consent, false advertising, or induced payment, it must be taken offline and rectified immediately upon discovery, and must not be retained on the grounds that the metrics look good | Safe / Risk / Hit |
Reminder: the checklist is meant to make risk-taking more controllable, not to make people afraid to take risks
Enumerating failure paths is not the same as vetoing each one individually. Before dealing with a pitfall you have fallen into, first weigh the cost of dealing with it and the upside you would give up, and consider whether it is worth sacrificing the plan's original win rate just to plug this pitfall. If a avoidance rule is revised to the point where the plan loses its room for growth and loses the part of the payoff it was originally meant to pursue, that means the rule has been drawn too broadly; it should be narrowed to block only that specific failure path, rather than cutting off the entire direction along with it. The two categories "outside the circle of competence" and "symmetric all-in betting" are the easiest to misuse as "don't touch anything, don't bet big on anything"; the correct use is to limit risk exposure, not eliminate risk exposure.
Munger anchor quote
"I just want to know where I'm going to die, so I'll never go there."