Smartphones on wheels: New rules for automotive-product development

Software-driven cars need new agile, customer-centric processes along the entire product life cycle, with a software- and data-focused architecture, to bring product development into the 21st century.

There’s a riptide cutting through automotive-product development, and it’s forcing OEMs and suppliers to reoptimize their product development processes and R&D operating models.

Sidebar

Today’s customers demand new capabilities in their vehicles. They want advanced autonomous-driving features, for example, and new personalization and “infotainment” options. They also want to integrate digital services into an automotive ecosystem that goes far beyond the conventional car to a smartphone-like experience.

Moving from a conventional car to an automotive ecosystem—a kind of smartphone on wheels—requires changes to the vehicle’s electronics and software architecture. That means shifting from the traditional use of scattered, embedded electronic-control units (ECUs) to a domain-focused system with central vehicle controllers. 1 It requires more sophisticated software, including a software abstraction layer, Ethernet usage, and connectivity at scale. It also means greater use of more sophisticated microprocessors instead of embedded microcontrollers to boost performance, reduce power consumption, and centralize control.

Consequently, OEMs and suppliers need to shift their R&D processes and operating models from hardware engineering to a combination of software and tech-driven systems engineering. In this new environment, routine upgrades will happen throughout the vehicle’s life cycle, including over-the-air (OTA) updates to fix bugs, update software features, improve customer experiences, or sell new features not available at the time of the vehicle’s original sale. This requires that OEMs and suppliers shift their current development processes toward a cyclical, more integrated pattern and establish R&D steering approaches that connect software and hardware development along the entire life cycle of the vehicle.

The shift toward electrification due to market and regulatory forces has resulted in new requirements across all main vehicle domains, including new electric powertrains; thermal management and heating, ventilation, and air conditioning (HVAC) systems; and new infotainment services keyed to finding charging stations. Other new regulations related to cybersecurity, systems to manage software updates, and the use of Society of Automotive Engineers (SAE) Level 3 autonomous-driving capabilities could also make future vehicle performance parameters more complex.

These challenges require automotive manufacturers and suppliers to shift their focus in product development capabilities, processes, and operating models from mechanical engineering toward electrical and electronics, software, and data engineering.

Furthermore, the centers of gravity in global and regional markets continue to shift toward Asia, requiring local strategies to provide incentives for OEMs and suppliers to maintain local footprints and keep data in the region. This requires that all market players set up complex engineering networks around the world with global and regional hubs and partnerships.

From electrification and autonomous driving to digital services and connectivity, a massive number of innovations are on deck today, expanding the innovation pipeline. Likewise, the lack of clarity regarding key trends such as whether battery electric vehicles (BEVs) or fuel cells will become the dominant battery and energy solution could lead to increased R&D cost pressures. Expanding product complexity in the form of more control units, more software, and complex distribution functionality makes it difficult to attain high product maturity levels across product development processes.

Five ways to master automotive R&D challenges

As shown in Exhibit 1, OEMs and suppliers need to manage several game changers and shift their mindset to be competitive in future automotive-product development:

