First Principles Thinking

🔍Step 1: identify inertial assumptions #

Put every 'that's how it's done' into a sentence

Write down, without exception, the premises underneath the current way of doing things: 'this feature needs a server', 'we can't sell below this price'. Until written down, assumptions are as invisible as air. The best collection tool is the questions of newcomers and outsiders; every spot where 'why do you do it this way?' gets answered with 'that's just how it is' is a candidate.

Sorting the assumptions #

Law of physics, regulation, or mere convention

Sort the written assumptions into three grades. Laws of nature and mathematics cannot be touched; regulations and contracts are expensive but changeable; conventions and industry lore are simply things nobody ever questioned again. The fact that the third category overwhelmingly dominates in most organizations is itself the harvest of this step. The fastest litmus test for grading: has anyone, anywhere, ever violated this?

🔨Step 2: decompose #

Down to facts that cannot be split further

Break the problem into components, and keep splitting until each piece is a verifiable fact. 'Cloud costs are high' is not decomposition; you have to get down to average compute per request, the market price of a unit of compute, and the traffic distribution. Along the way you often discover the problem statement itself was wrong, and that is a common bonus of this step.

The unit of decomposition #

BOM for costs, necessary conditions for processes

How far down you go depends on the subject. For physical goods it is the bill of materials (BOM) and market unit prices; for software cost it is the raw units of compute, storage, and transfer; for a process it is the requirements each step genuinely has to satisfy. There is one test: if a third party can independently verify the value of a piece, you have reached a fact unit.

🏗️Step 3: reassemble #

Rebuild the best solution on top of the facts

Assemble a solution from a blank page using only the facts the decomposition produced; the existing solution is not a reference but a benchmark. If the reassembly lands on the same approach as before, that is not failure: you now use that approach because the facts support it, not because others do, and its defensibility is entirely different. If it lands somewhere different, you must be able to point at exactly which assumption you discarded to get there.

Reassembly discipline #

Name the discarded assumption at every divergence

Wherever the new solution splits from the old one, attach a tag saying 'because we dropped assumption number N'. Without those tags, reassembly is indistinguishable from just another novel idea, and arguments with skeptics collapse into taste. The worst case is discovering later that a discarded assumption was actually a regulation, which is why the sorting from step one gets summoned again here.

Trap: stopping at decomposition #

Critique without reassembly is half the job

Many sessions end with the thrill of smashing assumptions: a list of holes in the current approach, and no alternative. Decomposition is only an intermediate product; the deliverable is always a reassembly plan, 'so this is what we do differently'. Fixing the output format before the session starts (a new proposed structure plus the list of discarded assumptions) avoids this trap most of the time.

🪞Contrast with analogy #

Not an enemy, a tool for a different job

Analogy borrows a proven approach: fast, cheap, and mostly right. Nine out of ten everyday decisions should be handled by analogy. First principles is the tool you pull out when analogy jams, that is, when the cost of the standard approach looks structurally wrong or everyone is stuck at the same wall. Declaring you will do everything by first principles usually leads to finishing nothing.

When to use which #

Judge by reversal cost and the price of convention

If a decision is easy to reverse, go fast with analogy and fix it if wrong. If it is hard to reverse (architecture, long-term contracts) and the local convention smells unusually overpriced, you are in first principles territory. A good signal: an item everyone complains about the cost of while nobody has ever recomputed its structure.

💰Applied: cost structure #

Recompute from raw units, not from quotes

'The vendor quote is about this much' is analogy. By first principles, you take the raw materials the service consumes (compute, storage, hours of labor), multiply by market unit prices, and construct the theoretical floor price. The gap between quote and floor is your negotiating room or your insourcing opportunity. The textbook case of this pattern: the calculation that rocket materials cost a single-digit percentage of the finished price, which led to reusable rockets.

Finding the cost floor #

Dissect the gap into three components

The gap between the theoretical floor and the actual price usually decomposes into three parts: the supplier's margin, inefficiency (bundled features you do not use), and a risk premium. The response differs by which one dominates. For margin, negotiate and run competitive bids; for bundling, redefine the requirements; for risk premium, calculate whether to absorb that risk yourself.

⚙️Applied: technology choice #

From the 'everyone uses it' stack to the requirements stack

'Everyone uses this framework these days' is analogy, and most of the time it is good enough. First principles becomes necessary when that choice starts coming back as cost or constraint. Then you lay out the actual demands in numbers (traffic, latency budget, data size, the team's operational capacity) and derive the minimal configuration that satisfies them. A frequent conclusion: much of the fashionable stack is built for scale problems you do not have.

Requirements as physical quantities #

Turn adjectives into numbers and options shrink

Convert adjectives like 'high-volume', 'real-time', and 'scalable' into requests per second, allowed latency in milliseconds, and annual data growth. Once the numbers exist, more than half the candidate technologies eliminate themselves or stand revealed as overkill. If you cannot produce the numbers, that is not a technology-choice problem but an underdefined product, and postponing the choice is the correct decision.

⚠️Beware of overuse #

Start every meeting from a blank page and you sink

First principles is expensive per session; it takes days of the whole team digging out and verifying assumptions. The healthy allocation is to spend it on one or two structural questions per quarter and handle the rest quickly by convention. The person who throws 'but why?' at every agenda item is not a first-principles thinker; they are on their way to paralyzing the meeting.