Tesla Model 3 agile car development framework

When I wrote about the Tesla Model 3 I focused on design , infotainment system and its pre-order success. Today indeed I write about the production approach that, reading the recent news about skipping the beta testing, is going to be assimilated to the agile software development framework.

In the last days I read many articles about the Model 3 pre-production beta testing skipping. This news was so curious that I needed to retrieve the source, so link after link I landed on the Anton Wahlman articles on Seeking Alpha “The Secret Tesla Investor Call To Which You Were Not Invited” and “Tesla Selling Model 3 Test Cars: Accounting Questions“. Considering that at the moment none knows how these “test cars” will be sold, which quality level they will have and what kind of refinement will be done by the testers/customers, I’ll focus on what I define the Tesla’s agile car development framework.

First, what does agile software development is? Wikipedia says:

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.

For understanding how this applies to Tesla and Model 3, you don’t need to be a Software Engineer or a Digital Product Manager like me. Read just the words that I put in bold and then think how normal is buying a videogame or a smartphone and immediately update it online. Is it possible for a Tesla? The answer is yes, but why?

Tesla isn’t a traditional carmaker, not only for the charismatic presence of Elon Musk and not only because its investors are continuing putting money in. Tesla actually is the unique car producer that together with a car produces a software Operative System that, thanks to the car’s hardware, can manage remotely things that any other carmaker couldn’t control neither at its official assistance network. The most impressive Tesla OS back-end updates are: the battery capacity, the engine power and the self-driving functions.

Whatch this overview video where the deep hardware and software integration is demonstrated.

Reading the Tesla OS official page is easy to understand that the Musk’s car are disrupting the automotive industry because they shifted the core of their products from mechanics to software development. It doesn’t mean that the Teslas hardware (chassis, shocks, body, glasses etc) aren’t good enough the other carmakers or that they didn’t need the same R&D and pre-production tests. What Musk said is that the knowledge-base that they have accumulated from the development of the Model S and Model X will give them the opportunity to jump directly to the production lines skipping the beta test and leaving the “final testing” to the first users (read this Wahlman article for in-depth analysis).

Skipping the beta testing for a traditional car-maker is a sort of suicide, but if you are Tesla it is the first application of its agile car development framework approach. The Tesla’s cars are really different from the other cars. Its engines, chassis, interiors and all the other components are a way simpler from the other cars so, once tested and standardized, they don’t need to be tested again for all the models. I suppose that the electric engines and the batteries can be scaled in a easiest way than the combustion engines, and that the chassis architectures simpler and less stressed than traditional cars. Moreover the Tesla Model 3 will be really more simple than the Model S like this official press release states and the dashboard (absence!) suggests.

Above this, for sure Tesla has other three big advantages. The first one is the big amount of real usage data that users need to share with the company for having the OS updates; the second is the capacity to absorb a lot of physical/software recall/updates thank to its low volume production, its dealers network and its over the air OS updates; the third is the customers base that is composed by engaged and motivated fans that are healthy, techies, early-adopters, green contingent and sports car lovers (read “Elon Musk and the cult of Tesla” by Hope Reese).

So the Model 3 beta test skipping shouldn’t be interpreted like a dangerous move for accelerating the mass production and keeping the investors happy (during the investors call Musk admitted a delay in the mass production plan). It is more like an iteration of a product with the most important hardware parts already tested, while the easily replaceable components and the less critical front-end functions are still in development.
To be simple.
Tesla is like Facebook launching its new app. The core is always the same but the design improves fast and in an iterative way. For this reaason Tesla presented the Model 3 as the next company model, not as a concept car.

Tesla has commoditized the cars hardware focusing on user experience, green technology, autonomous driving, products distribution and customers engagement.

That’s agile, but it is even a strategic move for conquering the electric vehicle supremacy and restarting, in 5 or 7 years, the traditional research and the tests for a real new product.

Photo credits: A2design, BGR, Carscoops.

The biggest problem of the level 3 self-driving cars are the drivers

I’m following the evolution of the self-driving technologies with a lot of interest. Many automotive companies say that by 2020/2022 they will commercialize autonomous cars that will reach the level 4 or 5 of the SAE International Automated Driving standards.
Below the table that is commonly adopted by all the automotive industry.


Download the pdf here.

Wired points the level 3 human problem in a very clear way: humans are not capable to maintain their attention if they are not interested or required to. For simplifying, a crash in self-driving mode cannot be avoided thanks to the intervention of the driver that in the meanwhile could be reading a newspaper or watching a video. Humans are just too slow and in that case even too distracted for recognizing the risk and avoiding a crush.

Read more

Self-driving bus service models and passengers User Experience

In the last months automotive world is talking a lot about autonomous and self-driving vehicles both for private and public transportation. During my day researches one day I found the exciting call for collaboration for Olli, the self-driving vehicle produced by Local Motors.

Designing the autonomous bus user experience is a complex task: for first because self-driving buses will serve the traditional public transportation diversified and multi-age target; second because without the driver and, in some cases, without a fixed route, passengers will have some new functional and informational needs.

The first part of my project started with a Service Design session focused on what kind of transportation services a self-driving bus can serve.

Personal on-demand shuttle

It’s like a Taxi/Uber, but less exclusive and more spacious. It brings one or more people from A to B. It can be reserved days in advance and can make various stops during a single dedicated service. The served area is restricted.

Shared on-demand shuttle

It’s like public transport service except for the fact that passengers can add a personalized stop to the route within the bus pertaining area. The route is dynamically optimized depending on users destinations and pick-up calls. The high level of complexity makes this service ideal for closed areas like small districts, big companies, entertainment parks etc.

Public Transport

It’s exactly the same public transport service as we know it.

Delivery service 

It’s like sending objects using a shipping company, but instead of giving the package to a human, users will schedule the shipment using an app or a dedicated device in the bus, and then they store the package in a secured housing inside the vehicle. The recipient will track the shipment in real-time and will be alerted when the bus is at the delivery point (or in front of his door). This service can be added to the “Shared on-demand shuttle” one, or it can be configured as an automated delivery service with customized buses and dedicated physical hubs.
This delivery service model is useful for companies that need to transport small parts within a relatively big space, or in modern cities creating a sort of fully automated shipping/delivery hubs for connecting wholesale shops and retails stores.

After this first Service Design session, I started a User Centered Analysis focused on the self-driving bus passengers needs. For designing a real accessible service, I defined only “analogue” needs excluding all the information/functions that a smartphone app could have. What you read is what my grandmother or a manager with a dead smartphone could need for using an autonomous bus.

What self-driving bus passengers need outside the bus

– Passengers need a purchase and reservation system that should be both digital (app), physical (street’s stops signs) and gestural (raising the hand for asking to catch the bus).
Here some examples of a simple bus stop sing with a call button (left) and an advanced stop sign with an integrated ticket machine and a digital screen (right).

SelfDriving_Bus_Stops_TicketsMachines_AntonioPatti

Read more