Comparing by fit
Two ways of thinking, side by side. There is no winner here — read across each row and choose the one that fits your situation.
Decision Making
Strip a problem back to what must be true, then rebuild — instead of copying what exists.
By 6days
Decision Making
Ask how this fails, not how it succeeds — the failure list is shorter and more honest.
By 6days
When to use — First-Principles Thinking
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.
When to use — Inversion
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 — First-Principles Thinking
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.
When not to use — Inversion
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.
Most reasoning is analogy: we do it this way because that is how it is done, because the incumbent does it, because we did it last time. Analogy is efficient and usually right, which is exactly why it is dangerous — it carries forward constraints that were real once and quietly expired. Whole industries hold assumptions nobody has tested in decades, because testing them was never anyone's job.
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.
First-principles thinking decomposes a problem to the things that must be true — physics, arithmetic, contract terms, hard constraints — and reasons upward from there, deliberately ignoring how the problem is currently solved. The hard part is not the rebuilding; it is telling a real constraint from an inherited convention. 'Water boils at 100°C at sea level' is a principle. 'Enterprise software is sold through channel partners' is a convention wearing a principle's clothing. The method is expensive and usually unnecessary — its value is concentrated in the rare cases where a load-bearing assumption is simply wrong.
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.
Write the problem so that no current approach is embedded in the wording. 'How do we make our call centre more efficient' has assumed a call centre. 'How do customers get their question answered' has not, and the two questions have very different answer sets.
Write down everything you believe about the problem, especially what feels too obvious to state. The load-bearing assumptions are always the ones nobody thought worth writing down, because obviousness is what protects them from scrutiny.
For each, ask what would happen if it were false, and demand evidence for why it holds. Laws of physics, arithmetic, and binding contracts survive. Industry practice, precedent, and 'the customer expects it' usually turn out to be conventions that someone chose, under conditions that may no longer apply.
Construct a solution using nothing but the constraints that survived. Do not check it against the existing approach yet — the comparison will pull you back toward the familiar before the new idea has finished forming.
Worked example — First-Principles Thinking
A team is quoted £40,000 for a piece of lab equipment and treats it as fixed. Decomposed: what is it actually made of? A precision stage, a camera, a light source, a controller, an enclosure, and software. Priced as components, roughly £6,000. The remaining £34,000 is not physics — it is certification, low production volume, support, and margin, all of which are real costs but not laws. For a regulated clinical setting the £40,000 is justified and the analysis ends there. For an internal research rig that needs no certification, most of that gap is avoidable, and the team builds it for £9,000.
Worked example — Inversion
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.
The idea is ancient: Aristotle described reasoning from first principles, and the method underpins mathematics and physics as disciplines. Its modern circulation in business owes much to engineering culture and to founders who have publicly credited it for cost-structure decisions. It is common intellectual heritage rather than anyone's proprietary framework.
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.
Set the rebuilt solution against the status quo. Often the status quo wins, which is a real and useful result: you now know why it is right rather than merely inheriting it. Occasionally the gap is enormous, and that is what the whole exercise was for.
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.