First Principles Thinking
Core principle: Strip away assumptions, conventions, and analogies. Reduce everything to the fundamental truths you *know* to be true, then rebuild from there. Most thinking is by analogy — "we do it this way because that's how it's done." First principles asks: *why is it done that way at all?*
The Core Process
Step 1: Identify the Current Belief or Solution
State clearly what is currently assumed, accepted, or proposed:
- What is the existing approach?
- What problem is it trying to solve?
- What does everyone in this space assume to be true?
Step 2: Challenge Every Assumption
For each element of the current approach, ask:
- *"Is this actually true, or do we believe it because we've always believed it?"*
- *"Is this a constraint of reality, or a constraint of convention?"*
- *"What would have to be true for this assumption to be wrong?"*
Distinguish between:
- Physical constraints: Laws of nature, math, physics — these are real
- Resource constraints: Time, money, people — real but changeable
- Conventional constraints: "You can't do X" meaning "nobody has done X yet"
- Inherited assumptions: Decisions made for past conditions that no longer apply
Step 3: Identify the Fundamental Truths
What do you *actually* know, stripped of convention?
- What is the core need being served?
- What are the irreducible requirements?
- What would this look like if you designed it from zero, knowing only what's physically true?
Step 4: Rebuild From the Ground Up
Starting only from fundamental truths, reconstruct the solution:
- What's the simplest approach that satisfies the real requirements?
- What would this look like if invented today, with today's capabilities?
- What existing constraints can be eliminated now that you're not inheriting them?
Output Format
🏛️ Current Belief / Approach
State what's being questioned:
- The existing design, strategy, or assumption
- Why it exists (historical or conventional reason)
- What problem it was meant to solve
🔬 Assumption Deconstruction
For each major assumption:
| Assumption | Type | Actually true? | Evidence |
|---|---|---|---|
| "We need X to do Y" | Conventional | Maybe not | Reason |
| "This requires Z" | Physical | Yes | Because... |
| "Users expect A" | Inherited | Unvalidated | Never tested |
🧱 Fundamental Truths Identified
What do we *actually* know, independent of convention?
- Core need: [The real underlying need being served]
- Hard constraints: [What is genuinely immovable]
- Validated facts: [What has been empirically confirmed]
🔨 Rebuilt Solution
Starting from fundamentals:
- What does the solution look like without inherited assumptions?
- What changes dramatically?
- What stays the same (and why — what fundamental truth supports it)?
- What's now possible that wasn't in the old frame?
⚠️ Assumption Risks
Which surviving assumptions are highest-risk?
- If any single assumption proves wrong, what breaks?
- Which assumptions should be validated before committing?
Thinking Triggers
- *"What is this actually trying to accomplish at the most basic level?"*
- *"If we were building this today with no legacy, what would we do?"*
- *"Is this a law of nature or a law of habit?"*
- *"Who decided this was the right way, and what were their constraints?"*
- *"What would a brilliant outsider — who doesn't know our conventions — suggest?"*
- *"Are we solving the problem, or are we solving our version of the problem?"*
Analogy vs. First Principles
Most thinking operates by analogy:
*"We do it like company X does it"* / *"The industry standard is Y"* / *"That's how it's always been done"*
Analogy-based thinking is fast and usually adequate. But it inherits the constraints and mistakes of the original. When something is fundamentally broken or when you need a step-change improvement — not an incremental one — analogy thinking will never get you there.
First principles is slower but the only path to genuinely novel solutions.
Example Applications
- "Should our agent pipeline be sequential?" → Why sequential? What's the fundamental constraint? Is it ordering of dependencies, or just convention borrowed from waterfall?
- "We need a dedicated QA team" → Is QA a separate function by necessity, or because testing was historically slow and manual?
- "Our API needs versioning" → What's the actual need — backward compatibility. What's the minimum mechanism that provides that, built from scratch?
- "We need standups every day" → What's the fundamental need? Coordination. What are all the ways to achieve that, unconstrained by "meeting" as a format?