Smartphones on wheels: New rules for automotive-product development
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com
  1. From waterfall to agile processes. Companies need to move beyond the traditional component-based waterfall process that centers product development on hardware modules and embrace development systems that combine systems-engineering methods with agile-development processes and tools. For example, one leading electric-vehicle (EV) OEM gives a customer experience manager end-to-end responsibility to represent the voice of the customer. This changes the way suppliers and OEMs collaborate on the product so they can achieve higher-level, more integrated ways of working.
  2. From distributed, embedded software to a centralized electrical and electronics architecture. Instead of the traditional distributed and embedded software approach developed by tier-one suppliers, the industry is moving toward an overarching and centralized electrical and electronics architecture that integrates software modules from OEMs, tier-one suppliers, and tech players. Several traditional and new OEMs are moving in this direction by establishing dedicated software departments, while many car companies are designing architectures with two to three central computers and two to six zonal computers. Some are also creating single, harmonized software platforms. Suppliers are changing their offerings toward a platform that is scalable across OEMs and often move into more integrated partnerships with OEMs.
  3. From start of production to life cycle economics. Moreover, OEMs must take a step beyond optimizing the direct material costs of the vehicle toward cost and revenue optimization along the entire vehicle life cycle. This includes additional OTA revenues (such as through function on demand), the cost of software updates, and software update management. Many OEMs are already developing end-to-end financial R&D steering and benchmark-based R&D target costing, exploring ways to capture the business case over the entire product life cycle. This includes life cycle monetization through paid hardware and software updates. For suppliers, this implies a much stronger integration into the OEM’s steering model and a similar benchmark orientation in steering their R&D cost.
  4. From product tech to customer experience. Automotive manufacturers that once focused on products and their underlying technology are now examining a holistic customer experience. This includes exploring market-specific requirements and zeroing in on a holistic experience both inside and outside the car. Some EV OEMs are closely interlinking customer experience and R&D teams to pursue user-centric vehicle design and partnering with best-in-class players to build real ecosystems and improve the customer experience of their core products.
  5. From engineering-driven to data-driven development. Companies continue to migrate away from engineering processes and requirement definitions that rely on the experience of engineers. Instead, they’re heavily applying the data collected from customer vehicles and elsewhere as well as from virtual development and validation processes such as simulation. Several new industry players already focus on data-driven development, especially for autonomous-driving features.

Employ agile systems engineering

Automotive manufacturers and suppliers are moving from a strong hardware focus to a functional one, and many are changing their operating models to a systems-based development approach. This requires the introduction of a holistic systems-engineering approach combined with an agile organization and agile ways of working.

Adopting a systems-engineering approach

Systems engineering is about breaking large, complex projects down into smaller, more manageable pieces and orchestrating the interfaces between them. It provides standardized processes for the product development process.

A suitable reference system architecture is the key to successful systems engineering. Creating a logical and physical architecture that combines functional and physical elements typically starts with a functional system view based on system requirements. The goal is to design a modular product architecture to ensure that different teams can develop modules independently from each other in an agile way. This approach requires a top-down definition of general requirements with a strong focus on customer expectations and experience. The team then structures and breaks down the requirements along the reference system architecture. This approach features strengthened end-to-end responsibilities through clearly defined system-engineering roles and aligns the organizational structure with the system architecture to integrate the functional, logical, and physical architectures. The collaboration between OEMs and suppliers requires well-defined interfaces, using the logical or physical system breakdown as the guiding structure. Typically, this results in higher-level, more integrated ways of working in the collaboration between suppliers and OEMs.

Creating an agile organization

Automotive manufacturers and suppliers often combine overarching, classic engineering methods with agile development. Modern, complex product development uses improved top-down planning in sync with a bottom-up agile planning and development approach. Companies can use waterfall practices to define the overall vehicle and domain architecture. This in turn will allow them to provide agile teams with high-level inputs and boundary conditions. Based on these inputs, agile teams can create detailed requirements before developing and testing the components.

Making an agile R&D organization work: Three keys for success

There are three keys to making agile product development work: structure, process, and people.

Structure. OEMs and suppliers create a network of cross-functional, empowered teams. The approach anchors the responsibilities for prioritization, architecture, road maps, and commonality on each system level, driven by strong decision making in the project organization. The delivery organization links closely to systems engineering, reflecting the system architecture featured along the different system levels. Likewise, the line organization reflects competencies and module ownership to optimally support the delivery organization and safeguard component and system communality. The structure of line organization must build on defined ways of working in things such as team structure, roles, and processes, and delivery teams should be stable across different projects.

Process. The goal of agile product development is to create rapid decision and learning cycles, which requires organizations to put supporting processes in place and align them throughout the entire organization. Likewise, the approach applies iterative and incremental development processes to hardware and mechatronics development, synchronizing them with top-down planning.

People. Agile product development relies on a dynamic model that ignites passion in people. The mindset change to the agile model becomes core to the entire organization and all communications. This requires clear career paths within the agile context, built around new roles and moving away from the conventional hierarchical career paths. Training at scale includes change management to support the overall transformation.

