First-Principles Thinking: How to Separate Real Constraints From Conventions

The data processing bill went up again. The team opens a negotiation with the vendor and secures a 20% discount. At the wrap-up meeting, someone asks: “why does this pipeline run every hour?” Nobody can answer. It’s always been that way.

Negotiating is useful, but it accepts the problem as inherited. First-principles thinking goes the other way: it takes the problem apart down to what really has to be true and rebuilds the solution from there.

What first-principles thinking is#

First-Principles Thinking is the practice of breaking a problem down to fundamental constraints, demonstrable mechanisms and assumptions that can be questioned.

The expression comes from Greek philosophy. Aristotle opens the Physics by saying that scientific knowledge comes from knowing the principles, conditions or elements of a subject (Aristotle, Physics). In the Metaphysics, a first principle is, in one sense, the first basis from which a thing is known (Wikipedia).

In everyday work, the term is used far more loosely. Logic has axioms. In physics, you can calculate from established laws. In a company, almost nothing is that firm. What a team calls a first principle is usually the most solid constraint it has managed to verify. That humility prevents the method’s most common error: calling an opinion a fundamental truth.

Analogy and first principles#

Most good decisions are made by analogy, and that’s no flaw. Copying what worked elsewhere is fast and draws on other people’s experience. The problem appears when the analogy carries assumptions that no longer hold.

Not all constraints are equal#

The most useful step in the method is classifying what seems impossible. Each type calls for a different response:

Much of what a team treats as a constraint falls in the last two rows.

Questions that separate fact from convention#

A few simple questions are usually enough to start classifying:

• Who requires this? A real requirement has an owner, such as a customer, a contract or a law.
• Where is it written? If nobody can find the document, it may not exist.
• When was this decided? Prices, technology and company size may have changed since then.
• What would happen if we stopped for a week? The answer shows what really depends on it.
• Who loses if it changes? Sometimes the convention protects a legitimate interest, and that has to come up in the conversation.

When to use it and when to avoid it#

How to apply it#

Step 5 deserves attention. In The Thing, from 1929, G. K. Chesterton describes a reformer who wants to remove a fence across a road. He advises that person to go away, think and come back only after understanding what the fence is for. The idea became known as Chesterton’s fence: not knowing why something exists is different from knowing it isn’t needed.

Worked example: the cost of processing data#

A company runs an analytics pipeline every hour, which means 720 times a month. Each run processes 2 TB, at a price of 10 units per TB. There’s also a fixed 4,000 units a month for orchestration, storage and network.

Breaking down the cost#

The current cost is 4,000 + 2 × 720 × 10 = 18,400 units a month. The 20% discount lowers the price to 8 and brings the cost to 15,520, a 16% drop. The formula shows the limit of that route: it touches a single term, and not even the one the team controls most. Volume and frequency remain untouched.

Separating fact from convention#

The team lists what everyone took for granted and goes to check each item:

Of the 2 TB, 1.2 TB is in use: 0.3 TB for anti-fraud, which needs hourly data, and 0.9 TB for dashboards read once a day.

The investigation also found a Chesterton’s fence. Full reprocessing exists for a real reason: some events arrive late. Anyone removing it without asking would start publishing wrong numbers. So any incremental alternative must keep a periodic full load.

Rebuilding the alternatives#

The 5-year retention requirement stays out of the conversation, because it’s the law, and it concerns keeping data, not reprocessing it. The team builds three alternatives:

• A, remove what nobody reads. 1.2 TB × 720 runs = 864 TB a month.
• B, remove and split by need. Anti-fraud stays hourly, with 0.3 × 720 = 216 TB. Dashboards run daily, with 0.9 × 30 = 27 TB. The total is 243 TB.
• C, add incremental processing to anti-fraud. That’s 0.03 × 720 = 21.6 TB, plus 27 TB for dashboards and 1.2 TB for four full loads a month. The total is 49.8 TB.

Each option’s monthly result, in TB and currency units:

The largest cut isn’t necessarily the best choice. Assuming 6,000 units per engineering week, with the gain in units per month:

Three readings:

