How Elon Musk’s 5-Step Process Applies To Software Development

in , , ,

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.

STEP 1. Make Your Requirements Less Dumb

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 come with 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.

How this relates to software development

Here are a few real-world examples of scenarios that we run into a lot with our clients during our Team Work Sessions:

  • UX Team asks “Why is this a requirement?” The client says “That’s what the business team wants.”
    The fact that product teams often do not question or challenge why a requirement is a requirement in the first place probably speaks more to a problem with the corporate culture dynamic than anything else. In other words, often times product teams are put in a position of focusing purely on delivering what they are asked to deliver — without being empowered to ask “why?”.
  • UX Team asks “Why does your current software product function this way?” The client says “That’s just how it’s always functioned.”
    This one actually happens quite a lot and it’s often the result of a product team that:

    • Can no longer “see the forest for the trees” because they’ve been so close to the product for so long
    • Has new members that don’t feel comfortable questioning things until they’ve earned their stripes.
  • UX Team asks “What drove this to become a requirement in the first place?” The clients says “Feedback from our users”. Then UX Team asks “How many users and what was their specific feedback?” The client says either “I don’t know. It’s just what we were told.” or “We had one or two users complain.”
    This also happens quite a lot and it often causes product teams to get sidetracked with enhancements or new requirements that should have a much lower priority than others in their backlog. It’s sort of like the “The squeaky wheel gets the grease” treatment.

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.

STEP 2. Try Very Hard To Delete A Part Or Process

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.”

How this relates to software development

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, the tendency is for product teams to add more and more features to their product 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.

3. Simplify or Optimize

In this clip, Musk talks about how he purposely makes this his third step so that it helps 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?

How this relates to software development

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.

4. Accelerate Cycle Time — or, “Go faster!”

In this clip, Musk says “Go faster — but don’t go faster until you’ve worked on the other 3 (steps) first.”

How this relates to software development

In Agile Development, “Velocity” is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint. So to increase Velocity, it would help if you made your requirements “less dumb”, deleted features or processes, and simplified or optimized your product. Once you’ve done these, you can be in a much better position to “Go faster!”

5. Automate

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’s 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 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 and they found no difference whatsoever. Needless to say, the mats were removed.

How this relates to software development

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.

The Importance of a Minimum Viable Product (MVP)

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.

How this relates to software development

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 and 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, and MVP is critical to the success of any product launch.

Presenting Evidence-Based Design Recommendations

in , ,

Much the way a prosecutor presents evidence to help a jury reach a verdict, we as designers must present the evidence to support our design recommendations. If you take the prosecutor comparison a step further, we also know that a prosecutor and a defense attorney can both have the exact same evidence to work with but it is the one that is better at presenting how that evidence should convince the jury to reach one verdict over another that will win the case. This is also true for designers. You can have ample evidence to support your design but if you don’t present that evidence in a clear, easy-to-understand manner, you may not win your case.

Start with the evidence

If everything in your design recommendation is built on top of a solid foundation of indisputable evidence, you stand a good chance of creating a convincing rationale for your design. If you start with an opinion, you are doomed because everything that follows can fall like a house of cards. By leading with the evidence you also build immediate confidence in your thought process, which adds credibility to everything you present next.

When we were hired to redesign an insurance quoting system, we were told the primary goal of the redesign was to “dramatically increase the number of small business quote submission”. To achieve this goal we created the following hypothesis:

“Based on our research, we now know that the MAJORITY of users value ‘Speed of Quote’ over ‘Price’ and ‘Coverage Options’. Therefore, to increase the volume of submitted quotes, the UX should be OPTIMIZED for the MAJORITY rather than degraded or compromised for both the majority and the minority.”

Then, throughout the project we carefully scrutinized every macro and micro design decision — from the overall user flow to every form field label name. One example of that related to selecting or editing building coverage options. Some of the initial design ideas being considered included accordions, multi-column layouts and drag and drop features. But, before we went too far down the design road, we first asked the following question: “Of the total small business policies written today, how many have just 1 building? How many have 2? How many have 3?, etc…”.

The Evidence:

Total Policies1 Building2 Buildings3 Buildings4 Buildings5+ Buildings
19,37217,5441,254319131124

Based on this data, the indisputable evidence shows that the mass-majority of small business policies have just 1 building.

Use the evidence to drive decisions

Now that we have the above evidence, we need to show how it should be used to drive our design decisions. This part is critical. If you don’t present the evidence in a way that leads to an obvious conclusion, you either don’t have good evidence or you’re not presenting it properly. In this case, we have great evidence but even great evidence can be met by some resistance because the evidence may lead to unwanted outcomes, such as additional development effort. In fact, often times during a software design project, the product team members will get hung up on trying to come up with design solutions that can accommodate both the mass majority and the extreme corner cases. The fact is, a “one-size-fits-all” UX is rarely the best solution for all your users. It may be the easiest to develop — but it will almost certainly degrade your UX for some of your users and you never want to degrade the UX for the majority.

So based on the number of buildings per policy, we recommended the following UX:

  1. For 90% of the users with one building, we will simply display rows for each coverage option that can be applied to the one building.
  2. For 10% of users with two or more buildings, we will display a multi-column layout so that coverage options can be applied across buildings one at a time or in bulk across multiple buildings in one action.

In other words, we ended up coming up with a UX solution that is optimized for both the majority and the minority. For the majority of users with just one building, we displayed a clean, easy-to-use list of coverage options to select from without any unnecessary clutter. For the minority of users with multiple buildings, we displayed a different layout that allows them to bulk apply coverage options across multiple buildings in one action since most users with multiple buildings select the same coverage options across all or most buildings.

The Bottom Line

Without the compelling evidence to help drive our design decisions, we almost certainly would have been pressured to create a one-size-fits-all UX with columns for each building — even though it would have completely contradicted our stated goal. Since we learned that 90% of the quotes would only have one building, it made no sense to display the one building in a column layout — but it made a lot of sense to use a column layout for more than one building.  A win-win for all users.