First Principles: Break a Problem Down to What Must Be True
First Principles thinking helps you take a problem apart, keep only the facts that cannot be removed, and rebuild a solution instead of copying how the thing is usually done.
Framework Card
- Name:
- First Principles
- Goal:
- Strip a problem down to facts that cannot be removed, then rebuild a solution without copying inherited analogy.
- Flow:
- Decompose → Validate first truths → Rebuild
- Best For:
- Breaking how it is usually done; Deep redesign when incremental change is not enough; Checking what is necessary versus inherited
Why it matters
Most redesigns start from a neighbor. A competitor’s onboarding. Last year’s process. The industry’s bill of materials. That is reasoning by analogy: the similar thing becomes the template.
Analogy is fast. It also hides constraints that were never required for your outcome. Teams then spend months optimizing a copy of a copy, and the leftover parts still look “necessary” because nobody tested them.
That matters when incremental change is not enough: a cost that will not move, a flow users abandon, a process that exists because a vendor once required it. Without a necessity test, arguments stay at the level of taste and precedent.
First Principles is a way to interrupt the copy: name the inherited solution, decompose it, keep what must be true, rebuild from those facts. It does not guarantee a famous product. It makes inherited constraints visible.
What it is
First Principles thinking is a method for reasoning from basic truths instead of from similarity.
Aristotle described a first principle as a fundamental proposition or assumption in a system that cannot be omitted, deleted, or violated. In public conversation, Elon Musk has described working from the essence of a problem rather than from comparison, including asking whether a given rocket or satellite part is actually required to reach orbit. Those comments popularized the method. They are not extra laws of the method.
The working structure has three stages:
| Stage | Question it answers |
|---|---|
| Decompose | What parts make up the current way? |
| Validate first truths | Which of those parts cannot be removed for the outcome we actually need? |
| Rebuild | If we start from only those remaining facts, what design follows? |
Everyday prompts from production teaching:
- Why is it like this?
- Does it have to be this way?
- Can it be done differently?
The unit of analysis is one problem or design, not a company personality and not a team-development stage.
How it works
A useful first-principles pass is a rebuild, not a mood of questioning.
1. Name the inherited solution
State the analogical template in one sentence: “We do it this way because X does it this way,” or “the industry stack is A then B then C.” If you skip this, later “truths” will smuggle the template back in.
2. Decompose into parts
Break the current design or process into pieces you can test: steps, components, rules, costs, roles. Stay with the user’s case. Do not import a generic industry encyclopedia.
3. Validate first truths
For each part, ask whether it is required for the outcome you actually need, or only inherited. Keep propositions that cannot be omitted. Drop or relabel the rest as assumptions, habits, or constraints that might be changed.
The three everyday questions help here, but they are prompts, not a ritual count.
4. Rebuild, then contrast
Assemble a solution from the remaining facts. Then say how it differs from the analogical option (what you would stop copying). That contrast is the point. A critique with no rebuild is unfinished. A rebuild that reintroduces the old template is still analogy.
How it compares
When another lens fits better, or when you need a complementary view, these approaches do different jobs. They are not interchangeable labels for the same question.
Related thinking lenses
| Framework | What it helps you see | How it differs from First Principles |
|---|---|---|
| Analogical / best-practice copy | A solution that already exists in a similar case | Starts from similarity; First Principles interrupts that copy when similarity is the blocker |
| Jobs-to-be-Done | The job a customer is trying to get done | Frames demand; does not decompose a design into necessary parts |
| Brainstorming | A wider set of options before judging | Expands volume; does not test which constraints cannot be removed |
Related frameworks on MyFramework
| Framework | What it helps you see | How it differs from First Principles |
|---|---|---|
| 5 Whys | A deeper cause by asking why in a chain | Diagnoses why a failure happened; does not rebuild a design from necessary facts |
First Principles is the lens for necessity and rebuild. Other methods help when the question is mainly root cause, customer job, idea volume, or copying a practice that is already a good fit.
When to Use This Framework
- Assumption breaking: The current solution feels mandatory because “that is how it is done,” and you need to test which parts are customary.
- Deep redesign: Small iteration on the existing template will not change the outcome you care about (cost, time, user effort, physical limits).
- Necessity checks: You need to know what truly cannot be removed or altered before you add another feature, vendor, or step.
Example
A concrete example makes the structure easier to reuse when you are under uncertainty.
Example: a SaaS onboarding wizard copied from a competitor
A product team inherits a 12-step wizard because “serious B2B tools look like this.” Completion is poor. The analogical claim is that a long wizard is required to look credible.
A first-principles pass might look like this in spirit:
Inherited way: Multi-step setup before the user can do anything useful.
Decompose: Account fields, team invites, billing, sample-data import, permission matrix, a tour, empty-state configuration.
Validate: For “user reaches first successful project,” what must be true is: the user can see an example of the job, and can complete one action that produces a real result. Billing, invites, and a full permission matrix are not required for that outcome.
Rebuild: Start in a preloaded project, one action, then ask for billing and invites after value. The contrast is not “onboarding is bad.” It is that credibility theater was treated as a first truth.
Implication: The team can now argue about a necessity test instead of about taste. First Principles did not design every screen. It showed which steps were customary.
Example: a hardware cost stack that will not move
An operations lead is told the unit cost cannot fall because “this is what the category costs.” The stack includes a supplier’s full assembly, a packaging format copied from a larger brand, and two inspections that were added after a one-off incident.
Decompose: Materials, energy, labor, assembly location, packaging, inspection.
Validate: Physics and materials still bind. The full assembly location and the two extra inspections are inherited. Packaging format is brand analogy.
Rebuild: Keep the material and energy truths; test a simpler assembly path and a packaging spec tied to protection, not to looking like the larger brand.
Implication: The close is a rebuild option plus labeled assumptions (what was not measured). No invented unit-cost percentages.
Takeaway
What First Principles can help with
- Separating necessary facts from inherited analogy
- Making a rebuild possible when copying the neighbor has stalled
- Checking what cannot be removed before adding more process
- Contrasting a rebuilt option with the current template
What First Principles cannot replace
- Root-cause depth on a known failure: A why-chain to the cause of an incident is 5 Whys. First Principles tests necessity in a design; it does not replace incident diagnosis.
- Customer-job framing: What job a user hires a product to do is Jobs-to-be-Done. You may use a job as the outcome you rebuild toward. That does not make First Principles a job map.
- Option volume: Generating many ideas before judging is Brainstorming. First Principles reduces, then rebuilds; it is not a diverging session.
- Situational completeness: Who, What, When, Where, Why, How is 5W1H. You still need facts. This method does not invent them.
- A guaranteed disruptive outcome: Reasoning from truths can still produce a modest, correct design. It does not purchase fame.
Honest scope: First Principles structures a necessity test. Thin evidence still produces a thin rebuild. Analogy remains useful when the similar case is actually similar.
Frequently asked questions
It is for testing what must be true. You decompose the current way, keep facts that cannot be removed for the outcome you need, and rebuild from those facts instead of copying a similar solution.
No. 5 Whys drills a known problem by asking why until a cause is specific enough to act on. First Principles asks which parts of a design are necessary, then rebuilds. Both use why. They are not the same job.
No. Analogy is a reasonable move when the similar case is actually similar and speed matters. Use First Principles when inherited practice is the thing blocking a design you cannot iterate into.
A named inherited solution, a short list of parts, which parts survived as first truths, a rebuilt option, and a contrast with the analogical path. If the output is only a motivational critique of “how everyone thinks,” the method was not used.
No. The method is the necessity test and the rebuild. Public examples (including asking whether a component is required to reach orbit) illustrate the habit of questioning inherited parts. They are not a requirement to cite a celebrity.