Stop selling hardware and turn your catalog into software-defined products

Automakers are struggling with long vehicle development cycles while losing billions to third-party repair shops. A software-defined vehicle (SDV) is an effective approach to addressing these challenges—it enables faster rollout of new models and features to ensure sales revenue and keeps track of vehicle performance for assured aftermarket revenue, tied digitally to the carmaker.

The SDV concept can be extended to software-defined products (SDPs) in other sectors too (industrial equipment, medical devices, and consumer goods). A product whose functionality is driven by specialized, embedded software is an SDP. In automotive, product owners adopting this tech can transform their products into customized mechatronic SDPs, using sensors and IoT for critical parameter feedback, actuators for action, and software with central command, thereby unlocking enhanced performance and differentiation.

Software, not hardware, will drive product differentiation and control

Software is the differentiating factor in today’s digital era, with its near-zero marginal cost for changes and updates. SDPs bring tailored benefits to various industries: safety (yet to be proven on a large scale), comfort, and productivity in automotive; affordability in healthcare; convenience in home appliances; and flexibility in software-defined networks. Onboard software is a source of revenue by itself. For instance, Tesla reported $326 million in revenue from its full self-driving software, achieving $25 billion in overall revenue during the third quarter of 2024.

SDVs initially focused on combustion systems and have since advanced to driver assistance, autonomous driving, infotainment, and comfort. Bosch’s early electronic control unit (ECU) in the 1960s digitally controlled the amount of fuel sent to the engines and the ignition timing. Electrical and electronic (E/E) architectures later became increasingly popular as a means to integrate the electrical, electronic, hardware, software, and communication components. Today, SDVs have more than 100 ECUs and around 100 million lines of code to support various functions. Morgan Stanley projects the tech will account for 90% of vehicle production by 2029, a significant rise from just 3.4% in 2021.

A typical SDV has sensors that enable proactive diagnostics to issue timely alerts for maintenance, repair, and spare parts replacement. It also gives over-the-air (OTA) updates for software fixes and new features. Tesla, for instance, demonstrated that capability in 2014 by issuing an OTA update to around 29,000 Model S vehicles instead of recalling them to fix a potential fire risk with the battery charger. The advanced driver assist system (ADAS) is another key feature, using sensors and logic for timely and safe navigation. Such advances toward flexibility, scalability, and the need for enhanced functionality across sectors mark a shift toward software-defined everything, a key learning covered in our recent HFS Research Horizons report.

Synchronizing hardware and software lifecycles ensures timely launch

Traditional carmakers have been struggling to integrate software in their vehicles, leading to product launch delays and buggy software. OTA upgrades, for instance, need thorough regression testing across vehicle models to ensure that new bugs aren’t introduced. According to the National Highway Traffic Safety Administration (NHTSA), nearly 6.8 million vehicles in the US were fixed through remote OTA updates in 2024, up from about 2.7 million the previous year.

However, experts have raised concerns about the use of software for car repair. As of November 2024, 41% of recalls were due to software issues, up from 15% in 2023. The software can be complex and lacks standards for quality assurance.

Moreover, modern car development is bimodal in nature—hardware and software are developed at different speeds, making it difficult to synchronize their lifecycles. Hardware typically follows a waterfall model with linear gated checkpoints for quality assurance, while software is iterative and agile. To bridge that gap, carmakers should implement the V-shaped model (see Exhibit 1) that Automotive SPICE (ASPICE; an industry-standard guideline for software development) advocates.

This model calls for cross-functional teams and clear channels of collaboration with shared goals. Along with this, a systems approach that integrates hardware and software should be adopted to avoid siloes and ensure that vehicle launch dates align with software delivery dates. Also, AI tools such as generative AI can be used to expedite the design process.

Exhibit 1: Models like ASPICE V ensure synchronized hardware and software development

Source: VDA QMC ASPICE model; HFS Research, 2025

With the electrification of vehicles a major trend, commoditization is inevitable. Onboard software and the features it enables are thus critical for product differentiation. According to BCG, onboard software is expected to account for up to 20% of a car’s value by 2030. It’s only a matter of time before this trend catches up in other product segments. Integrating AI in software further supports autonomy, decision-making, personalization of features, and optimization of overall operations.

Matching the maturity levels of SDPs to market needs will drive monetization

Manufacturers that continue to produce mechanical devices should consider transforming them into mechatronic devices to stay competitive and tap the benefits of SDPs. For those building products that are already mechatronic, decoupling hardware and software will ensure an agile development process. However, to realize the full benefits, product owners must reengineer the workflows and tools used in product development lifecycles and integrate software tool chains with common dashboards to provide a single perspective for status updates.

A critical step is adopting a maturity model based on distinct levels, such as the one regularly published by the Society of Automotive Engineers (SAE) for autonomous driving. Level 0 has no autonomy. Level 1 has limited features to assist humans. Levels 2 and 3 have autonomous operation, with the human ready to take over at any time. Level 4 allows for high autonomy under specific conditions with human intervention when necessary. Level 5 represents full automation under all conditions.

Product manufacturers should first assess the market needs to decide the appropriate level of maturity. They should then lay out a time-bound roadmap to achieve each level of autonomy for their SDPs based on their risk appetite for investments and the technical capabilities available both internally and in their partner ecosystem.

The Bottom Line: Software is no longer a component in modern vehicles, but the very chassis on which other systems are built.

In this intensely competitive market with shrinking product lifecycles, transforming products into SDPs is essential for ensuring timely releases, driving post-sales revenue, and avoiding obsolescence.

For product owners, the journey starts with making products mechatronic (if not already) and laying out a time-bound, feasible digital roadmap with increasing maturity levels, enabling software to take over critical functions.