During a June 2021 a tour of Starbase, by space journalist Everyday Astronaut, Elon Musk talked about previously private methods that his companies (Tesla, SpaceX, Neuralink and The Boring Company) use to make better products. Elon described the method he uses to effectively build software, cars, rockets, solar arrays, or anything. His steps are (1) make the requirement less dumb, (2) try to delete the requirement, (3) optimize, (4) accelerate, and (5) automate.
You won’t find this design thinking in any business school textbook or case. It’s one of methods that Elon used to become the richest human in history. He admits that he doesn’t always live up to his own advice, and provided counter-examples he’s learned from, in building the Model 3 electric car, Falcon 9 rocket and Starship.
1. Make the requirement less dumb
“The requirements are definitely dumb; it does not matter who gave them to you. It’s particularly dangerous when they come from an intelligent person, as you may not question them enough. Everyone’s wrong. No matter who you are, everyone is wrong some of the time. All designs are wrong, it’s just a matter of how wrong.”
When he says “requirement” he’s speaking in the language of R&D. In architecture, requirements are called blueprints, in IKEA furniture they’re called assembly instructions. In medicine they’re called operating procedures. In engineering they’re called specifications. For pilots of airplanes they’re called checklists. Every technical field has a term-of-art to describe their requirement documents. Elon says regardless how honed they seem; there’s room for improvement, especially if they’re approved by an authoritative body or if they’ve stood the test of time. Durability in the past doesn’t mean a requirement is fit for the present.
Elon encourages us to return to first principles to explain every requirement, rather than assuming they’re right. Everyone is wrong some of the time.
He advises that a person be assigned to each requirement, not a department, in order to defend the existence of the requirement. Lest the Safety Department be allowed to enforce a requirement that’s no longer considered the ideal safety-inducing feature.
Don’t spend time finding the right answer to the wrong question.
2. Try to delete the requirement
“If parts are not being added back into the design at least 10% of the time, [it means that] not enough parts are being deleted. The bias tends to be very strongly toward ‘let’s add this part or process step in case we need it.”
Elon says, convergent thinking teaches us to optimize components that shouldn’t exist. You can make “just in case” arguments for most things, but that doesn’t mean they’re necessary. In order for SpaceX to build a rocket that’s efficient, it must run on tight margins, and not hedge every bet.
Elon recommends that rather than adding a requirement just-in-case, consider keeping a backlog and adding that step later.
Elon clarifies that this mentality works during prototyping, and will evolve to zero-faults once humans fly aboard Starship.
3. Optimize and simplify
“The reason this is the third step and not the first step is because the most common error of a smart engineer is to optimize something that should simply not exist…You have to ask the question [should we build this at all.] So everyone’s basically, without knowing it, they got like a mental straight jacket on. They’ll work on optimizing the thing that simply should not exist.”
Elon uses Falcon 1 as an example of when SpaceX optimized a system that shouldn’t have existed. They optimized a rocket using NTO/MMH, even though the propellant is toxic and expensive and therefore shouldn’t have been considered at all. This requirement shouldn’t have made it to step 3, it should have been deleted in stage 2.
4. Accelerate cycle time
“You’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first…Because if you are digging your grave, you don’t want to dig faster. You want to stop digging your grave.”
5. Automate the requirement
“Then the final step is: automate. Now, I have personally made the mistake of going backward on all five steps multiple times. On the [Tesla] Model 3, I automated, accelerated, simplified and then deleted.”
Seeking to learn and explain using past mistakes, Elon explains how he inadvertently did the reverse of his advice on Model 3. That is, rather than counting up the steps, he started by automating a requirement, and ended by deleting the requirement entirely.
While working on a fiberglass mat atop the battery pack. He automated the fiberglass mat requirement using a $2 million installation robot (step 5–automate). Then he accelerated the mat requirement by moving the robot faster with a shorter movement path (step 4-accelerate). Then he removed the reversing step in bolt tightening, and got rid of the mat glue (step 3-optimize). Then finally he asked what the fiberglass mats were for. He was told by the battery deparment they’re for fire safety. The Safety Department said they’re not for safety, but rather for noise dampening. So Elon sat in a Model 3 for an A/B test, and couldn’t hear the difference. So after automating (step 5) the fiberglass mat installation, accelerating (step 4) that automation, and optimizing (step 3) installation. Finally the Tesla team deleted (step 2) the requirement for the fiberglass mats entirely by removing a $2 million fiberglass mat installation robot for the Model 3. Had they begun by questioning (step 1) the requirement they might have saved effort, time and expense.
Elon Musk’s 5-steps to build and write requirements better are a valuable lesson for any builder interested in design thinking, product management, and engineering