By 6days · v1.0 · Updated 7/20/2026
Ask how this fails, not how it succeeds — the failure list is shorter and more honest.
Fill this in for your own situation — a private worksheet only you can see.
When to use
Use it before committing to a plan that is expensive to reverse, when a team has become uniformly enthusiastic and you suspect the optimism is social rather than evidential, and in any decision where avoiding a catastrophic downside matters more than optimising the upside.
When not to use
Avoid it as a general operating posture — a culture that only inverts becomes paralysed and treats every idea as a hazard. It is weaker in genuinely novel territory where the failure modes are unknown rather than unspoken. And it will not generate a strategy: it removes ways to lose, which is not the same as finding a way to win.
Planning is optimistic by construction. A team asks how to succeed, generates a route, and commits — and the failure modes stay unexamined because raising them feels like disloyalty, especially once leadership has expressed enthusiasm. The risks were usually knowable in advance. They simply had no socially safe moment at which to be said out loud.
Inversion turns the question around. Instead of asking how to achieve the goal, ask what would guarantee failure — then systematically avoid those things. It works for two reasons. Failure modes are often far easier to enumerate than success paths, since there are fewer ways for a thing to work than to break. And it makes pessimism structurally acceptable: a person listing ways to fail is completing the assigned exercise, not attacking the plan. Avoiding stupidity reliably tends to beat pursuing brilliance, and it is considerably easier.
Framework by 6days on 6days — https://6days.apexaion.ai/framework/inversion
Write down what success actually looks like, concretely and with a date. You cannot invert a vague aspiration — 'grow the business' has no clean opposite, while 'ship to 500 paying customers by March' does.
Ask the opposite question: what would we do to guarantee this fails? Be specific and be uncomfortable. Give the group silent writing time first, because the honest answers do not survive contact with an enthusiastic senior voice.
Order the failure modes by how plausible they are and how badly they would hurt. Most will be neither, and a few will be both. The list will usually contain one or two items everyone privately expected and nobody had said.
For each failure mode that matters, decide now: prevent it, monitor it with a named trigger, or knowingly accept it. Accepting it explicitly is a legitimate answer and much better than accepting it by default.
Worked example
Before a platform migration, the team asks how to guarantee failure. The list: migrate everything at once with no rollback; do it in December when everyone is away; let the one engineer who understands the legacy schema take leave mid-project; discover the data quality problems during rather than before; tell customers nothing. Written down, four of the five are quietly already true of the current plan. The plan changes to a phased cutover with a rollback path, moves to February, front-loads a data audit, and adds customer comms — none of which required new information, only permission to say it.
Inversion as a reasoning habit is long-established in mathematics, where proof by contradiction is standard practice, and it is often associated with the 19th-century mathematician Carl Jacobi and his advice to invert a problem. Its modern popularity in decision-making owes much to Charlie Munger, who advocated it repeatedly as a discipline for avoiding error. It is common heritage, not a proprietary framework.
Related ways to think about this.
Strip a problem back to what must be true, then rebuild — instead of copying what exists.
Use when Use it when an industry's costs or practices have been stable for a long time without obvious justification, when you are entering a field as an outsider and lack the incumbents' assumptions, or when repeated incremental attempts have all failed and the problem may be framed wrongly.
Avoid when Avoid it for routine decisions — it is slow, effortful, and analogy is right most of the time. It is also a common vehicle for arrogance: reasoning from first principles while lacking domain knowledge tends to rediscover why the convention exists, expensively. If experts cannot explain why a practice exists, that is worth investigating; if they can, listen.
Observe, orient, decide, act — and win by cycling faster than the situation changes.
Use when Use it in genuinely competitive, fast-changing situations — an incident, a live negotiation, a competitor's surprise move, a crisis. It suits environments where information is incomplete by nature and waiting for completeness means losing.
Avoid when Avoid it for decisions that are expensive to reverse and slow-moving: a factory site or a pension scheme does not want tempo, it wants analysis. It is widely misread as 'decide fast', which drops the orient step and produces speed without judgement. It also has little to say where there is no adversary and no clock.
Separate urgent from important, and notice how much of your week serves neither.
Use when Use it when you are busy but not progressing, when a team is permanently reactive, or during a periodic review of where a role's time actually goes. It works well as a recurring habit rather than a one-off, and it is a useful device for a manager and report to look at a workload together without it becoming personal.
Avoid when Avoid it where you have little real autonomy — telling someone to delegate work they cannot delegate is just a way of blaming them for their constraints. It handles individual tasks better than long collaborative efforts, and it has nothing to say about work that is important to someone else and not to you, which is most of what makes a job hard. It also assumes you can tell importance from urgency, which is exactly the skill people struggling with this tend to lack.