Implement overarching, centralized electrical and electronics architecture and software

Software will be a key driver of customer experience and generate new revenue streams. Today’s market research shows customers want more than a traditional car ownership experience. For example, four out of five customers would repurchase their current ADAS (advanced driver assistance systems) solution, and more than two-thirds of premium consumers would switch brands for better ADAS functionalities. More than 40 percent of consumers also say they will use connectivity services more in the future, and about the same number are willing to pay for connected services. 2

To seize this opportunity, OEMs need to switch from purchasing ECUs with embedded software to a more centralized electrical and electronics architecture and hardware–software separation (Exhibit 2). This enables the reuse of software and individual purchasing of hardware and software, as well as the integration of OEM-developed software modules. Tier-one suppliers should prepare for software-defined vehicles by building up software capabilities, developing new business models for software, and creating new collaboration models with suppliers—for example, working in joint agile teams. The transformation will need to happen along three dimensions: technology, commercial structure, and commercial change.

Smartphones on wheels: New rules for automotive-product development
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

Technology. Technology will see a consolidation toward domain-centered archetypes (fourth-generation architectures) and zone- or vehicle-centered archetypes (fifth-generation architectures). This shift focuses on standardization by using IT components and systems via horizontally interlinked technical stacks instead of relying on integrated, embedded systems. Regional regulations and the cybersecurity ecosystem will in part enable this change. This means that OEMs must move from distributed architectures with ECUs for each specific functionality to a centralized architecture with the domain and vehicle computer abstracting hardware from software and the use of standardized interfaces.

Industry structure. The industry structure will change significantly when OEMs start sourcing hardware and software separately—for example, new players could enter the hardware and software space, or OEMs could work directly with tech players or tier-two specialists. To be successful, players must resolve new technical and commercial challenges at speed as new business models and specialist players in hardware and software introduce established, nonautomotive products to the market. OEMs must transition from working with several suppliers to creating alliances and partnerships centered on key technological control points, while tier-one suppliers must adapt to software sales and develop solutions in partnership with OEMs.

Commercial change. Introducing the next generation of automotive electrical and electronics architecture requires a comprehensive business case that looks beyond the vehicle start of production (SOP) and initial bill of materials. Next-generation electrical and electronics architectures will require significant upfront investments that will pay off only in the following generation. The acquisition, development, and retention of new software and system-engineering talent and capabilities will be core to success. This success will shift the business model away from one-time sales and toward vehicle life cycle revenue streams and new forms of monetization, such as pay-per-use or subscription-based models.

Focus on cost and revenue optimization over the entire life cycle

Automotive manufacturers are moving away from a traditional product development steering approach focused on direct material cost optimization targeting the SOP. Instead, companies are now exploring a holistic product development approach that optimizes the total cost of ownership (TCO) or the product business case over the entire vehicle life cycle, including sustainability-related costs.

Automotive manufacturers are moving away from a traditional product development steering approach focused on direct material cost optimization targeting the SOP.

Understanding current practices

Traditionally, OEMs and suppliers steer their product development activities without the support of a “single source of truth.” Instead, they rely on scattered data lakes and data systems for the most important product and cost data, including product specifications and features, material costs, R&D costs, capital expenditures, and other data. Typically, little data consistency exists across systems, and stakeholders base their planning and steering on different versions of data.

OEMs focus on material cost optimization to reduce product costs and improve product profit. Other important key performance indicators and business case dimensions include R&D costs, capital expenditures, variants-based complexity costs (for example, testing and validation and integration of life cycle maintenance), and sustainability costs (including CO2 penalties). OEMs typically do not consider other items, such as revenues and costs for product or feature updates, in their R&D steering approaches. Consequently, such steering is currently not based on a TCO perspective and a holistic business case. Furthermore, the strong focus on material costs can lead to a high number of variants in the product portfolio configuration.

