3 Decision Frameworks Used by a Fighter Pilot, a General, and Elon Musk (And None Are What You Expect)

· 6 min read

3 Decision Frameworks Used by a Fighter Pilot, a General, and Elon Musk (And None Are What You Expect)

Over 15 documented frameworks exist for making better decisions. Some come from Greek philosophers. Others from military commanders. Others from the world’s best investors.

Most builders in 2026 use none of them.

Not because they’re complicated. But because nobody connects them to the reality of building products, making decisions under pressure, and moving forward when you have twelve fronts open at once.

These are the three that have most changed how I think.

1. The Eisenhower Matrix: Productive at the Wrong Things

Dwight D. Eisenhower was Supreme Allied Commander in World War II and later the 34th President of the United States.

He had more urgent things on his list than most of us will have in our entire lives. And yet, he made long-term decisions that changed the century.

His quote says it all:

“I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.”

The framework he developed from this observation is simple: a four-quadrant matrix.

Urgent

Not Urgent

Important

Do it now

Schedule it

Not Important

Delegate it

Delete it

What nobody tells you is that most people live in the urgent-not-important quadrant. Notifications, meetings without agendas, other people’s requests, small fires to put out.

And the truly important things—building the right product, validating the idea before scaling, learning the skill that changes your trajectory—can always wait. Until they can’t.

Applied to my daily routine in 2026: before opening email or checking metrics, I ask myself what important-not-urgent task I’m going to protect today. Without that, the day consumes me.

Concrete action: Take your task list for today. Classify each one into the four quadrants. If more than 60% is in “urgent”, you have a work design problem, not a productivity problem.

2. The OODA Loop: The Fighter Pilot Framework Used by Investment Banking

John Boyd was a colonel in the United States Air Force. They called him “Forty-Second Boyd” because he challenged any pilot to an aerial duel with a 40-second disadvantage… and always won.

His theory: he didn’t win because he was more skilled. He won because he cycled faster than his opponent.

That’s how the OODA Loop was born:

  • Observe — Gather information from the environment
  • Orient — Filter and interpret that information with your context
  • Decide — Choose an action
  • Act — Execute

Then you go back to the start. Faster than your competitor.

The fascinating thing about this framework is that the key isn’t in any of the four steps separately. It’s in the speed of the complete cycle. The one who cycles through Observe → Orient → Decide → Act fastest controls the situation. The other is always reacting to outdated information.

CEOs of massive-scale financial institutions use it for exactly this reason: in environments where information changes every hour, the one who takes three weeks to decide has already arrived too late.

For an indie builder in 2026, the OODA Loop changes how you see iteration. It’s not that you launch fast just because. It’s that you launch fast to enter the cycle as soon as possible. Every user who uses your product is new information for your Observe phase. Every piece of feedback is Orient. And if you take a month to decide what to do with that feedback, your competitor is already two cycles ahead.

Concrete action: The next time you get user feedback or a metric that surprises you, set a 48-hour limit to go through all four steps: observe the data, interpret it in context, decide on an action, and execute it. Even if it’s a small action.

3. First Principles: The Question That Cuts 90% of Assumed Cost

This wasn’t invented by Elon Musk. Aristotle invented it over two thousand years ago: decompose anything to its fundamental truths and build from there, without the assumptions accumulated by convention.

Musk modernized it with a brutal example.

When he wanted to build rockets, the market price was astronomical. Everyone assumed that’s just how rockets were, they’d always been expensive, and that was that. Musk asked: what are they actually made of? Aluminum, titanium, copper, carbon fiber. How much do those materials cost on the market? The number came out to a fraction of the final price. The difference was pure assumed cost, not real cost.

“I think people’s thinking process is too bound by convention or analogy to prior experiences.” — Elon Musk

This applies directly to how we build products.

Many builders in 2026 assume they need a perfect landing page before validating. Or that they need their own backend before scaling. Or that market X is impossible to attack because there are already big competitors.

None of those things are fundamental truths. They’re inherited assumptions.

First Principles forces you to do three things:

  1. Identify what you’re assuming without having verified
  2. Decompose it to the bare truth
  3. Build the solution from there, not from convention

I learned this the hard way with a project last year. I assumed I needed complete authentication before testing whether anyone would use the tool. It took weeks. Nobody used it. The fundamental truth was: does anyone have this problem? I could have asked that in 48 hours.

Concrete action: Take your next important decision and ask: what am I assuming here that I’ve never verified? Write down the assumptions. Then, for each one, ask: is this a fundamental truth or something I took for granted because it’s always been done this way?

The Pattern That Connects All Three

Look at the three frameworks together:

  • The Eisenhower Matrix tells you what to focus on
  • The OODA Loop tells you how fast to move
  • First Principles tells you where to start from

They’re not interchangeable. They’re layers. And all three share an obsession: eliminating the noise that prevents you from seeing what really matters.

In previous posts I’ve talked about Munger’s incentives, Taleb’s antifragility, and Naval’s hourly rate. They all point to the same place from different angles: your worst decisions aren’t ones you make with bad intentions, they’re the ones you make without a system.

These frameworks are that system.

The Trap of Collecting Frameworks

A warning: reading about frameworks is useless.

I’ve seen people with 40 mental models books who make worse decisions than someone with zero books and lots of field experience. Knowledge without application is intellectual decoration.

Pick one this week. Just one. Apply it to your most important current decision. Document what changed.

Frameworks only work when you use them. The rest is nice theory to talk about on Twitter.

Keep building.

Brian Mena

Brian Mena

Software engineer building profitable digital products: SaaS, directories and AI agents. All from scratch, all in production.

LinkedIn