Question the Requirement
Delete the requirement before you optimise the part
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 7
- Confidence
- 90%
The method inverts the usual order of engineering work. Before anything is made faster or cheaper, you interrogate why the requirement exists at all. Requirements must be traced to a person, never a department: departments cannot be questioned, individuals can. You go back to that person and ask whether the thing is genuinely needed. Requirements that fail the question get deleted, which leaves a smaller set. Then you strip parts until only what the surviving requirements demand remains. Optimisation comes after that: how to make each remaining part efficiently and put it in the right place. Cost efficiency and economies of scale come last. Holding the sequence matters because each earlier step shrinks the surface area of the later ones, an optimised part that should not exist is pure waste. The whole thing depends on one person, usually the founder, who can hold the entire problem in their head and see what removing part A does to parts B through E.
Origin
Naval describes it as one of Musk's great driving principles, citing the version documented in Eric Jorgensson's book of Elon in his own words.
Core principles
- 01Optimisation is one of the last steps, not the first
- 02Every requirement traces back to a named individual, never to a department
- 03The cheapest part is the one that no longer exists
- 04Somebody has to hold the whole product in their head
- 05Teams inherit requirements and defend them long after the reason has gone
How to run it
- 1
Stop optimising
Freeze the effort to speed up or cheapen the current design. Optimisation is among the last things you do, not the first.
Watch out Partial wins from optimisation are the trap; they feel like progress and hide the obsolete requirement.
- 2
Track the requirement to a person
Find not which department produced the requirement but which individual said this is what I want. Requirements have to come from a name.
Pro tip If nobody will own it, that is already your answer.
Watch out Departments defend requirements reflexively; individuals will usually tell you the truth.
- 3
Ask whether it is really needed
Go back to that individual and ask directly whether they still need this. Cross-check the stated reason with the team that supposedly owns it.
Pro tip Ask two teams the same question; contradictory answers are the strongest signal the requirement is dead.
- 4
Eliminate the requirement
Delete the requirements that fail the question, leaving a smaller number that are absolutely necessary.
Watch out Do not soften a dead requirement into a nice-to-have; it will grow parts back.
- 5
Delete parts
With fewer requirements, remove as many parts as you can while still fulfilling what is left.
Pro tip Compare iterations side by side; a mature design has almost no parts left to fool around with.
- 6
Now optimise
Only at this point work out how to manufacture each remaining part and fit it in the right place most efficiently.
- 7
Then chase cost and scale
Finally address cost efficiencies and economies of scale, once the part set is settled.
Pro tip Keep one person who understands why every component is where it is throughout all seven steps.
Watch out If nobody holds the whole product in their head, deletions in one place quietly break requirements elsewhere.
In the wild
A line producing fiberglass mats glued to the top of Tesla battery packs was frustratingly slow. Elon put a sleeping bag down at the line and the team optimised the gluing robot, improving it a bit but not enough. He then asked why the requirement existed at all. The battery team said the mats were there for noise reduction, so he went to the noise and vibration team, who said there was no noise issue; the mats were for heat, because the battery catches fire. Back at the battery team, the fire risk turned out to be obsolete. Each group had been doing what it was trained to do. They tested for safety, put microphones on it, and eliminated the part.
→ The bottleneck disappeared because the part was removed, after optimisation of the same part had already failed to fix it.
Naval points at the successive versions of the SpaceX Raptor engine as a visible record of this process. The earlier versions have a million different parts, each with a thickness, a width and a material you could still fool around with. The most recent version barely has any parts left to change. What looks like a design converging is really the accumulated output of repeatedly questioning requirements and then deleting the parts those dead requirements were holding in place.
→ A design with almost nothing left to remove, arrived at by subtraction rather than refinement.
Common mistakes
Optimising a part that should not exist
Speeding up the process around an obsolete requirement produces a marginal win and locks the waste in permanently.
Accepting a department as the source
A requirement attributed to a team cannot be interrogated. Only a named individual can be asked whether they still need it.
Nobody holds the whole system
Without one person who understands why each component is there, deleting part A silently breaks the requirements of parts B through E.
Is it for you?
Best for
Product, hardware and process teams stuck on a stubborn bottleneck they have already tried to speed up.
Not ideal for
Regulated or safety-critical requirements that cannot be traced to an individual and deleted at will.
From the transcript
“the first thing you do is you question the requirements. You're like why does the requirement even exist?”
“The requirement has to come from an individual. Who's the individual who said this is what I want?”
“Now you have parts and you try to get rid of as many parts as you can to fulfill the requirements that are absolutely necessary.”
From the episode
In the Arena