『How to Improve Your First Principles Thinking』のカバーアート

How to Improve Your First Principles Thinking

How to Improve Your First Principles Thinking

無料で聴く

ポッドキャストの詳細を見る
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. 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: Write the problem exactly as it was given to you. Don't improve the framing yet. Use their words. Underline every word that implies a constraint. "Must," "can't," "always," "never," "the only way to." Each one is a candidate. 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. 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. 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...
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません