In a fantastic, super geeked-out interview (courtesy of the Everyday Astronaut), Elon Musk breaks down the 5-Step Process he’s implemented to develop everything from Tesla electric cars to Space X rockets. One of the great things about Elon’s explanation of each step is that he speaks in a very blunt manner and uses examples of the mistakes he and his teams have made that drove him to implement these steps. As he explains each step, it occurred to us how these exact same steps can and should be applied to developing software products.
In this clip, Musk says “The requirements you were given are definitely dumb — and it’s particularly dangerous if a smart person gave you the requirements because you might not question them.” Basically, he encourages everyone to assume that there are things wrong with the requirements they’ve received so that they feel much more free to ask questions and make them better (or, less dumb).
In addition, Musk requires all requirements to have a person’s name attached to them—not just a department name. This way, a person takes responsibility for the requirement, and everyone knows who to go to with questions.
Here are a few real-world examples of scenarios that we run into a lot with our clients during our Team Work Sessions:
Ideally, if product teams followed Elon’s “Step 1” advice, they would attach a name to every requirement and create a culture whereby everyone felt not only empowered but expected to ask questions about the requirements they were given before they spend tons of time designing and developing them.
In this clip, Musk says “The bias tends to be “let’s add this part or process ‘in case’ we need it” – but you can make ‘in case’ arguments for almost everything.”
In art school, they teach “When everything is important, nothing is important”. In UX design, when you make the visual weight of too many things on a given screen the same, you create a visual hierarchy that does not inform the user about what is important vs less important. Therefore, whenever you add something you need to always consider whether it is worth degrading the visual weight of other existing things or if you should remove existing things to make room for the new thing.
This also holds true for adding functions and features to a software product. As Musk explains, product teams tend to add more and more features when they should be equally considering what they can remove. After all, if the end goal is to make a better product, but the bells and whistles you want to add make your product more difficult to use, are they really worth adding?
As this relates to a “Process“, a few years ago we were hired to redesign an existing product, but the first priority was to get the live product working. Soon after we engaged with our client, we fixed the existing code and were ready to deploy it – but we couldn’t because the client’s development team was still working out the details of their new Continuous Integration (CI) scheme and how our team was going to get integrated with it. We suggested that, for this particular release, we simply push the updated code files to production manually without CI in place. Then, we will shift our focus to the redesign effort while the client development team takes their time to implement a proper CI scheme for us to use. Processes can be good, but when teams get so programmed to follow them, it can prevent teams from considering simple, logical solutions.
In this clip, Musk talks about how he purposely makes this his third step to help prevent teams from “optimizing a thing that shouldn’t exist.” In other words, it’s great that you were able to optimize the performance of that new feature—but did you consider whether it was needed in the first place?
This one speaks directly to the creation of a good user experience. When we design a software product, we test the usability of our designs before it is developed. When we deploy the tested and refined design into production, we then monitor how it is being used and even A/B test different designs to further optimize it. Sometimes our tests reveal what we call a “design thorn”, which is an element in our design that we are struggling to optimize, but it continues to cause problems for the users. In many cases, the best way to handle a design thorn is to simply remove it.
This also applies to application and infrastructure optimizations, which can speed the performance of a product and help keep it more stable. A product that performs quickly, is error-free, and is always available, is one that is far more likely to create a great user experience.
In this clip, Musk says “Go faster — but don’t go faster until you’ve worked on the other 3 (steps) first.”
In this clip, Musk talks about the importance of never starting with automation first and going through the Steps in reverse. This is our favorite video because Musk tells a great story where he made this exact mistake when they were struggling with a fiberglass mat that was mounted to the top of the Tesla battery. The installation of this mat was “choking the whole production line”. So, he and his team spent a lot of time working on ways to optimize the automation (robots) until one day, Musk finally asked the Battery Safety Team, “What the hell are these mats even for?”. They told him they were for “noise and vibration”. So he went to the Noise and Vibration Team, and they said they were for “fire safety”. So, they placed microphones and sensors inside 2 different cars and tested the noise and vibration with the mats in, and with the mats out. They found no difference whatsoever. Needless to say, the mats were removed.
This one can relate to everything from a simple ticketing system to an elaborate e-commerce website. Both require people, processes and technology to be in place before any true automation can be implemented. Much the way the robots on the Tesla assembly line were not implemented until they were designed, tested, and optimized for each step of the assembly line, you should not automate anything until you can support that automation.
In one software product we made for a client, they wanted a Task Management feature that auto-generated tasks for people based on specific triggers within the system. For example, “When Team B enters X data, generate a task for Team B”. The problem was the client didn’t have the teams to support all the auto-generated tasks — so tons of tasks were getting generated and left open in the system, and the users eventually just ignored the whole Task Management feature.
Even though this one isn’t a ‘Step,’ it’s a great clip where Musk talks about how the first few Starship rockets all blew up for reasons that were not on their “Risk List.” In other words, the first Starship rockets they launched helped them uncover flaws that no one on their teams expected, which is one of the main points of launching an MVP first. You simply do not know what you do not know.
Too many software product teams have a hard time whittling down the backlog of their product requirements to something that could be termed a Minimum Viable Product. We often hear excuses like “It’s really not a ‘Viable’ product without all its features.”, which is usually nonsense. More often than not, a product can be broken down into a logical set of releases that grow from an MVP to an official “1.0” full release. Whether you release only one set of features to a small sample of user personas or you release only the core features of the product that may still require manual work to be done on the back end, MVP is critical to the success of any product launch.
