Elon Musk's 5 step process for making things in a better way

This video is an extract for educational purposes from a great interview with Elon Musk by Everyday Astronaut. Watching the entire multi-hour tour of SpaceX's Starbase is recommended. You can find the first episode on Everyday Astronaut's channel here:

This video is an extract for product managers, service designers and others people who make hardware, software or both. It might be good general life advice too!

The 5 step process for handling requirements when making things, according to a man who gets a lot of things done and learns from his mistakes (including the Cybertruck window smash, which he's wearing an image of on his t-shirt during the interview).

1. Make your requirements less dumb
- Your requirements are definitely dumb
- Its particularly dangerous if a smart person gave them to you as you might not question them enough

2. Delete the part or process
- If you're not adding back then you're not deleting enough
- Don't add requirements just in case, don't hedge your bets

3. Simplify/Optimise
- Don't optimise if it shouldn't exist

4. Accelerate cycle times
- But don't go faster if you haven't worked on the other 3 things first...
- If you're digging your grave don't dig your grave faster

5. Automate
- Don't reverse these 5 steps

[caviersim]

Love the chaos honestly, feels like a real convo with a friend in the middle of work instead of a cold stale interview on tv

[elkernel]

1:30 “the most common error of a smart engineer is to optimize the thing that should not exist.”

[freedomu]

1. Make your requirements less dumb
2. Delete as much of the process as possible (test the borders/trim the fat to get rid of unnecessary parts)
3. Simplify/optimize
4. Accelerate cycletime (go faster)
5. Automate

[WingofTech]

Thank you for including the paraphrased quote at the end!! ❤

[AjGalloway]

Thank you! Appreciate you transcribing

[tistougames]

I listen to this every morning, it's a bit silly since it becomes gospel to me. Anyway, the first step, to question the requirements, is, as he says, harder if a smart person made the requirements. I want to add, that if you, yourself, aren't smart enough, when asking this smart person, it's not possible to question the requirements enough. It's impossible unless you educate yourself to understand on a deeper level. Imagine getting the requirement from a smart person, that you have to use a cylindrical chair when making a time machine. How could you question this enough? You'd have do question in a manner so deep, that the smart person has to educate you on how it works. Otherwise, you will have requirements that you don't know if they should be there, you just trust the smart person and build on top of it.

[tomasstesti]

Golden nuggets here, thx for this :-)

[Vlad-vkmm]

Awesome, great advice, was looking for someone to make a compilation and found it. Thanks. Would be cool too also delete the background noise with some of that AI, but I'm asking too much I guess ha.

[jpxgs]

1 make your requirements less dumb
2 delete as much of the process as possible
3 simplify/optimize
4 accelerate cycletime (go faster)
5 automate

[Coach_Dustin_C]

Whomever interviewed him on this day, when he was wearing this exact shirt. Asked the best questions bar none.

[mikemike-ympb]

All starts ups need to watch this video. Primary focus on cycle times is simply foolish if core DESIGN and PROCESS issues are ignored!!!

[PotentialTechniques]

Are they testing the killbots in the background? Those huge gunshot sounds

[markmalonson]

He really is a beautiful person this is great.

[coloradowestaerialarts]

Then how does someone get a job in engineering if schools are not teaching proper engineering curriculum?

[feisal]

Ulipataa ansr Orr Badi nilikuonesha kituu muhimusana itamsaidiya kufanya transport ikuwe chip

[aman-tigray]

You missed about adding at least 10% back in you will bleed up…

[karabontseki]

What does "Make your requirements less dumb" mean?

[paulmetzger]

I wrote a scientific paper about that :)

[ExaltedDuck]

The first two steps should be swapped. Delete anything extraneous, then with what remains, evaluate whether it's sensible. Then only once you know that it's necessary and has sensible requirements, continue forward with optimization. And never automate what hasn't been optimized. Automation is just faster, not better. If you're doing something poorly, automating only stacks up more bad results in less time.