Comparing by fit
Two ways of thinking, side by side. There is no winner here — read across each row and choose the one that fits your situation.
Innovation
Understand the person, frame the real problem, build something rough, and learn from their reaction.
By 6days
Decision Making
Strip a problem back to what must be true, then rebuild — instead of copying what exists.
By 6days
When to use — Design Thinking
Use it on ill-defined problems where the need is genuinely unclear, where the people affected are not you, and where the cost of building the wrong thing is high. It is strongest early, when the framing is still open and cheap to change.
When to use — First-Principles Thinking
Use it when an industry's costs or practices have been stable for a long time without obvious justification, when you are entering a field as an outsider and lack the incumbents' assumptions, or when repeated incremental attempts have all failed and the problem may be framed wrongly.
When not to use — Design Thinking
Avoid it when the problem is well-specified and the answer is known — it is expensive ceremony for work that needs execution. It struggles with problems whose constraints are technical or regulatory rather than human. And it is the most ritualised framework in common use: workshops, sticky notes and a five-stage poster routinely produce the appearance of the method with none of the substance, because nobody left the building to observe anyone.
When not to use — First-Principles Thinking
Avoid it for routine decisions — it is slow, effortful, and analogy is right most of the time. It is also a common vehicle for arrogance: reasoning from first principles while lacking domain knowledge tends to rediscover why the convention exists, expensively. If experts cannot explain why a practice exists, that is worth investigating; if they can, listen.
Organisations solve the problem they were handed. A brief arrives already containing its solution — 'build a dashboard' — and a team spends six months building it well, only to find nobody uses it, because the actual difficulty was never a lack of a dashboard. The expensive error was committed before any work began, in accepting a framing nobody tested against a real person.
Most reasoning is analogy: we do it this way because that is how it is done, because the incumbent does it, because we did it last time. Analogy is efficient and usually right, which is exactly why it is dangerous — it carries forward constraints that were real once and quietly expired. Whole industries hold assumptions nobody has tested in decades, because testing them was never anyone's job.
Design thinking is a loop for problems where the requirement is not yet known: understand the people affected, define the problem from what you learned rather than from the brief, generate many candidate solutions before judging any, build a rough artefact, and put it in front of someone. The sequencing carries the value. Defining after observing prevents you from solving the wrong problem, and prototyping before committing makes being wrong cheap. It is not linear — findings at the test stage routinely send you back to redefine — and treating it as a five-step process to march through is the most common way to get nothing from it.
First-principles thinking decomposes a problem to the things that must be true — physics, arithmetic, contract terms, hard constraints — and reasons upward from there, deliberately ignoring how the problem is currently solved. The hard part is not the rebuilding; it is telling a real constraint from an inherited convention. 'Water boils at 100°C at sea level' is a principle. 'Enterprise software is sold through channel partners' is a convention wearing a principle's clothing. The method is expensive and usually unnecessary — its value is concentrated in the rare cases where a load-bearing assumption is simply wrong.
Watch and talk to the people who live with the problem, where they actually encounter it. Watch what they do rather than trusting what they say; the workarounds they have stopped noticing are where the real problem is visible.
Write a problem statement grounded in what you observed, not in the brief you were handed. If your definition is identical to the original brief, you have almost certainly skipped the observing.
Produce many candidate directions with evaluation explicitly suspended. The first plausible idea is a local optimum and will kill the search if allowed to. Quantity first, judgement second, deliberately separated.
Build the crudest thing that could elicit a real reaction — paper, a clickable sketch, a manual process behind a form. Fidelity is not a virtue here; it is a liability, because polish makes people admire the artefact and makes you reluctant to discard it.
An ordered process with 5 phases.
Observe the people in their situation.
Frame the real problem from what you saw.
Generate many options before judging any.
Worked example — Design Thinking
A hospital is asked to reduce missed outpatient appointments and briefs a team to build an SMS reminder system. Observation first: patients who miss appointments overwhelmingly received the letter and remembered the date. The barriers are transport, unpredictable shift work, and a booking line answered only during working hours — the hours they are at work. The problem is redefined from 'patients forget' to 'patients cannot attend or rearrange within the constraints of their lives.' Prototypes: a text-back rescheduling line, evening slots, a standby list. The reminder system, which was the entire original brief, addresses a cause that barely exists.
Worked example — First-Principles Thinking
A team is quoted £40,000 for a piece of lab equipment and treats it as fixed. Decomposed: what is it actually made of? A precision stage, a camera, a light source, a controller, an enclosure, and software. Priced as components, roughly £6,000. The remaining £34,000 is not physics — it is certification, low production volume, support, and margin, all of which are real costs but not laws. For a regulated clinical setting the £40,000 is justified and the analysis ends there. For an internal research rig that needs no certification, most of that gap is avoidable, and the team builds it for £9,000.
The approach draws on design practice and cognitive research going back to the 1960s, with roots in work on the nature of design problems by figures such as Herbert Simon and Horst Rittel. Its current business form was shaped substantially by the firm IDEO and by the Stanford d.school from the 1990s onward. The five-stage articulation is one popular formulation among several, not a canonical definition.
The idea is ancient: Aristotle described reasoning from first principles, and the method underpins mathematics and physics as disciplines. Its modern circulation in business owes much to engineering culture and to founders who have publicly credited it for cost-structure decisions. It is common intellectual heritage rather than anyone's proprietary framework.
Not specified
Put it in front of someone from the affected group and watch them struggle without helping them. Most tests send you back to define rather than forward to build, and that is the loop working rather than failing.
Write the problem so that no current approach is embedded in the wording. 'How do we make our call centre more efficient' has assumed a call centre. 'How do customers get their question answered' has not, and the two questions have very different answer sets.
Write down everything you believe about the problem, especially what feels too obvious to state. The load-bearing assumptions are always the ones nobody thought worth writing down, because obviousness is what protects them from scrutiny.
For each, ask what would happen if it were false, and demand evidence for why it holds. Laws of physics, arithmetic, and binding contracts survive. Industry practice, precedent, and 'the customer expects it' usually turn out to be conventions that someone chose, under conditions that may no longer apply.
Construct a solution using nothing but the constraints that survived. Do not check it against the existing approach yet — the comparison will pull you back toward the familiar before the new idea has finished forming.
Set the rebuilt solution against the status quo. Often the status quo wins, which is a real and useful result: you now know why it is right rather than merely inheriting it. Occasionally the gap is enormous, and that is what the whole exercise was for.
Build the crudest thing that can be wrong.
Put it in front of real people and learn.
Not specified