“When time pressure starts, the art of development is to stop and be willing to work with 80% so that you still have the best outcome in the end”

During our first Launchpad we interviewed Armin Müller about his past experiences and his role during the development of the ESP system at Daimler. Feel free to watch the video or read the full interview below!

Armin, you have gained a great deal of experience in your roles at Daimler, ZF, and Porsche. Today, we wanted to talk with you about the introduction of the ESP system—the Electronic Stability Programme that prevents cars from skidding.

You were Head of Development at Daimler at the time when the ESP system was developed in collaboration with Bosch. Can you share some insights about your experience back then? How quickly did you develop the whole thing and what were some of the challenges you faced during development?

The first hurdle was setting up the design innovation project between two large companies. We had to decide who had the specific skills and how the project would be divided.

The first big phase was to get the ESP system from the research phase into a series product (this was between 1992-1995). Bosch had prepared a solution that was partly ready, but some essential features were missing. Mercedes had another solution in pre-development that was very pragmatic, but it was not extensive enough. In the end, a fusion of both was the right thing, so we merged together the algorithms that Bosch developed for ABS with the Mercedes driving safety system (called FSI at the time).

The timeline was also one of our early challenges. Our development timeline was shortened from 5 years to 33 months. Compared to ABS/ASR, the ESP was developed in half the time, with a third of the people, and a factor of 6 in complexity (if you only take the amount of software code). 

We were creating a completely new system that automatically brakes in the event of an error. This didn’t exist before. The ASR did some of this, but only for the rear wheels, because the front wheels did not brake. With ESP, all 4 wheels would be able to brake. This also brought in a new dimension of security. 

We were a well-functioning team. We deliberately worked with very few, but very good people. And speed was the key. But the product had to be flawless. For that we had a clear process—define, deliver, check, improve, redefine. We went through this twice. 

The difficulty with the ESP system was that these phases could not be run in a sequence, they were all run in parallel because of the schedule and our coordination with the Bosch team. The whole system was so modular that if, for instance, the yaw rate sensor (a completely new development) was still in the last phase, but control units and other parts were already further ahead, everything could be tested together.

A year before the start of series production, we didn’t do anything except eliminate mistakes and work on those issues. In the end, this was the right thing to do so that we could maintain the quality. 

When time pressure starts, the art of development is to stop and be willing to work with 80% so that you still have the best outcome in the end. Of course, this also requires a bit of tolerance and alignment from everyone—what do you need to add, and what can you leave out? This was an excellent exercise with the ESP system and it worked very well. We had excellent operating figures and the first system went into series production almost flawlessly after 33 months. That was really something.

Amazing, Armin. Let’s go deeper into this topic 80%. It sounds so simple—the Pareto principle that roughly 80% of consequences come from 20% of the causes. But to what extent did you really go about it with products where safety is so critical?

In the end, there will still be some functionalities that can be developed further or improved. For example, driving comfort in certain types of snow, or calmer braking behavior when you have rough surfaces. But these have nothing to do with final performance and safety.

These last improvements are still so important to a specialist, but we really had to stress to the team that when we said we would stop developing, nothing more would be done. There was massive resistance because our specialists knew that they could still improve a lot, but we stopped anyway. We simply decided that safety, quality, and robustness were the most important. In the end, it turned out that the functionality was always good enough for the average user anyway.

At the end of the day, we had to start making compromises around what would really play a significant role in our success in the market. In terms of quality and safety, that had to be 100%. But other features, where it’s about driving comfort or improving noise, you make compromises so that you can use the resources available to bring safety and quality forward.

We all know of Tesla from the US. Daimler was an investor in Tesla, but then dropped out, perhaps out of fear that the products had been developed too quickly and were not safe. How do you see this in relation to the development of the ESP system? Is product development becoming more and more agile?

The question is always at what point do you make compromises, and at what point do you not. Concerning battery technology and computer technology (or board network technology), Tesla has broken new ground. This is where they invested their efforts. Maybe the stiffness of the body is not the dominant feature for their marketing and sales success, so it’s not where they invested.

In the end, you always have to weigh what your product is and what it represents. If Tesla were to build the best car body in the world, no one would care. But when they create great computer technology and an electric drive, then that’s super interesting.

Tesla chose not to go the traditional way. They saved on traditional features and invested in new features. Every start-up does this, by the way. You can’t go the traditional way, because the others are way too far ahead and are too good. So now you have to take a different view and push that forward. If it’s good and your product is successful on the market, then you’ve defined something new.

That’s right, Armin, you’re bringing up an important topic. In order to develop something new, you have to go new ways and maybe develop the product in a more agile way.

You touched on another point. In 1997, the A-Class flipped during the so-called ‘moose test’ in Sweden. Because of this, the ESP system was introduced very quickly in the A-Class and thus entered the market fast. It took ABS 20 years, but the ESP  system was available in all vehicle classes within just a few years. So the product was not only developed very quickly, but it was also launched on the market quickly.

Regardless of effort, you also need to have luck in the end. Thank goodness it worked and thank goodness we had already started development. We had a version completely set up to fit in the A-Class, so the system was available. Otherwise it would not have been available at all.

We worked extremely well with the task force to bring it into the A-Class. Hubert and his team with Mr. Brunke, they did a great job, reacted quickly, and took the chance. You also need this kind of management that seizes opportunities, because many don’t.

