Your Requirements Are Dumb (and Other Gifts from the SpaceX Algorithm)

I first watched Elon Musk explain "The Algorithm" years ago, filed it under things I'll definitely apply to my work, and then promptly did the exact opposite of it for a very long time. Recently it came roaring back — SpaceX put its CFO on camera for the IPO roadshow, and there, tucked between the asteroid-mining slides and the "space is a really big market" energy, was the same five-step process. Apparently it's important enough to pitch to mom-and-pop investors. So it's probably important enough for your next PRD.

Here's the thing about the Algorithm: it's ostensibly about building rockets, but it's actually about the quiet, humiliating ways product teams waste their own time. Let's go through it. (Musk's original explanation is here — worth the four minutes.)

Step 1: Make your requirements less dumb

Musk's exact framing: "Make your requirements less dumb. Your requirements are definitely dumb." He is not being polite about it, and neither should you.

The key insight is what comes next: it doesn't matter who gave them to you, and it's particularly dangerous if a smart person gave them to you, "because you might not question them enough." This is the whole game right here. Every product org has a set of requirements nobody questions because they came from someone with a good title. The VP said users need it. The founder mentioned it in a meeting eleven months ago. Legal "flagged something." Everyone's wrong some of the time — smart people included — and the smarter the source, the less scrutiny the requirement gets, which is exactly backwards.

Then Musk drops the part every PM should tattoo somewhere visible: every requirement must come with a name, not a department. You can't ask a department why a requirement exists. You can ask a person. And that person has to agree to own it. Otherwise you end up defending a constraint that "an intern two years ago randomly came up with off the cuff" — his words — from a company that may not even exist anymore. If you've ever spent a sprint honoring a rule and nobody in the building can tell you why it's there, you've met the ghost of that intern. He haunts your backlog. Requirements-with-names is the exorcism.

Step 2: Delete the part or the process step

This is the one people nod along to and then never do.

Musk's test is beautifully specific: if you're not adding at least 10% of the deleted things back in, you're not deleting enough. Read that again. The goal isn't to delete safely — it's to delete so aggressively that you occasionally break something and have to undo it. If you never have to add anything back, you were being a coward the whole time.

The reason we don't do this in product is that "in case we need it" is the most seductive phrase in software. In-case-we-need-it a settings toggle. In-case-we-need-it an admin override. In-case-we-need-it three extra fields on the onboarding form that 2% of users touch. You can make an in-case argument for literally anything, which is exactly why the argument is worthless. SpaceX was trying to build the first fully reusable rocket — the Holy Grail of rocketry, a thing that had never existed — and the discipline that got them there was deleting stuff and refusing to hedge. Your feature is not more sacred than a reusable rocket. Delete the toggle.

Step 3: Simplify or optimize — and NOT before now

Here's where the ordering does real work. Optimization is step three, not step one, and Musk is blunt about why: "The most common error of a smart engineer is to optimize a thing that should not exist."

He blames school, and he's right. We were all trained to answer the question on the exam. You don't get to tell the professor the question is dumb — you'll get a bad grade. So we grow up with, in his words, "a mental straitjacket," reflexively optimizing whatever's put in front of us instead of asking whether it should be there at all. In product terms: the beautifully A/B-tested checkout step that shouldn't exist. The lovingly refactored service powering a feature nobody uses. The dashboard you made 40% faster that should've been deleted in step two. Polishing something that shouldn't exist is just a more sophisticated form of wasting time, and smart teams are especially good at it.

Step 4: Accelerate cycle time

Now — now — you're allowed to go faster. "You're moving too slowly, go faster. But don't go faster until you've worked on the other three things first."

This is the step every leadership team wants to jump straight to. "We need to ship faster!" Sure. But if you accelerate before you've made the requirements less dumb, deleted the dead weight, and simplified what's left, all you've built is a faster machine for producing the wrong thing. Congratulations, you're now generating waste at scale with impressive velocity. Speed is a multiplier, and multipliers work on negative numbers too.

Step 5: Automate

Last. Dead last. And this ordering is where Musk gets refreshingly, specifically self-deprecating.

He admits he has personally run the whole thing backwards multiple times — "I automated, accelerated, simplified, and then deleted." The example is perfect. On the Model 3 line, five fiberglass mats sat between the floor pan and the battery pack, and they were choking the entire production program. His first move? Try to make the robot placing them better — automating. Then speed it up — accelerating. Then optimize. Every one of these was a mistake, because he never asked the actual question: what are these mats even for?

So he asked the battery safety team. They said noise and vibration. He asked the noise-and-vibration team. They said fire safety. Each team thought the mats were the other team's requirement. Musk's description — "I felt like I was in a Dilbert cartoon" — is the most relatable thing a billionaire has ever said. They ran the test, put a microphone in a car with the mats and one without, and couldn't tell the difference. He couldn't even tell which car was which. So they deleted the mats and bypassed a $2 million robot that existed entirely to install nothing.

That's the whole Algorithm in one anecdote: a very expensive, very fast, very automated, very optimized solution to a problem that didn't exist.

The uncomfortable part

The reason this framework hits harder than the usual "move fast" poster wisdom is that Musk openly admits he screws up the order all the time. Nobody naturally runs these steps forward. Our instincts pull us toward step five — build the thing, automate the thing, make the thing fast — because that feels like progress and looks like work. Deleting a requirement doesn't demo well. "I removed a feature and asked whose idea it was" is not a slide anyone wants to present.

But that's the job. Next time a requirement lands on your desk, before you spec it, build it, or optimize it, ask two questions: Whose name is on this? and What happens if we just... don't? Worst case, you add it back — that's the 10%. Best case, you just deleted your five fiberglass mats.

Sources

• Elon Musk on The Algorithm (original)
• SpaceX IPO roadshow presentation