Reasoning from First Principles: How to Find the Problem Nobody Could Explain

How to Reason from First Principles

There are four steps. Simple to describe and hard to execute, because at every stage your experience will try to shortcut you back to the last fix.

Step 1: Define the Problem Precisely

Not the symptom — the problem. These are rarely the same thing.

The symptom is what the team is complaining about. The problem is what is actually causing it. A week of questions — how does this work, why does it do this, what is happening here — showed me that the team knew the system was broken.

That wasn’t the problem. The problem was that nobody could explain how the system made its decisions. Until you can state that in one clear sentence, you haven’t defined the problem yet.

This distinction matters more than it sounds. Most problem-solving stalls at this stage, not because the team lacks answers, but because they are answering the wrong question. Defining the problem precisely is what makes every subsequent step productive rather than circular.

Step 2: Break It Down to Its Components

Decompose it into inputs, rules, and outputs — mapped from scratch, not from memory. For the job allocation system, that meant identifying every input: engineer areas, skillsets, available days, job types.

Then the rules governing how those inputs produced an output, and the flow from client job to allocation decision. None of this was documented. Mapping it took time.

But it was the only way to see the whole picture. Without the map, you are still operating from assumption. You think you know how the system works. You don’t yet.

Step 3: Question Every Assumption

The team had a decade of beliefs about how the system worked. Most were approximately right. Some weren’t. Treat each one as a hypothesis: ask what evidence supports it and what would have to be true for it to hold. One way to do this systematically is through inversion — asking not what would make this work, but what would make it fail.

When we did this, beliefs fell quickly. The ones that remained were the ones we could actually build from.

This is the step that experience fights hardest. A decade of working knowledge feels like understanding. It isn’t — it is a collection of observations that have never been tested against the fundamentals.

Step 4: Rebuild from What You Know to Be True

This doesn’t mean rebuilding the system itself. We didn’t have the capacity to rewrite the software from scratch, so we built a model that replicated what it did.

It was in the modelling that we found the open door.

There was no cap on work allocation.

The setting had been a deliberate decision by the MD, made when volumes were 20% of what they were when we got involved. It was never documented. Nobody who came after him knew it existed.

The inherited belief that the system was managing volumes correctly had never been tested against the reality of what the business had become.

We couldn’t cap the work. So we increased the capacity of the network — more engineers, targeted to the areas and skill types where the modelling showed the greatest overload. Six months from the first question to a solution that held.

That is reasoning from first principles. You don’t just solve the problem differently. You find the problem that was actually there.

First Principles Thinking in Practice: Two Leaders Who Got It Right

The job allocation story is one version of this. There are others.

Nick Kokonas and the Restaurant That Reinvented Itself

Nick Kokonas co-owns some of Chicago’s most acclaimed restaurants. When his partner, head chef Grant Achatz, became seriously ill, Nick had to take a more active role in the day-to-day running of the business.

He was observant. He noticed empty tables on a Tuesday evening and overbooking on a Saturday night. He asked why.

Nobody could adequately explain it. That is just the restaurant trade, was the answer. Nick didn’t accept it.

As he kept asking, the picture came into focus. Demand for Friday and Saturday tables was high, with bookings going weeks ahead, but some customers wouldn’t show, leaving empty tables and lost revenue. To compensate, the restaurant would overbook.

Then customers calling for a table for two would find only a six-top available. They would book it, arrive as a pair, and the four empty seats represented another loss. The same problem, wearing a different face.

Nick stripped it back. When he cleared the assumptions, two fundamental truths became clear: customers could book without any commitment, and weekdays were structurally different from weekends in terms of demand.

Once he had those two facts, the solution followed. His restaurant was no different from a theatre — in a theatre, the better the view, the more the seat costs.

Apply the same logic and the busier the night, the more a table should cost. Quieter nights could be priced to fill. And just as you pay for a theatre seat upfront and still pay whether you show up or not, the same principle applied to a restaurant reservation.

Nick built an online booking system with dynamic pricing and upfront deposits. Customers had skin in the game. Empty tables became rare.

Occupancy hit levels the industry hadn’t seen before. The system Nick built to solve his own problem became Tock — software he licenced to other restaurants facing the same situation.

The lesson isn’t that Nick was clever. It is that he kept asking why until he understood the fundamentals, then reasoned forward from there.

Elon Musk and the Question Nobody Else Asked

Most people in the aerospace industry reasoned by analogy. Rockets have always been expensive, therefore rockets will always be expensive. Elon Musk framed it directly: that is not true — that is just reasoning by analogy.

His own description of this approach was a physics framework — boiling a problem down to what the laws of nature actually permit, then reasoning forward from there.

His starting point was a question that sounds almost naive: what is a rocket actually made of? Aerospace-grade aluminium, titanium, copper, and carbon fibre. Then he asked what those raw materials cost on the open market.

The answer stopped him. The materials cost of a rocket was around two percent of the typical purchase price.

The gap between what a rocket cost and what it needed to cost wasn’t driven by physics. It was driven by inherited assumptions about manufacturing, suppliers, and the way the industry had always worked.

Musk had been quoted prices as high as $65 million when trying to buy a rocket before founding SpaceX. By sourcing raw materials and manufacturing in-house, SpaceX brought a launch cost down to $6 million — less than a quarter of the cheapest competitor price at the time.

That result didn't come from one decision. It came from feedback loops that let Musk test every assumption against reality as the builds progressed.

But the number isn’t the point. The method is. In Musk’s own framing: the first-principles approach is a good way to understand what new things are possible. It lets you determine whether success is even one of the possibilities — and that is the question most people never ask, because they have accepted the inherited constraint as fixed.

What transfers to any leader isn’t the scale. It is the habit of asking what is actually, fundamentally true about the problem — and refusing to accept the industry answer as the final word.

The Decision You Keep Solving the Same Way

My GM’s instruction was simple. Find the root cause. Then fix it.

What he didn’t give me was a way to do it. Reasoning from first principles was how I found one — not because I knew the term, but because the problem left me no other option.

Most recurring problems have the same shape. The fix exists. It gets applied. The problem returns. Somewhere underneath it, there is an assumption made in a different context, inherited without that context, never revisited because the system appeared to be working.

That is why knowing your principles — the foundational beliefs you are actually operating from — matters before any framework can help.

The MD’s decision about work allocation wasn’t wrong when he made it. It was made for a business running at 20% of the volume it would eventually reach. Nobody documented it.

Nobody tested it against the new reality. And so it sat inside the system, invisible, doing quiet damage until the weight of the business made it visible as a problem nobody could explain.

That is the root cause you are looking for. Not the symptom the team keeps patching. The assumption that was reasonable once and never got revisited.

The question isn’t whether you have a problem like this. You do. The question is whether you are willing to go looking for it. If the problem runs deeper than one decision, thinking strategically gives you the longer frame.

What is the problem your team has been circling for three months — the one where the fix keeps not sticking?

That is the one worth breaking down.