Why automotive software has mostly failed

If you collect a list of annoying products that still seem to have made their way into our daily lives, automotive software would be one of the top contenders (the others include home switching system, conference software, water temperature regulator). You don’t know what the automotive software actually does, what it has to offer or why you even need it. In my ~5 years at Ather Energy building vehicle software experience, I have had a unique position to understand why such a high potential product has fallen flat in most OEMs.

It is telling when leading consulting firms’ whitepapers that started with predictions of connectivity tech being the “next big thing” or a “game changer for automotive business models”, ended up analyzing why companies have failed to monetise it. In this article, I share my views on what went wrong in most companies and hopefully this gives some pointers to the industry professionals on fixing some of their issues.

First things first, we would all do ourselves a great favor by changing the way we refer to the product internally (and externally) as software-defined-vehicle or vehicle connectivity. Branding of any product starts with its name and a name that conveys the tech instead of what it does as a product has a good chance to fail. Inevitably, the way the teams and orgs start thinking about this product is in terms of tech, that is, “here is the tech, what can we do with it”. It is no surprise that the eventual outcome from this approach is a hodge-podge of features that can be implemented with this tech. There is a clear lack of intentionality on why a certain feature exists or how it changes a customer’s life.

Second, the leadership of the OEMs have faced a puzzling conundrum on where to fit the team(s) working on this product in their org. By nature, software product development, skills and ways of working are different from hardware. Some chose to club it within the larger IT departments or within their digital technology teams. These are the teams who are chartered with digitalizing the company’s operations and now find themselves also owning an end customer product, a very different ball-game. In other cases, these teams are part of the vehicle programs but often understaffed, under-represented in key forums and without a seat at the table. As a result, these products are an afterthought and not integral to the product development process and decision making of a vehicle. In yet other cases (specially in 4-wheelers with internal R&D teams), the org is structured by sub-systems, each operating within its silo and creating the software-defined-sub-component instead of a holistic approach to it. None of these options really work effectively and the results are there for all to see.

Third, the lack of in-house capabilities for a product (and tech ecosystem) that is not yet mature has led to vehicle software getting outsourced to tier-1 suppliers. So, effectively, the product ended up being called an infotainment cluster (though it can be much more than what the name conveys) whose roadmap is largely determined by tier-1 suppliers who are one degree away from the end customers. This implies that there is limited flexibility for an OEM to evolve or iterate the product once it has been put in the customers’ hands and unable to implement any feedback loops.

Fourth, this product that is by now defined or identified as a tech, doesn’t become a part of the product story. There is no branding on this product, there is little story-telling around it and it is largely seen as a list of features to dump because the tech allows it. This means that it gets underrepresented in both branding, marketing and sales. (For example, Microsoft gave the name ‘Copilot’ to convey what LLM based AI does as a product. Imagine, if it was instead called as GithubAI)

Fifth, this is essentially a software product that is built and sold like a hardware product. There is no GTM and it just ends up creating a vicious cycle of belief that the users don’t care about this by the sales staff. 

Finally, the product development part itself has a gap. It is closest to a B2C SaaS product but developed like a hardware product. B2C SaaS products (and consumer internet products) have developed a good amount of sophistication in product discovery, iterative development, fast feedback loops and GTM. All of these are essentially different from how hardware products are built. The internet technology enables tools and methodologies that are impossible to implement for hardware products such as A/B tests or rapid iterations or detailed usage analytics. Not leveraging the power of these tools is criminal. For starters, product building or feature building is not just development of the core functionality of the feature. From discoverability, to onboarding, to education, to creating hooks and nudges, to creating habit building, to product support are all part of the definition of a product. That’s what differentiates, say Apple products, from many other copies even when there is feature parity. Moreover, it is important to implement continuous product discovery and feedback loops for rapid iterations (aka, new iteration within weeks instead of years as in hardware products) to build the perfect end-to-end experience for the product. When none of this is taken care of, it becomes a classic case of feature development rather than solving a customer problem.

The gaps in some or most of the above areas has unfortunately created a negative sentiment among the industry insiders on whether this is truly a game changer as was originally touted or just “bells and whistles” that is probably required just to be able to claim that it is a connected vehicle. The biggest fallout from this, in my view, is the increasing attitude to see the value proposition of this product in diagnostics rather than a significant elevation of user experience in how they ride their vehicles today. From being an asset with immense (and exponential) monetisation potential, it is now viewed as something that adds to cost efficiency through remote diagnostics and predictive maintenance capabilities. Nothing can be further from this and I hope that the OEMs see the immense potential of this product.

PS- this article is a high level summary of the key areas of gaps leading to why I think most automotive companies have failed here. In my subsequent articles, I will detail out some of the points covered here. There is also a lot of similarity in the larger space of IoT (and thus, smart/ connected devices) that appear to be falling into the same trap as vehicles.