Many OEMs employ a static financial steering approach that focuses on the SOP of a vehicle and does not consider dynamic or cyclical effects along the product development process. Thus, they systematically underestimate the effort and cost required today versus future revenues or costs over the vehicle’s life cycle. Furthermore, future revenues and costs are planned, targeted, and tracked in the same way as development efforts and product costs that happen before the SOP due to a lack of experience with update and release cycles for software, for example, and the underlying life cycle revenues and costs.

Seeing what the future holds

OEMs must transform their approach to product development steering to focus on cost and revenue optimization over the entire vehicle life cycle as shown in Exhibit 3. They should implement end-to-end product development steering and controlling based on a single source of truth. This approach features a harmonized systems landscape and a single end-to-end data backbone along the entire process of product development and life cycle management that connects all relevant steering KPIs. The systems landscape and data backbone must feature a common product structure that enables end-to-end steering from a systems perspective for team leads and department leads, all managed by the R&D controlling staff.

Smartphones on wheels: New rules for automotive-product development
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

Steering toward the ‘right ambition level.’ The product development team should derive targets by benchmarking development projects—and the benchmarks should reflect the true project intent. The team should set targets for all core steering dimensions, especially material costs, R&D costs, and capital expenditures, centered on benchmark-based target costing.

OEMs have an opportunity to redefine their performance regarding R&D hardware and software costs. First, they need to set the right ambition level to drive innovation at a competitive cost level and identify opportunities for efficiency improvements to free up resources for other projects and innovations. They should optimize project assumptions (including levels of reuse, which technical concepts to use, and the amount of outsourcing) to prioritize R&D resources for the most important projects. OEMs also need to provide a fact base to support the planning and steering of their own R&D activities as well as negotiations and steering of suppliers and engineering service companies.

OEM can typically use commercial databases to support their benchmarking efforts on material costs and capital expenditures; for R&D hardware and software costs, third-party providers can help. Companies should base their product development steering efforts on holistic business case optimization. The core of the steering approach should be the total product business case based on the TCO, including any costs that arise during the initial product development phase (for example, R&D costs, capital expenditures, and product and factory or production costs). It should also include all revenues and costs generated over the product life cycle, which can include product maintenance, releases and product updates for hardware and software, function-on-demand offers, and sustainability costs such as CO2 penalties.

Companies should base their product development steering efforts on holistic business case optimization.

Players shift the steering scope from SOP to life cycle management to enable “design for upgradability” and to enhance the lifetime of the product. Product development steering should fully use the potential of OTA capabilities deployed in vehicles to offer feature updates, function-on-demand offerings, and new features such as higher levels of autonomous driving. It is important to note, however, that while this strategy will generate additional revenues, it will also create additional costs.

Be customer centered and market specific

Traditional product-focused R&D and product development processes typically remain in their lanes and have few structured interactions with other functions such as marketing and sales. Direct customer interactions or feedback remain rare and limit the voice of the customer in important product decisions.

Instead, OEMs need to become more customer centered across the entire product development process, even to the point of launching a dedicated customer experience (CX) unit. The goal is to achieve customer-centered product development with integrated feedback from customers in short iteration cycles, where the voice of the customer sets the pace for the product development process. The OEM needs to ensure that all required information is shared with the suppliers, allowing them to significantly increase their customer centricity. In this approach, the OEM’s CX team is involved in the entire R&D process, from the initiation of the project to SOP and life cycle management.

Before development starts, the team examines CX insights and conducts mid- to long-term planning as it collects business and industry trends and user feedback.

During development, the team focuses on realizing a CX-driven unique selling point design. The CX team discusses the feasibility of CX elements with R&D, creates product and requirement documents, and participates in all aspects of development. It also influences requirement changes and cocreates the vehicle with technical R&D teams to ensure the product accurately reflects CX elements. Weekly progress reports enable managers to track progress between CX and R&D teams and their alignment on requirement changes.

After SOP, the team drives CX upgrade opportunities and product life cycle management. It collects and aggregates user feedback, supports the R&D department in analyzing feedback, and disseminates conclusions to the relevant development teams.

