Thinking/Mental Models

Framework

Mental Models I Use

Mental models are thinking tools. They don't give you answers, they give you better questions. This is a working collection, not an exhaustive list. These are the ones I actually reach for when making decisions, diagnosing problems, or evaluating opportunities, listed roughly from the ones I use most to the ones I use least.

None of these are original. They come from Munger, Feynman, Taleb, Bezos, and others. The value isn't in knowing them, it's in using them consistently.

Rank them your way. Drag any card to reorder the list by how you use them. Your order is saved in this browser only, nothing is sent anywhere.

First Principles Thinking

What it is: Break a problem down to its fundamental truths, then reason up from there. Strip away assumptions and conventions.

When I use it: Pricing strategy, architecture decisions, entering new markets. Anytime the answer "because that's how it's always been done" shows up.

Example: When building our stock valuation framework, I didn't start from "what do other screeners do." I started from "what determines a company's value?", cash flows, growth, risk. Everything else is derived.

Two-Way Door Decisions

What it is: Most decisions are reversible (two-way doors): make them fast and cheaply, because you can walk back through. A few are one-way doors, irreversible, and deserve slow, careful analysis. The fatal error is treating a two-way door like a one-way door (paralysis) or a one-way door like a two-way door (recklessness).

When I use it: Almost daily, to set decision speed. The test: "What if we're wrong, and can we go back without serious consequences?" If yes, decide now and move.

Example: Shipping a new article layout is a two-way door, I just try it and revert if it's worse. Choosing the framework the whole site is built on is a one-way door, that one I researched for days. Knowing which is which is most of the skill.

The 80/20 Rule (Pareto Principle)

What it is: Roughly 80% of outcomes come from 20% of causes. Effort and results are rarely proportional, a small set of inputs drives most of the value, and most of the rest is noise.

When I use it: Prioritization, triage, and any time the to-do list is longer than the time available. Find the vital few; consciously defer the trivial many.

Example: On the stock dashboard, 20% of the features (valuation + the comparison view) drove ~80% of the usage. I built those to a high bar and kept everything else deliberately minimal.

Leverage

What it is: Not all effort is equal. Find the inputs that produce disproportionate outputs. Code, media, capital, and people are the four forms of leverage.

When I use it: Prioritization, resource allocation, career strategy. Ask: "What's the one thing that makes everything else easier or unnecessary?"

Example: Building this website is leverage, it works 24/7 while I sleep. Writing one article reaches thousands. That's media leverage. The stock dashboard is code leverage, runs 503 analyses in minutes.

Second-Order Thinking

What it is: Think beyond the immediate consequence. "And then what?" First-order: the obvious effect. Second-order: the effect of the effect.

When I use it: Policy changes, incentive design, pricing decisions. Most bad decisions come from stopping at first-order effects.

Example: Cutting prices to gain market share (first-order: more customers). Second-order: competitors match, margins compress industry-wide, you're worse off. Third-order: only the lowest-cost operator survives.

Inversion

What it is: Instead of asking "how do I succeed?", ask "how would I guarantee failure?" Then avoid those things.

When I use it: Risk assessment, product launches, hiring decisions. Especially useful when you're stuck on the positive framing.

Example: Before launching a new product: "What would make this fail catastrophically?" Usually surfaces risks that optimistic planning misses, dependency on a single vendor, no rollback plan, unclear ownership.

Circle of Competence

What it is: Know what you know, know what you don't know, and stay honest about the boundary. Operate inside your circle; learn at the edges.

When I use it: Investment decisions, career moves, delegation. The most dangerous decisions happen when you think you understand something you don't.

Example: I know product, operations, and AI integration. I don't know deep ML research. So I hire ML engineers and trust their technical judgment while I focus on product-market fit and go-to-market.

Occam's Razor

What it is: Among competing explanations, the simplest one is usually correct. Don't multiply complexity without necessity.

When I use it: Debugging, root cause analysis, system design. When a system breaks, check the simple things first, permissions, typos, config, before suspecting complex failures.

Example: Production incident: "Is it a distributed systems race condition?" No. Someone deployed to the wrong branch. Check the simple explanation first.

The Map Is Not the Territory

What it is: Models, dashboards, and reports are simplifications of reality. Don't confuse the representation with the thing itself.

When I use it: Data-driven decisions, financial models, org charts. The stock valuation dashboard I built is a model, useful, but not truth.

Example: A DCF model says a stock is worth $150. The model is built on assumptions about growth rates, discount rates, and margins. Change any assumption by 1% and the output shifts 20%. The map is useful. It's not the territory.

Hanlon's Razor

What it is: Never attribute to malice that which is adequately explained by ignorance, miscommunication, or incompetence.

When I use it: Cross-team conflicts, customer complaints, partner negotiations. Most friction comes from misalignment, not bad intent.

Example: A partner team ships a breaking change without telling you. Your instinct: "They don't respect us." Reality: they forgot, or their notification process is broken. Start with that assumption and you'll resolve it faster.

The Feynman Technique

What it is: Explain a concept in simple language as if teaching a child. Where you stumble, you don't truly understand it.

Note: Strictly, this is a learning technique rather than a decision-making model, it tells you whether you understand something, not what to do. I keep it here because it's the tool I reach for to pressure-test my own grasp before I rely on any of the models above.

When I use it: Learning new domains, preparing presentations, writing specs. If you can't explain it simply, you haven't understood it deeply enough.

Example: I use this constantly when writing /thinking articles. If I can't explain AI-DLC to someone outside tech, my framework has gaps.

What is a mental model, really?

The everyday usage above is loose, "a useful thinking tool." The term has a more precise lineage worth knowing, because it sharpens what these things are and what they are not.

The phrase was coined by the Scottish psychologist Kenneth Craik in The Nature of Explanation (1943). He argued that the mind builds "small-scale models" of reality and runs them forward to anticipate events, the same way an engineer tests a scale model before building the bridge. A mental model, in this original sense, is an internal simulation of how some part of the world works.

The cognitive scientist Philip Johnson-Laird formalised this in Mental Models (1983), proposing that people reason not by formal logic but by constructing and manipulating these internal models, which also explains why we reason badly when our model is incomplete or wrong.

In systems thinking, Peter Senge (The Fifth Discipline, 1990) defined mental models as "deeply ingrained assumptions, generalisations, or even pictures or images that influence how we understand the world and how we take action", emphasising that they are often invisible to the person holding them, which is exactly why surfacing and testing them matters.

The popular, decision-making sense used on this page comes mostly from Charlie Munger, who urged building a "latticework of mental models" drawn from many disciplines, physics, biology, economics, psychology, so that you have a repertoire of lenses rather than, as he put it, "a man with a hammer, to whom every problem looks like a nail." This is the framing behind the list above: not one master theory, but a toolkit of complementary lenses you learn to reach for by reflex.

Sources: Craik, K. (1943) The Nature of Explanation; Johnson-Laird, P. (1983) Mental Models; Senge, P. (1990) The Fifth Discipline; Munger, C. "A Lesson on Elementary, Worldly Wisdom" (1994), collected in Poor Charlie's Almanack.

This list evolves. I add models when I find myself reaching for the same pattern repeatedly. I remove them when they stop being useful. The goal isn't to collect models, it's to internalize them until they become reflexive.

Want to see one of these applied? I go deep on first-principles thinking for product decisions in the Product Management playbook.