When the car flipped, I was with my family in Grindelwald. I got a newspaper saying that the A-class had flipped and the ESP system should be built into the A-class. I invited everyone to a bottle of wine that day. I was happy because two years earlier I had reported to management that the ESP system would be built in all Mercedes vehicles by the year 2000. This was met with roaring laughter. They thought I was a crazy young guy. With the A-Class incident, it was absolutely clear that we would win the race.

Another thing that was interesting—thanks to the quick introduction, we were able to statistically prove the effectiveness of the system. With ABS it was extremely difficult to prove, because there were always many different cars on the market, so you could not correctly identify the features and functionality from accidents. This was not the case with the ESP. Due to the rapid change, there were pre-cars and after-cars, and there were different studies to prove the effectiveness in accidents. For example, fatal accidents with a vehicle skidding and turning into oncoming traffic or skidding off the road and hitting a tree, simply stopped. So in this respect, it was also a gift for the security of the product that it moved so quickly.

There are statistics that in Germany and Europe alone, tens of thousands of lives have been saved by the ESP. So Armin, thank you very much for that. It is also impressive to see that products can be developed so quickly. For instance, we just saw the development of vaccines at Biontech and CureVac. 

Now let’s jump to later in your career when you were at ZF and then also at Porsche. Can you compare the two companies (Diamler and Porsche) for us? What was the philosophy behind product development? Were they comparable, were they different?

ZF was extremely distributed around the world with many plants and many different types of businesses. This was completely different from Porsche, a sports car manufacturer with a clear identity, based in Weissach and Zuffenhausen. Porsche was focused on precision in how the product was developed and was also very customer-centric.

One of my first goals was to understand the data around all of our features so we could maintain specific KPIs. Right from the start, we had a targeted system for developing the cars. Our motto was: how do I make a difference with this vehicle? It’s a similar vehicle to an Audi or Daimler, but how do we differentiate ourselves? Why is the car better? If the data is the same, what can I do to make it better?

For example, when the 911 Turbo came onto the market, it was better than the vehicles that had been developed up until then. When we were building the first generation, we were already thinking ahead about optimizing the technology for the second generation. In the management meeting with Wiedeking, there were disputes about where money was being invested and how we could make lightweight vehicles. We could make lightweight improvements on the fenders or we could make lightweight improvements in the center. The center is more expensive, but when you improve the center, you can still fix the fenders and gain weight improvements again. So we had massive discussions about this.

We finally agreed on a high-performance package that didn’t fully play out from the start. We got the first generation to 80%, and the remaining 20% of the optimizations were brought into the second generation. The key thing was that the management at Porsche was extremely product-oriented and had a clear direction and a team behind every measure. That was great.

You mentioned an important issue here. The management was product-driven. We see that a lot with our customers too. Some are procurement-driven, some are product-driven, what is your experience here?

In the automotive industry, if you ask someone from the board of directors, they will always say ‘I have gasoline in my blood, I’m product-driven’. But what is a manager really doing all day long? They are dealing with finances, the market, and the share price. At Porsche, under Wiedeking, we had an extremely small, high-performing team behind the scenes, and we were able to implement a lot.

With a small production quantity, it was crucial to keep the development costs low, because in the end it was reflected in the product cost. With mass production, it was more or less the component price. From a financial standpoint, you need to work extremely effectively and have a clear product definition and efficient processes. All of these things were excellent at Porsche.

That sounds exactly right. After a career like the one you’ve had, most would think of retirement, buying a nice house in the mountains, but no, you founded the company emm! Solutions. Now you have a great, young team at your company developing great products, such as the self-driving vehicle (ILO) or the Automated Guided Vehicle (AGV). 

You’ve seen both worlds now. You saw the corporate world in product development, but also the start-up space, with more agile methods of bringing products to market. How do they differ? Where do you see advantages and disadvantages and where can the two complement each other?

The first thing we do differently in the startup space is that we basically rely on standards, rather than reinventing them. We don’t differentiate ourselves by developing something that others can already do much better. We are not too proud to take a good solution from someone else. We’re focusing on system integration, not on the development of components. By concentrating on system integration, we were able to realize the vehicle extremely quickly. However, of course, the functionality cannot be compared to an OEM.

For example, what a vehicle can do on all kinds of roads, we don’t address that in the same way. We only do this for certain essential core areas. This doesn’t mean that the core cannot expand, but we don’t focus on overtaking everyone in the first step.

You need to focus on two things regarding the USP: what do you really want to achieve and how do you get it done in the shortest possible time? The realization time is the absolute differentiator. When you know exactly what you want and you can do it in a short time, you’re on the market earlier and it costs you less. It’s absolutely essential to understand how you can get to the market as quickly as possible to shape your economic future.

You will certainly inspire many with this interview, Armin. If someone wants to found a hardware start-up, what three tips would you give them?

My first tip is to get a clear picture of the market and customer. The second is to be sure product offering matches the effort and budget that goes into making it. You need to know who you want to serve and in what kind of market. If the product fits, you can do brutally innovative development. But that’s the framework for development. As a startup, this framework is the most important thing. Developing the product itself is not the challenge, but setting up the framework for success, that’s what I would focus on if I were starting again.

Great Armin! Thank you very much for sharing your experience with us today. It was really inspiring and it was fun. Thank you!

 Make an appointment with one of our cloud manufacturing specialists today to find out more about KREATIZE.