How to Improve Your First Principles Thinking Skills

Most product decisions get made by analogy. Someone says, "This is how we've always done it," or "This is what the market expects," or "This is what the competition is doing." The room nods. The decision gets made. And buried somewhere in the middle of all of it is an assumption nobody checked.

First-principles thinking is the discipline of identifying assumptions before the market finds them for you. By the end of this episode, you'll have the tools to strip any problem down to what's actually true and build answers that hold, even when the boardroom is watching, and the clock is running.

... or listen to the podcast.

What Is First Principles Thinking?

First principles thinking is the practice of breaking a problem down to its fundamental truths, then building your solution up from what actually holds. Not from industry convention. Not from what worked last time. From what's actually true about the problem in front of you.

The alternative is reasoning by analogy: doing what worked before, doing what competitors do, doing what the category expects. Analogy is faster and usually right. It fails badly when the thing that used to be true stops being true and nobody notices.

Why Assumptions Go Unchecked

In 2005, HP's CEO, Mark Hurd, stopped me in the hallway at Building 20 in Palo Alto and drilled me on HP's R&D funding. The metric he focused on was R&D as a percentage of revenue. He wanted HP's ratio to look more like Acer's. I pushed back. I argued we should be comparing ourselves to Apple, not Acer. Mark didn't hesitate. "We are not Apple, and we never will be."

What stopped me in that moment wasn't the disagreement. It was the certainty. Nobody in the room questioned whether R&D as a percentage of revenue actually measured what we thought it measured. That metric had been in use for decades. Every competitor used it. Every analyst tracked it. It felt like bedrock.

It wasn't. It was an inherited constraint that had calcified into a rule. R&D as a percentage of revenue tells you about accounting categories. It tells you nothing about what that spending produces, whether the right problems are being attacked, or whether innovation output is growing or shrinking. The assumption underneath the metric had never been tested. Nobody had ever asked whether comparing R&D ratios across companies with entirely different business models actually tells you anything meaningful.

The cost of that unchecked assumption didn't show up in the next quarter. It showed up over the following decade. HP's innovation pipeline quietly drained, and the Fast Company "Most Innovative" recognition we'd earned three years running disappeared with it. One inherited metric, accepted as fact by an entire room of experienced people, making a generational decision.

That's what derivative thinking actually costs. Not a bad quarter. A decade.

The people in that room weren't careless. They were experienced. Experience is exactly what makes inherited assumptions feel like facts. The metric felt like a fact. It was a choice nobody remembered making. That's exactly what a first principles question would have caught. Nobody asked it.

The Three Core Skills

The three skills run in sequence, and each one depends on the one before it. The first, Strip the Assumptions, finds the inherited assumptions baked into how the problem was framed. From there, Test What Remains and Build Up takes what survived and builds your solution from what's actually true. Finally, When to Use First Principles tells you when the process is worth running in the first place. Skip ahead, and the later skills don't hold. Run them in order, and they compound. 

Strip the Assumptions

Before you can reason from first principles, you have to know what you're actually working with. Most problems arrive already carrying assumptions in how they're framed. Your first job is to find them.

Steps to strip assumptions:

1. Write the problem exactly as it was given to you. Don't improve the framing yet. Use their words.
2. Underline every word that implies a constraint. "Must," "can't," "always," "never," "the only way to." Each one is a candidate.
3. Ask, for each constraint: is this physically true, or is it inherited? A physical truth holds regardless of what you decide. An inherited constraint is someone's prior decision that calcified into a rule.
4. Set the inherited constraints aside and restate what remains. This is the real problem. It's usually smaller and easier to solve than what you started with.
5. Treat what survives as your design constraints. These are your real boundaries. Take this list into your brainstorming, and test every idea against what's on it, not against the assumptions you crossed out.

This step takes 20 minutes when you do it honestly. Most teams skip it entirely, then spend months optimizing a solution to the wrong problem.

Test What Remains and Build Up

Not every constraint is an assumption. Some things are actually true: physics, unit economics, human behavior at scale. The goal isn't to pretend those constraints don't exist. It's to be precise about which reality you're dealing with.

Steps to test what remains and build up:

1. Take each surviving constraint and push on it. Ask: Is this true because it's physically impossible to change, or because changing it would be expensive, unfamiliar, or uncomfortable? Expensive and unfamiliar are not the same as impossible.
2. Separate the hard limits from the soft ones. Hard limits are what's actually true: things that hold regardless of how the problem is reframed. Soft limits are negotiable. Label them clearly. Most teams never make this distinction and treat every constraint as if it were granite.
3. State your hard limits in plain language.  Write it down. One sentence per hard limit. These are the actual boundaries your solution has to honor.
4. Reason forward from what remains. Don't start from where the industry is and work backward to justify it. Now ask: what solution do the hard limits support? 

That last step is where unexpected solutions come from. When you reason backward from convention, you arrive at a modified version of the existing answer. The shape is familiar because you started with it. When you reason forward from hard limits, you land somewhere the category didn't expect, because you weren't anchored to the shape of the existing answer. Solutions built this way often feel strange at first. People will question them. That discomfort is usually a signal you've found something real rather than something inherited. That's what reasoning from what's actually true produces, rather than reasoning from what everyone assumed.

When to Use First Principles

Before running the process, ask these four questions. One yes is enough.

1. Has the environment this decision was built for changed significantly?
2. Does every solution on the table feel like a variation of the same thing?
3. Is the current approach inherited rather than chosen?
4. Would a bad assumption here cost you more than an afternoon to find and fix?

If all four are no, past experience is the right tool. Use it. 

The 20-minute assumption-strip is cheap. The cost of skipping it isn't.

The Assumption Reversal Exercise

For this exercise, you will need a partner. Have them watch this video first. They need to know what an inherited assumption looks like before they can spot yours. Once you're both ready, grab the free First Principles Thinking Checklist at innovation.tools or find the link in the description. It gives you both a shared reference point before you start. 

Here is how it works:

1. Each person brings one real problem. Something current, with actual stakes. Not a thought experiment. The problem should be one you've been turning over in your mind without arriving at a satisfying answer.
2. Work on your partner's problem, not your own. You are trying to find the assumptions baked into how they've framed it. They are doing the same for yours. The reason this works is that you can see their inherited constraints more clearly than they can. You're not inside their problem the way they are.
3. Each person lists every assumption they can find in the other's problem. Write them down. Don't argue yet. Don't evaluate. Just surface as many as possible. Quantity matters here. The obvious assumptions are easy. Push past them.
4. Take each assumption and reverse it. If the assumption is "this requires a significant budget," the reversal is "what becomes possible if it requires no budget?" If the assumption is "the customer won't accept a different format," the reversal is "what would we build if they would?" Don't ask whether the reversal is realistic. Ask what it opens up.
5. Discuss what the reversals revealed. Not every reversed assumption leads somewhere useful. But one of them usually exposes a constraint that was never as fixed as it felt. That's the one worth following.

The point of the reversal is simple. Some assumptions hold when you push on them, and some don't. You can't tell which is which until you try.

The Long Game

Every time you run this process and find something that didn't hold, you get faster at spotting them. The judgment about when to use it gets sharper. That's what improvement looks like in practice: not a dramatic flash of insight, but a practiced ability to find the assumption in the room before it finds you.

The assumption that costs you most isn't the one you haven't thought of yet. It's the one you stopped questioning years ago. 

Find your partner. Run the Assumption Reversal this week. That's where this starts becoming a skill.

Subscribe for the next episode. It builds on this.