Becoming customer centered also requires a new go-to-market model that features direct interactions between the OEM and the end customer. Such direct sales will give the automaker full control over the customer experience, whereas a traditional overreliance on franchised dealers could lead to inconsistent customer handling. Beyond participation in the vehicle’s initial sale, OEMs need to cultivate a true life cycle experience with multiple car and noncar touchpoints per month. Where in the past automakers had to contend with patchy customer relationship management (CRM) data and limited sales lead analytics, this new approach provides full access and the full use of customer data through advanced analytics.

Develop data-enabled engineering and virtual-engineering capabilities

Automotive OEMs are undergoing an essential transformation from experience-based engineering toward data-driven, virtual engineering. This development is strongly integrated and will affect automotive suppliers in the same way. The goal is to improve the product by developing new features (such as SAE Level 4 and Level 5 autonomous-driving capabilities) and increase R&D efficiency.

Traditionally, OEMs incorporated engineering capabilities based on the collective experience of their engineers and experts with only limited data on customer behavior and product performance in the field. They made limited use of testing fleets or static hardware-in-the-loop or software-in-the-loop testing environments.

Going forward, OEMs need to adopt data-enabled engineering and virtual-engineering capabilities to understand the value drivers of automotive customers in today’s new ecosystem, which includes autonomous driving and data services. Automakers should also increase their engineering efficiency and use their limited R&D resources most efficiently. The adoption of these capabilities will also be pushed toward suppliers.

Two product-related use cases illustrate potential changes in this area. The first use case takes advantage of advanced simulation techniques to improve multiphysics simulations via surrogate models or virtual testing with an AI-based driver in the loop. The second use case involves data-driven development based on a state-of-the-art big-data architecture. This architecture consists of a big-data stack in the backend, broad OTA capabilities, and a protected mode in the vehicle stack for in-vehicle simulations. It’s paired with algorithms based on machine learning to intelligently collect data at scale and identify “interesting situations” to propel the development of Level 4 and Level 5 autonomous-driving features or optimize driver-assistance features. It represents a critical enabler and precondition for leaping into Level 4 and Level 5 autonomous driving.

Beyond product-related improvements, this transformation should propel productivity and efficiency advances due to predictive maintenance or defect detection enhancements. Likewise, proactive risk and error detection actions will improve overall productivity based on predictive maintenance and machine learning algorithms, as will intelligent talent and team management techniques such as capacity management and scheduling.

Implementing big-data infrastructure and architecture is an essential requirement for driving data-enabled engineering and virtualization. Elements of these include the data backbone; the backend or big-data stack; in-vehicle architecture; technology such as machine learning algorithms and simulation techniques; and governance, including data governance, legal framework, and consent management processes.

Take two steps to get started

Automotive OEMs and suppliers need to adapt quickly to maintain their R&D competitiveness in areas including time to market, cost, quality, and new-feature rollouts. The first step should be a thorough and rapid assessment through benchmarking, diagnosing, and pursuing development. To benchmark R&D performance, they should compare their performance against peers on dimensions such as R&D intensity, new-product costs, time to market, and R&D offshore ratios. OEMs should also conduct an opportunity diagnostic, which involves making a quantitative assessment of R&D productivity based on historical programs and developing a digital workspace for continuous program review. Finally, OEMs and suppliers should pursue software and hardware development target costing, including for the needed resources and associated costs.

In the second step, players need to prioritize their efforts and set up a transformation office to drive change. Requirements for change include conducting constant reviews, adjusting objectives as necessary, and tracking target achievements. Critically, top management must actively drive this change.


Bringing automotive-product development into the 21st century is a difficult but necessary step if OEMs and suppliers want to remain competitive in the face of new architecture and software-centered challenges ahead. Done right, product development will change the ways automotive companies conceive of, plan, engineer, and monetize new products, thus expanding their go-to-market strategy, business case, and revenue streams. This new approach to product development isn’t just a fad—it’s the future. OEMs and suppliers that hesitate to make this change could find themselves playing catch-up for a long time to come.

Explore a career with us

Related Articles