Contents
Inversion is the practice of asking "What would guarantee failure?" before designing your solution. Instead of chasing the right answer directly, you map the conditions that would make success impossible — then engineer your plan to avoid every one of them.
Section 1
What This Tool Does
The mathematician Carl Jacobi had a maxim: "Man muss immer umkehren." Invert, always invert. He wasn't offering life advice. He was describing a problem-solving technique that had unlocked proofs his contemporaries couldn't crack by approaching them head-on. Charlie Munger, who spent decades as Warren Buffett's partner at Berkshire Hathaway, took Jacobi's principle and transplanted it from mathematics into the messier domain of business and life decisions. His version was blunter: "All I want to know is where I'm going to die, so I'll never go there."
The joke contains the entire method. Most decision-makers start with the question "How do I succeed?" and generate a list of things to do. Inversion starts with "How would I guarantee failure?" and generates a list of things to avoid. The difference sounds trivial. It isn't. The forward approach produces aspirational plans — hire great people, build a superior product, execute flawlessly. These are true and useless. They describe the destination without identifying the landmines between here and there. Inversion produces a map of the landmines.
The cognitive gap it fills is specific and well-documented. Humans are significantly better at recognising what's wrong than at constructing what's right. Show someone a flawed business plan and they'll spot the problems in minutes. Ask them to write a perfect business plan from scratch and they'll stare at a blank page. Inversion exploits this asymmetry. By asking you to describe failure first, it activates your critical faculties — your strongest analytical gear — and redirects that energy toward constructive design. You're not brainstorming solutions. You're brainstorming disasters, which is something the human mind does with alarming fluency, and then systematically eliminating each one.
There's a second mechanism at work, subtler but equally important. Forward planning suffers from what psychologists call the "planning fallacy" — the tendency to imagine best-case scenarios and underweight obstacles. When you ask "How do we win?", the room fills with optimism. When you ask "How do we definitely lose?", the room fills with honesty. People will volunteer failure modes they'd never raise as objections to a positive plan, because describing a hypothetical disaster feels less confrontational than criticising a colleague's strategy. Inversion gives permission to be pessimistic in a structured way, and that pessimism is where the actionable intelligence lives.
The tool is deceptively simple — a single question, no framework, no matrix, no scoring rubric. That simplicity is its greatest strength and its greatest vulnerability. Strength because anyone can use it in any context with zero preparation. Vulnerability because its lack of structure means the quality of the output depends entirely on the rigour of the person wielding it. A lazy inversion produces a list of obvious failure modes. A disciplined one surfaces the non-obvious conditions that kill strategies silently — the assumptions nobody questioned, the dependencies nobody mapped, the second-order effects nobody modelled.
Section 2
How to Use It — Step by Step
Instructions on the left. Worked example — a Series B SaaS company deciding whether to expand from the US into the European market — on the right.
Step 1 — State
Define the goal you're trying to achieve
Write down the specific outcome you want, in concrete terms. Not "succeed in Europe" but "reach €5M ARR in the DACH region within 18 months of launch." The more precise the goal, the more precise the failure conditions you'll generate in the next step. Vague goals produce vague inversions. If you can't state the goal in one sentence with a number and a timeframe, you're not ready to invert.
Worked example
SaaS European expansion
"Reach €5M ARR in the DACH region (Germany, Austria, Switzerland) within 18 months of launch, with a gross margin above 70% and a payback period under 14 months." The team writes this on the whiteboard. This is the target they'll now try to destroy.
Step 2 — Invert
Ask: What would guarantee failure?
Flip the goal. Instead of "How do we reach €5M ARR?", ask "What would make it absolutely certain that we fail to reach €5M ARR — or that reaching it destroys the company?" Generate as many failure conditions as possible. Be specific. "Bad execution" is worthless. "Hiring a country manager who has never sold to German mid-market IT buyers" is useful. Push past the obvious. The first ten failure modes will be predictable. The next five are where the insight lives. Encourage the team to think across categories: people, product, market, timing, regulatory, financial, competitive.
Worked example
The failure list
The team generates: (1) Translate the UI but not the compliance documentation — German buyers won't touch it. (2) Price in USD — signals we're not serious about the market. (3) Hire a US-based "head of EMEA" who flies in quarterly instead of a local GM. (4) Ignore GDPR data residency requirements and host on US servers. (5) Launch without a local payment processor — German companies still rely heavily on SEPA direct debit. (6) Assume the US sales playbook works — German enterprise sales cycles are 2–3× longer. (7) Enter during Q4 when German procurement budgets are already committed. (8) Underestimate the strength of local incumbents who have existing relationships with target accounts. (9) Set US-style quotas for the DACH sales team and lose them within six months. (10) Fail to get ISO 27001 certification — table stakes for German enterprise buyers. (11) Ignore the Works Council dynamic — in Germany, software purchases that affect employee workflows often require Works Council approval, adding months to the cycle.
Step 3 — Cluster
Group failure modes by theme and identify the lethal ones
Not all failure modes are equal. Some are inconveniences. Some are fatal. Sort your list into clusters — regulatory, go-to-market, product, organisational, financial — and then mark the ones that would be irreversible or extremely expensive to fix after launch. These are your "must-avoid" conditions. A pricing mistake can be corrected in a quarter. A data residency violation can result in regulatory action that shuts down the entire operation. Weight accordingly.
Worked example
Clustering and severity
The team clusters into four groups. Regulatory/compliance (GDPR data residency, ISO 27001, Works Council dynamics) — marked as potentially fatal, because violations can trigger fines up to 4% of global revenue and destroy trust with prospects. Go-to-market (US playbook assumption, Q4 timing, US-based leadership, quota structure) — marked as expensive but correctable. Product localisation (compliance docs, payment processor, currency) — marked as launch-blocking. Competitive (local incumbents with relationships) — marked as ongoing friction, not fatal. The regulatory cluster gets a red flag. Everything in it must be resolved before launch, not after.
Step 4 — Design
Build your plan as the mirror image of the failure list
Take each failure condition and write its opposite as a design requirement. "Hosting on US servers guarantees failure" becomes "Requirement: EU-hosted infrastructure with data residency guarantees before day one." "US-based head of EMEA guarantees failure" becomes "Requirement: hire a Berlin- or Munich-based GM with direct DACH enterprise sales experience." This step converts a list of fears into a list of specifications. Your plan isn't aspirational anymore — it's a systematic avoidance of every condition you identified as lethal.
Worked example
The inverted plan
From the failure list, the plan now includes: (1) EU-hosted infrastructure (Frankfurt data centre) operational before any sales activity. (2) ISO 27001 certification process initiated immediately, with target completion before launch. (3) Local GM hired in Munich with DACH mid-market SaaS sales background. (4) Pricing in EUR with SEPA direct debit as default payment method. (5) Sales cycle assumptions reset to 6–9 months (not the US average of 3–4). (6) Launch timing: Q1, when German procurement budgets reset. (7) Compliance documentation fully localised — not just translated, but reviewed by German legal counsel. (8) Quota structure adjusted for longer sales cycles with ramp period extended to 9 months. (9) Works Council briefing template created as part of the standard sales enablement kit. Each requirement traces directly back to a specific failure mode. Nothing is aspirational. Everything is defensive.
Step 5 — Stress-test
Ask what failure modes you missed
The inversion is only as good as the failure modes you generated. After building the plan, run one more pass: "Given this plan, what could still kill us?" This catches the second-order failures — the ones that emerge from the plan itself. Hiring a local GM creates a new failure mode: what if they don't align with HQ product priorities? Hosting in Frankfurt creates another: what if latency to the US-based backend degrades performance? The best inversions are recursive. Invert the plan, then invert the inversion.
Worked example
Second-order failures
The team identifies: (a) Local GM may prioritise DACH feature requests that conflict with the US product roadmap — need a clear escalation process and quarterly alignment reviews. (b) Frankfurt hosting may require a separate deployment pipeline, increasing engineering overhead — need to budget for a dedicated DevOps resource. (c) Longer sales cycles mean higher customer acquisition cost — need to model whether €5M ARR at a 14-month payback is achievable, or whether the payback target needs to flex to 18 months. The plan adjusts. The budget adjusts. The timeline adjusts. None of these adjustments would have surfaced from a forward-only planning process.
Section 3
When It Works Best
✓
Ideal Conditions for Inversion
| Dimension | Best fit |
|---|---|
| Decision type | High-stakes, irreversible, or expensive-to-reverse decisions — market entry, major hires, product architecture choices, M&A. The tool's value scales with the cost of getting it wrong. For low-stakes reversible decisions, the overhead isn't justified. |
| Planning stage | Early — before commitments are made, resources allocated, or teams assembled. Inversion is a design tool, not a diagnostic one. It shapes plans before execution, not after failure. Using it mid-flight is possible but less powerful because some failure conditions are already baked in. |
| Team dynamic | Groups where optimism bias is strong — founding teams, sales-led organisations, cultures that reward confidence over caution. Inversion gives the sceptics in the room a structured, non-confrontational way to surface concerns that would otherwise be dismissed as "negativity." |
| Information environment | Situations where you know more about what doesn't work than what does. Entering a new market, launching a novel product category, attempting an organisational transformation — domains where precedent is thin but cautionary tales are abundant. |
| Complexity | Problems with many interacting variables where the failure modes are non-obvious. Simple decisions don't need inversion. Complex ones — where success depends on getting fifteen things right simultaneously — benefit enormously from a systematic audit of what could go wrong. |
| Cognitive context | When the team has been in "solution mode" too long and has stopped questioning assumptions. Inversion breaks the momentum of forward planning and forces a perspective shift. Particularly valuable after a strategy offsite that produced a confident plan nobody has stress-tested. |
Section 4
When It Breaks Down
⚠
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| Shallow inversion | The team lists obvious failure modes — "don't hire bad people," "don't run out of money" — and calls it done. The output is a list of platitudes that inverts into equally platitudinous advice. The inversion never reaches the non-obvious, context-specific failure conditions where the real value lives. | Pair with 5 Whys to drill each failure mode to its structural root. Require specificity: names, numbers, mechanisms. |
| Paralysis by pessimism | The failure list grows so long and so terrifying that the team concludes the initiative is too risky to attempt. Inversion becomes an engine of inaction. Every plan has a hundred ways to fail; the point is to identify the lethal ones and design around them, not to catalogue every conceivable risk until the project dies of caution. | Cluster and prioritise ruthlessly. Use Reversible vs. Irreversible Decisions to separate the fatal from the fixable. |
| Inversion without construction | The team completes Steps 1–3 (generating and clustering failure modes) but never does Step 4 (designing the plan as the mirror image). The exercise produces a vivid list of fears and no actionable plan. Inversion without the constructive flip is just anxiety with a framework. | Mandate that every failure mode has a corresponding design requirement. No orphan fears. |
| Anchoring on past failures | The team's failure list is dominated by things that went wrong last time — the previous market entry that failed, the last bad hire. These are relevant but incomplete. Over-indexing on historical failures blinds you to novel failure modes specific to the current context. | Split the brainstorm: one round for "failures we've seen before," one round for "failures unique to this situation." Use Scenario Planning for the latter. |
| Solo inversion in echo chambers | A single decision-maker runs the inversion alone. Their blind spots become the inversion's blind spots. The failure modes they can't imagine — because of their functional background, their seniority, their distance from the front line — never appear on the list. | Run inversion as a group exercise with diverse functional perspectives. Use Delphi Method for sensitive topics where hierarchy suppresses honesty. |
| Misapplication to creative problems | Inversion is a risk-mitigation tool. Applied to problems that require creative leaps — "What should our brand stand for?" or "What's our next product category?" — it produces conservative, defensive thinking. You can't invert your way to a breakthrough; you can only invert your way to not failing. | Use SCAMPER or First Principles Thinking for generative ideation. Reserve inversion for stress-testing the ideas those tools produce. |
The most dangerous failure mode is shallow inversion, because it's invisible. A shallow inversion looks exactly like a rigorous one — the team went through the steps, generated a list, built a plan. But the failure modes were generic, the kind you'd find in any business school case study. "Don't underestimate the competition." "Don't ignore customer needs." These are true of every initiative in every industry. They contain zero information specific to your situation.
The antidote is relentless specificity. Instead of "don't underestimate the competition," force the team to name the competitor, describe their specific advantage, and explain the exact mechanism by which that advantage would cause your initiative to fail. "Personio has pre-existing relationships with 60% of German mid-market HR directors and a 3-year head start on DACH compliance features — our sales team will face a default incumbent in nearly every deal." That's an inversion you can design around. The generic version is wallpaper.
Section 5
Visual Explanation
Inversion applied to the DACH market expansion — failure modes on the left, design requirements on the right. Each lethal condition maps to a specific plan element.
Section 6
Pairs With
Inversion is a lens, not a complete decision system. It sharpens the design of a plan but doesn't generate the plan itself. The tools around it determine whether the inversion produces real protection or just a well-organised list of worries.
Use before
First Principles Thinking
First Principles strips a problem down to its fundamental truths before you start building solutions. Inversion then stress-tests whatever you build. The sequence matters: decompose the problem to its foundations, construct a solution from those foundations, then invert to find the failure modes in your construction. First Principles without Inversion produces elegant but fragile plans.
Use before
Reframing
Inversion assumes you're solving the right problem. Reframing checks that assumption. If you invert the wrong goal — "How do we fail to launch in Germany?" when the real question is "Should we expand internationally at all?" — you'll produce a bulletproof plan for an initiative that shouldn't exist.
Use after
Pre-Mortem
Inversion and the Pre-Mortem are cousins, not twins. Inversion asks "What would guarantee failure?" in the abstract. The Pre-Mortem asks "It's 18 months from now and this has failed — why?" The temporal framing of the Pre-Mortem surfaces narrative failure modes (sequences of events, cascading errors) that the more categorical inversion can miss.
Use after
Reversible vs. Irreversible Decisions
Once inversion generates a failure list, this framework helps you triage it. Irreversible failure modes (regulatory violations, architectural choices that can't be unwound) demand pre-launch resolution. Reversible ones (pricing, positioning, hiring) can be addressed iteratively. The distinction prevents paralysis by pessimism.
Use after
[Second-Order Thinking](/mental-models/second-order-thinking)
Inversion's Step 5 — "What could still kill us given this plan?" — is essentially second-order thinking applied to the inverted design. Second-Order Thinking formalises this: for each design requirement you created, ask "And then what happens?" The GM you hired in Munich creates a new political dynamic with HQ. The Frankfurt data centre creates a new latency profile. Every solution seeds new failure modes.
Mental model
Scenario Planning
Scenario Planning builds multiple plausible futures. Inversion stress-tests your plan against the worst of them. Run inversion once for each scenario: "What guarantees failure if the market grows 40%?" produces a different list than "What guarantees failure if the market contracts 15%?" The combination is more robust than either tool alone.
Section 7
Real-World Application
Amazon — Working Backwards as institutionalised inversion
The scenario
Amazon's "Working Backwards" process — the practice of writing a press release and FAQ for a product before building it — is often described as a customer-obsession ritual. It is that. But its deeper mechanism is inversion. When Jeff Bezos formalised the process in the early 2000s, the problem he was solving wasn't a lack of customer focus. It was a pattern he'd observed repeatedly: teams would build technically impressive products that failed because they'd never confronted the conditions under which customers would reject them. The forward question — "What should we build?" — produced feature lists. The inverted question embedded in the FAQ — "What are all the reasons a customer would choose not to use this?" — produced the design constraints that actually mattered.
How the tool appliedThe FAQ section of Amazon's internal press release template is structured inversion. Product teams must answer questions like: "Why would a customer not switch from their current solution?" "What's the most common objection a customer would raise?" "Under what conditions would this product make a customer's life worse?" These are failure-condition questions dressed in customer language. The team behind the original Kindle, for instance, had to confront the failure mode "customers won't switch from physical books if the e-reader doesn't have a library of at least 100,000 titles at launch." That specific inversion — what would guarantee that nobody buys this? — drove the decision to delay launch until the content library was large enough to overcome the switching cost. The team reportedly pushed back on the timeline, arguing the hardware was ready. The FAQ's failure-mode logic won.
What it surfacedThe Kindle example illustrates inversion's core contribution: it surfaces the binding constraints that forward planning misses. A forward plan for the Kindle would prioritise hardware specs, screen technology, battery life, industrial design. All important. But none of them mattered if the content library was too thin. Inversion identified the single condition — insufficient content — that would have guaranteed failure regardless of how good the hardware was. The entire launch timeline reorganised around that constraint.
The non-obvious factorWhat makes Amazon's application distinctive is that inversion isn't a one-time exercise — it's embedded in the operating system. Every new product, every new feature, every significant initiative goes through the Working Backwards process, which means every initiative is inverted before resources are committed. Most companies use inversion episodically, during annual planning or when a crisis forces reflection. Amazon uses it continuously, which means the failure-mode thinking compounds. Teams develop an instinct for asking "What would make this fail?" before they ask "How do we build this?" — and that instinct, scaled across thousands of teams, is a meaningful structural advantage. The tool isn't the press release template. The tool is the cultural habit of inverting every plan before executing it.
Section 8
Analyst's Take
Faster Than Normal — Editorial View
Inversion endures because it solves a problem that no amount of intelligence or experience can solve on its own: the asymmetry between how easily humans imagine success and how reluctantly they imagine failure. Smart people are particularly vulnerable. The smarter you are, the more convincing your forward plan sounds — to yourself and to the room. Inversion is the only tool I know that gets reliably smarter people to slow down and ask the uncomfortable question. It doesn't require a framework, a facilitator, or a two-day offsite. It requires one sentence: "What would guarantee this fails?" That sentence, asked sincerely, has prevented more bad decisions than any matrix I've encountered.
The failure mode I see most often isn't shallow inversion or paralysis — it's inversion that stops at the first layer. Teams generate failure conditions that are accurate but proximate. "We'll fail if we can't hire fast enough." True. But why would you fail to hire fast enough? Because your compensation isn't competitive in the local market. Why? Because you're benchmarking against US cost-of-living adjustments instead of local market rates for the role. That's the actionable failure condition. The surface-level version — "can't hire fast enough" — inverts into the useless requirement "hire fast enough." The deep version inverts into "benchmark compensation against Berlin SaaS companies, not US cost-of-living tables." One layer of inversion gives you a worry. Three layers give you a specification.
The highest-leverage modification: invert across time horizons. Most teams invert against immediate failure — what kills us in the first six months? That's necessary but insufficient. Run a second inversion against the 24-month horizon: "What would guarantee that even if we succeed initially, we fail by year two?" This surfaces a completely different class of failure modes — the ones related to scaling, organisational debt, competitive response, and market shifts. The DACH expansion team might nail the launch but fail at year two because they never built a local customer success function and churn ate the ARR they'd worked so hard to acquire. Short-horizon inversion catches the launch risks. Long-horizon inversion catches the sustainability risks. You need both.
Section 9
Top Resources
01
Poor Charlie's Almanack — Charlie Munger (2005)
Primary sourceThe definitive collection of Munger's thinking, including multiple speeches where he explains inversion as a core mental model. His 1986 Harvard School commencement address — "How to Guarantee a Life of Misery" — is the purest demonstration of inversion as a decision tool: he describes how to ruin your life, then inverts every point into practical wisdom. The book is expensive and out of print in its original edition, but the expanded edition remains the primary source for Munger's approach to inversion and his broader latticework of mental models.
02
Book
The scientific foundation for why inversion works. Kahneman's research on the planning fallacy, optimism bias, and the asymmetry between loss aversion and gain-seeking explains the cognitive architecture that makes forward planning systematically overconfident. Read Part 3 ("Overconfidence") and Part 4 ("Choices") to understand the specific biases that inversion is designed to counteract. Not a how-to guide — a why-it-matters guide.
03
Book
The best modern case study of inversion institutionalised at scale. Bryar and Carr, both long-tenured Amazon executives, describe how the Working Backwards process — which embeds inversion into the FAQ section of every product proposal — shaped decisions on the Kindle, AWS, and Prime. Chapter 4 on the press release process is the most detailed public account of how Amazon operationalises failure-mode thinking before committing resources.
04
Book
Horowitz doesn't use the word "inversion," but the book is essentially a catalogue of failure modes in company-building — the things that kill startups that nobody warns you about. His chapters on "the struggle," wartime vs. peacetime CEO, and the dynamics of layoffs read as an inverted playbook: here's what goes wrong, here's the mechanism, here's how to design against it. Pair with Munger's theoretical framework for the complete picture.
05
Book
Grove's account of Intel's strategic inflection points is inversion applied to corporate strategy at the highest level. His central question — "What would destroy this business?" — drove Intel's decision to exit memory chips and bet entirely on microprocessors. The book demonstrates inversion not as a planning exercise but as a survival discipline: the practice of continuously asking what would kill you, and reorganising before it does. Chapter 5 on "signal or noise" is particularly valuable for distinguishing real failure conditions from phantom ones.
Decision Tools Library — Browse by phase
Why this matters next
mental modelsSecond-Order Thinking
First Principles Thinking applied the Second-Order Thinking mental model
mental modelsFirst Principles Thinking
First Principles Thinking applied the First Principles Thinking mental model
mental modelsLeverage
First Principles Thinking applied the Leverage mental model
mental models5 Whys
First Principles Thinking applied the 5 Whys mental model
mental modelsMomentum
First Principles Thinking applied the Momentum mental model
mental modelsNarrative
First Principles Thinking applied the Narrative mental model
Continue exploring
SCZBPM
Decision tool
SCAMPER
Systematically generate variations by Substituting, Combining, Adapting, Modifyi
Decision tool
Zwicky Box
Generate novel solutions by combining dimensions of a problem in unusual ways
Decision tool
Productive Thinking Model
Move through a structured six-step creative process from problem to solution to
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.