• The terms multiply. That’s why cutting volume and frequency together yields far more than negotiating price.
• The fixed part becomes the floor. In option C, 4,000 of the 4,498 units are fixed. After B, the next question is about another term in the formula.
• C doesn’t pay off for now. Eight weeks of work, plus the complexity of incremental processing, yield little. The team goes with B and keeps C as an option in case volume grows.

None of this rules out the discount. Negotiating still makes sense, but after knowing what really needs to be bought.

Which assumption weighs most#

B’s numbers depend on two assumptions, and one weighs much more than the other. If only 20% of the volume were unused, rather than 40%, B’s cost would barely rise: from 6,430 to 6,550 units. If, on the other hand, 0.9 TB had to run hourly rather than 0.3 TB, it would reach 10,570 units.

In other words, the result is barely sensitive to unused tables and highly sensitive to what requires hourly data. That’s the assumption that deserves the most careful check.

Testing before migrating#

Each alternative has a risky assumption that can be tested cheaply:

• “Only anti-fraud needs hourly data.” The team interviews dashboard owners and cross-checks the answers with read times.
• “Dashboards can live with a day’s delay.” The team changes the frequency of a single dashboard, warns users and tracks requests and decisions for two weeks.
• “Nobody reads these tables.” Ninety days of logs won’t show an annual report. The team hides the tables for a month before deleting them, and watches who complains.

Only after that does the full migration come.

The same reasoning outside technology#

The method isn’t only for systems. Imagine a company where every purchase over 1,000 units requires three signatures, and each request takes nine days. The real goal is to prevent improper spending. The audit requires only one independent approval above a certain amount. The other two signatures came from an old incident, in a structure that no longer exists.

The fence, in this case, is the incident itself: it’s worth understanding what happened to make sure the new process covers that risk. The rebuild might keep one independent approval, add an automatic vendor check and review a sample each month. This example is hypothetical too, and the change would also start with a test, in a single area.

Common mistakes#

• Calling an opinion a principle. “Our customers would never pay for this” is a hypothesis, even when said with conviction.
• Confusing ignorance with convention. Not knowing the reason for something doesn’t prove there isn’t one.
• Breaking things down forever. You can always go deeper. Stop when the parts are verifiable and allow you to act.
• Reinventing what works. If the standard solution does the job, the reasoning has served its purpose by confirming that.
• Forgetting the cost of change. Migration, training and integration go into the math too.

What’s known about the method#

To be direct: this research found no studies showing that “thinking from first principles” improves results as a management method. The term’s popularity comes from stories, not experiments. Its strength lies in logic: if an assumption is false, whatever depends on it deserves review. That’s useful, but it’s a different kind of support from what other frameworks have.

How to use an LLM#

An LLM is good at listing hidden assumptions, proposing breakdowns and suggesting alternatives. Its risk is presenting industry conventions as if they were laws, with the same confidence as a fact. Give it the real constraints and require every claim to be classified.

I want to investigate [problem] using first-principles thinking.
Real goal: [result].
Non-negotiable constraints: [security, SLA, legislation, etc.].
Current solution and cost: [describe].
Team assumptions: [list].

Separate proven facts from conventions and hypotheses. Break the problem
down into fundamental needs, identify assumptions that can be tested and
propose three new architectures or approaches. For each alternative,
describe trade-offs, risks and a validation experiment. Don't treat
arbitrarily chosen principles as laws.

Expected output: a reframing of the problem and alternative solutions.

Before trusting the answer:

• Ask where each “fact” comes from. If the model doesn’t know, treat it as a hypothesis.
• Look for the fence. Ask why a sensible team would have created the convention it suggests removing.
• Redo the math. Numbers and savings estimates must come from your data.
• Sanitize the context. Internal architecture, contracts and real costs shouldn’t go into public tools.

Combine it with other frameworks#

• MECE principle: helps break the problem down without overlaps or gaps.
• 5 Whys: seeks the cause of an observed problem; first principles question the shape of the solution itself.
• Lateral thinking: generates alternatives through deliberate association, while first principles rebuild them from fundamental premises.
• Cost-benefit analysis: compares the alternatives over time.
• Hypothesis testing: validates the riskiest assumption.

References#

1. Aristotle. Physics, Book I. Translated by R. P. Hardie and R. K. Gaye. Link
2. Chesterton, G. K. (1929). The Thing. Chapter “The Drift from Domesticity”.
3. Wikipedia. First principle. Link