Reason from the ground up
Start with what is true.
First-principles thinking is the discipline of taking a problem apart until facts, constraints and assumptions stop masquerading as one another. Then you build the answer back up—and try to break it before reality does.
What it is
Reason from bedrock, not resemblance.
Most decisions are made by analogy: find something similar, copy its shape and adjust the edges. That is efficient and often sensible. Roads, contracts, teams and software all contain knowledge earned the hard way. Starting from nothing every morning would be less revolutionary than exhausting.
First-principles thinking is for the moments when the inherited answer has become the problem. Instead of asking “How do organisations like ours do this?”, ask “What outcome is required? What is physically, legally or logically unavoidable? What is merely customary? What evidence would prove the new answer wrong?”
It is not permission to ignore experience. It is a way to inspect experience before promoting it to law.
A usable method
Take it apart. Keep the load-bearing parts. Rebuild.
Five moves are enough. The difficulty is doing them honestly.
- 01
Name the outcome.
Describe the change in the world, not the artefact you expect to buy. “People can complete their return accurately” is an outcome. “We need a tax portal” has already smuggled in a solution.
- 02
Separate facts from assumptions.
Facts can be observed or checked. Constraints are limits you must respect. Assumptions are claims that may be useful but have not earned either status. Write them in different columns.
- 03
Interrogate every constraint.
Ask why it exists, who owns it, what evidence supports it and what would happen if it changed. Repeat until the answer reaches law, physics, a deliberate policy choice or an observable need.
- 04
Rebuild from what survives.
Design the smallest complete system that produces the outcome while respecting the real constraints. Reuse old patterns when they still earn their place; remove them when they do not.
- 05
Try to falsify the answer.
Find the edge cases, incentives, operating costs and human behaviour that could make the elegant design fail. First principles begins with doubt and should end with evidence, not applause.
Keep the categories honest
Not everything you rely on is the same kind of true.
| Observation | What did we measure or witness, where and when? | “Seven of the last twenty cases returned for missing evidence.” |
|---|---|---|
| Definition | Which meaning or boundary are we choosing? | “Complete means submitted, acknowledged and recoverable.” |
| Constraint | What limits the available actions, and who can change it? | “Only an authorised officer may approve this payment.” |
| Assumption | What are we relying on without enough evidence? | “Most customers will configure this without help.” |
| Preference | Which outcome or trade-off do we value? | “A person should be able to leave with their data.” |
| Unknown | What have we not yet established? | “We do not know the support load at ten thousand users.” |
The categories can change. An assumption may become an observation after a test. A constraint may become a choice when its owner changes it. Keeping that movement visible is more useful than pretending everything in the brief arrived with equal authority.
Worked example · product pricing
Why is business software sold per seat?
Because business software is sold per seat. Different tiers unlock more users, more records and the features serious customers eventually need.
The product completes a valuable job, remains reliable and pays for its continued operation and improvement.
Hosting, support, compliance, product development, risk and a reasonable profit must be funded. Some costs grow with use; others barely move.
Every extra colleague creates equivalent cost. High prices signal quality. Deliberately incomplete tiers improve the product. Exit friction is acceptable retention.
Once those claims are separated, flat or usage-shaped utility pricing becomes a design option rather than an act of commercial vandalism. It is not automatically correct. Activation, support effort, operating margin and retention still have to prove it.
See the Anti-SaaS argument →Small examples, same discipline
Look beneath the familiar shape.
What are you actually buying?
Two boxes can contain the same active ingredient and dose while telling very different stories on the front. The useful comparison begins with what acts on the problem, then adds formulation, suitability and medical advice where they matter. Packaging is not pharmacology.
NHS explanation of medicine names →What makes revision work?
Hours at a desk are easy to count but do not guarantee recall. If the outcome is remembering later, test whether practising retrieval helps more than simply rereading. The method should answer to the result, not to how studious the session felt.
Research on retrieval practice →Why does a replacement lose features?
Teams often rebuild the screens they can see and call the missing behaviour “phase two”. Start instead with the observable obligations of the live system. If behaviour can be described and exercised, a modern replacement can be measured against it before the old path retires.
Four ways cleverness goes wrong
A clean sheet can still produce a dirty answer.
You call “unproved” false.
An assumption may be correct. Its status tells you how to handle it, not what verdict to reach. Test it before discarding it.
You remove the fence before finding the bull.
An awkward rule may encode a failure nobody remembers. Understand the reason it appeared before treating its inconvenience as proof of stupidity.
You optimise the object and forget adoption.
A technically superior answer can fail because people cannot understand, trust, buy or operate it. Persuasion and transition are part of the system.
You confuse raw inputs with delivered cost.
A product costs more than its materials. Integration, quality, distribution, recovery and risk remain real even when the underlying component is cheap.
The Five Whys, with one warning
Keep asking why. Stop pretending the fifth answer is magic.
Repeatedly asking why is useful because it moves a conversation from symptoms towards mechanisms. A missed deadline may lead to manual reconciliation, conflicting records, an unclear owner and finally a decision nobody made.
The number five is not sacred. A chain of “why” answers can also become a confident story invented after the event. Check each link against evidence, branch when there are several causes and distinguish a root cause from the condition that made it harmful.
The goal is not to reach a satisfyingly deep sentence. It is to reach a cause you can test and change.
Worked example · three approvals
Do not begin by declaring the bureaucracy stupid.
A workflow requires three people to approve every case. It is slow, work queues are growing and everyone agrees that the process is painful. That is a reason to investigate—not yet a reason to delete two approvals.
Find the work each approval performs.
One reviewer checks completeness, one has authority to commit expenditure and one applies specialist judgement to exceptions. The three boxes look repetitive. Their obligations are not.
See which controls catch real failures.
Sample ordinary, exceptional and adversarial cases. Record what each reviewer changes, what passes untouched and which harm the original control was meant to prevent.
Automate repetition without automating authority.
Deterministic checks can reject incomplete records. Independent reviews can run in parallel. Ordinary cases can take a shorter route while specialist judgement remains attached to genuine exceptions.
Test the new workflow against the old risk.
The redesign fails if a harmful action escapes, the evidence trail weakens, exceptions become invisible or the saved work simply appears in somebody else’s queue.
The result may still retain three approvals. That is not a failure of first principles. If each one carries a distinct, necessary obligation, the method has replaced frustration with understanding—and shown where the real delay lives.
First principles with AI
A model can challenge the frame. It can also decorate it.
Language models are excellent at generating alternative explanations, exposing possible assumptions and attacking a proposed design. They are also highly capable of turning a weak premise into a magnificent document.
- List the assumptions hidden in a brief
- Construct the strongest opposing explanation
- Generate alternative system boundaries
- Find exceptions and second-order effects
- Translate a question across disciplines
- Decide which supplied claims are factual
- Invent evidence for an attractive theory
- Treat consensus as proof
- Replace observation with elaboration
- Approve the conclusion it helped construct
The antidote is simple and slightly annoying: connect every load-bearing statement to an observation, source, calculation or explicit human decision. Reality remains the senior reviewer.
When to reach for it
Use the expensive thinking where inheritance is expensive.
First-principles work earns its cost when the current answer is failing, the environment has changed, a repeated assumption creates a large constraint, or the decision is difficult to reverse. It is particularly useful at product boundaries, in architecture, pricing, regulation and operating-model design.
Do not redesign a door handle from atomic theory because you are feeling intellectually frisky. Mature patterns often contain more knowledge than one person can reconstruct. The discipline is selective: inspect what controls the outcome, not everything that exists.
The thing to leave behind
A decision another person can inspect.
The change the system is meant to create, for whom and under which conditions.
Observed facts, authoritative sources, owned preferences and known unknowns.
The current arrangement and credible alternatives, not just the founder’s favourite answer in several hats.
The selected trade-off, its owner, its rejected counterexamples and the evidence used.
The measurement, date or changed condition that should reopen the decision.
First-principles thinking is complete when the dependency chain is visible. Another person should be able to see what the answer relies on, why it won and what would make it lose.
The practical test
Can you show which parts are true, chosen and merely inherited?
- What outcome would still matter if the current solution disappeared?
- Which constraints are legal, physical, logical or deliberately chosen?
- Which “facts” are actually predictions, customs or commercial preferences?
- What important knowledge might the existing design be carrying?
- What observation would make you abandon the new answer?
If those questions produce discomfort, the method is working.