A forward plan answers "How can we succeed?"; inversion thinking answers the other half of the question: "How can this be guaranteed to fail?" Once the failure paths are thought through clearly, the avoidance checklist emerges naturally. Taleb's Via Negativa puts it plainly: 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
- Do a premortem before a major decision: the money is about to be invested, the team is about to go all-in—first assume it has already died, then work backward to the cause of death
- You have only 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 collapse?"
- You are reviewing a failed case and want to abstract the lessons 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 achieve X" to "If I wanted to guarantee this fails, what would I do?" This angle of questioning is itself the operationalization of Munger's line: invert, always invert.
Step 2: Exhaustively list failure paths, at least 8. Go through the eight categories of failure studies below one by one and see which ones your current plan is exposed to. Do not 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 beautiful details that account for 20% of the value (Pareto principle in reverse)
- Nobody wants it / the map is treated as the territory—falling in love with your own map (business plan, PRD, roadmap) and refusing to compare it with the territory (real user feedback, real execution data). Starting work on the product side without anyone validating it, and on the progress side still pushing according to the original plan even though the data has already diverged—these are essentially the same "trust the map, not reality" bias
- Cash flow runs out—the account cannot last until the day validation holds up; the runway was miscalculated
- Single point of dependency blows up—only one customer, one channel, one person carrying all the risk, with no diversified redundant configuration
- Outside the circle of competence—a tech geek insists on making a consumer product they would never use themselves, and dies in a field they do not understand
- Symmetric all-in 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: most resources in a certain, safe position, a small portion in high-risk, high-payoff asymmetric opportunities, and no entering the middle ground
- Compliance/legal liability—stepping on 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. No matter how good the intentions, when told to stop, you stop
- Ethical overreach—the product data looks great, but it was bought by harming user trust, such as false advertising, inducing payment, or algorithms manipulating emotions. Without a moral moat, it deserves to be zeroed out
Step 3: Turn each failure path into a checkable avoidance rule. Use the negative approach: rules should clearly state "what not to do" and "what to subtract," rather than vaguely saying "do a good job." 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 the current plan item by item. 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 period, 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 substitute | 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 A/B test to obtain data, or finding someone with hands-on experience to provide a written review opinion; choose one of the two, 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); bets exceeding that proportion must be split into phased validation and must not be placed 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 each item as passed; 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, once discovered it must be taken offline immediately for rectification 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 against 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 portion of returns 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 to eliminate risk exposure.
Munger anchor quote
"I just want to know where I'm going to die, so I'll never go there."