Modular designs and product platforms strategies enable companies to build a broader portfolio of offerings for customers, including niche products at acceptable cost, at less effort. But to capture these advantages, companies must choose the right organizational design for their product development function as well as manage it strategically.
Facing stiffening competition and ever-accelerating development speed, companies in an array of industries—automotive, consumer products, appliances, and semiconductors—are broadening their product portfolios and offering tailored solutions, even for narrow customer segments. The result is lower production scale for some products. Companies have increasingly used product platforms and more recently modules to manage such broadened product portfolios at acceptable cost and effort.
Platforms and modules are typically defined as standardized parts or a catalog and are described in module books.1 They enable companies to benefit from production scale, by reducing the number of product variants and thereby reducing complexity and its associated costs along their value chain (for example, in product development, materials, manufacturing, and spare parts).
But to deliver their promised advantages, platform and modularity concepts must be supported by the right product development operating model. Such a model determines how a development organization develops platforms and modules. It also helps ensure that standard modules as well as platform rules are used with actual products. In developing their product development operating model, companies must define the organizational structure, roles, and responsibilities as well as decision rights and processes for handling change requests.
Adopting a platform/module strategy
Historically, companies have developed most products by taking a project approach, temporarily pulling together all required specialists from their line organizations into a product "house." These project teams would develop the new product completely from scratch or based on a predecessor or similar product, opportunistically using existing modules, drawings, and other resources. Thus, project teams have had considerable freedom in making design and development choices.
As companies transition toward platforms and modules, such freedom is reduced. Platforms (and modules even more so) require project engineers to follow a set of rules to gain the scale advantages offered by the module concept. At the same time, the line organization needs to take much more responsibility for defining the platforms and modules, for the design and robustness of the standards and the interfaces, and for changes and innovations in the modules. This all needs to be orchestrated in a way that ensures modules are actually applied without changes in the products (Exhibit 1).
A well-known example in the automotive industry is Volkswagen. Many years ago, the company defined a platform with strict geometrical restrictions for the lower part of the vehicle. Engineers had to stick to the platform to capture benefits of scale for different models with variations in the upper part of the vehicle. A few years ago, Volkswagen pushed further by creating a catalog of modules from which the engineers must pick. Other automotive OEMs and suppliers, as well as companies in other industries, have copied this approach.
Adapting the structure of the product development organization
As described above, introducing a platform and module strategy requires a different way of working that reappoints responsibilities within the organization. The journey from pure project orientation to platform and module responsiblity requires to define several new roles and modify existing ones (Exhibit 2). For example, new roles might include the following:
- Modular strategy lead defines the company's overall strategy for where to apply modules in product architecture and where to apply product-specific solutions. With module leads and platform leads, he or she ensures that modules are applied without changes.
- Module lead owns global module development, including the module book and road map, guards against module overcomplexity, ensures reuse and best-practice transfer by incorporating feedback from system integrators, and drives module innovation.
- Platform lead owns global platform development, including the future road map; defines differentiation of products across the platform together with those responsible for portfolio strategy and with sales; defines module interfaces; reduces platform complexity; and drives platform innovation.
Roles that are modified might include the following:
- Project manager to system integrator remains responsible for developing products on time, according to specifications, and within budget, but now integrates existing systems and modules instead of developing them from scratch.
- Portfolio strategy lead defines global and regional product portfolios including product differentiation, aligning with the modular strategy lead on commonalities versus differentiation across products.
This shift in roles moves the product development organization from a pure project orientation (orchestrated by R&D and product managers) to a platform and module orientation. In the development organization, the newly established roles of module lead and platform lead are key to future development success. Why? The module lead ensures scale and innovation while the platform lead ensures optimal architecture and integration of the modules as well as circulation of feedback to module leads (Exhibit 3). For the overall success of a product, companies must also strike the right balance between commonality and differentiation across products. The portfolio strategy lead, along with the modular strategy lead in collaboration with platform and module leads, shoulders this responsibility.
These roles are similar in many organizations that have implemented modularity. But there is considerable variation in the actual organizational design. Moreover, companies will generate different answers to questions such as the following:
- Where is the platform lead located in the organization? Does he or she report directly to the CEO?
- Where are the system integrators allocated? Do they report to the platform manager or to an integration function in the product development line organization?
- Where should module leads be located? In a dedicated function? Or spread across several functions? How are different geographies involved?
- Where is the modular strategy lead located? In a central organization? Does he or she also own tools and frameworks and supervise implementation rates? Or do the module leads handle these responsibilities?
- How close is the modular organization to top management? How is top management involved?
In addition to having to create new roles and redefine existing ones, companies transitioning to a platform/modular strategy also face two key challenges: managing platform and module changes as well as innovation, while ensuring use of standards. Below, we offer insights into how companies can surmount these challenges.
Managing platform and module changes as well as innovation
Companies need to establish a process for efficiently and effectively managing the inevitable requests for changes to platforms and modules. Such requests can be triggered by a number of different events. Some are internal. For instance, a company sees a way to improve assembly or manufacturing of a particular product by changing a subsystem or component or by altering a technological solution. These and other types of innovation are usually a trigger for substantial changes. Other events are external, such as shifts in customer requirements, in the competitive landscape, in the regulatory environment, or in industry standards.
Some change requests affect only the module and do not require modification of the platform. (That is, all modules keep the same interfaces.) Other change requests affect both the module and the platform. But regardless of where the impetus for change is coming from and what it will affect, companies must determine whether to make changes and, if so, which ones to make. They must also decide whether and when to update their platform and module books to reflect changes. Such questions can be boiled down to: "Do we make an exception to accommodate this type of change request? Or do we make it a new standard?"
Companies can set up a new, cross-functional organizational structure—a modularity steering committee—to resolve these problems. The committee analyzes change requests and uses a disciplined process to determine which (if any) changes should be reflected as updates in platform and module books. In making these decisions, committee members consider a number of criteria. These include the market potential that could be captured if the change were made, as well as cost and complexity implications.
New modules may be introduced only if they are legally required or if the committee can show that they will deliver positive business results. For instance, perhaps adapting a module to regional taste would help the company capture higher market share in a region while requiring a few new variants. In this case, the committee might decide to update modules to reflect the change and to develop a new or altered variant with standard interfaces. If an innovation would involve intensive modifications to variants and thus high levels of complexity and cost, the committee will have to consider whether the innovation is critical enough to justify the additional effort and cost.
Ensuring the use of standards
In addition to change requests, companies must find ways to ensure that their standard modules are applied as is. Many factors could prevent engineers from selecting the standard. For instance, a product's design does not allow for enough space, or innovations in nonstandard parts may require different boundary conditions. Most changes to standard modules are small, but the effect on cost for the components may be high if a modification requires changes in tooling, manufacturing processes, or logistics.
Therefore, companies need to establish clear governance that reinforces modularity and use of standard modules. The modularity steering committee should thus comprise high-ranking members and be charged with approving deviations from the standard as well as changes to the standard. The goal is to make the hurdle for deviation requests very high in order to truly capture the benefits.
Looking ahead
Many companies have already completed the journey toward modularity or have made major strides in this direction. But owing to advances in connectivity and the Internet of Things, we believe that many companies will have to find ways to update and upgrade products outside of their normal development cycles. Take automobiles, which historically had a product life cycle of seven years (the time between a predecessor and a new car model). OEMs will have to explore ways to adapt functions "over the air," as Tesla has done with its suspension system, or incorporate much later in the development process a special feature that the competition introduced. Companies can tackle some of these challenges using modules that can be refreshed during a product's life cycle. For other challenges, they will need to take a more feature-based approach to product development—which requires massive changes to the product development organization. For example, automotive OEMs might organize their product development around features like safety or parking, including all systems that may be used for these features instead of using a rather simple module approach.
About the authors: Fabian Bannasch is a senior expert in McKinsey’s Munich office, Giorgio Rossi is a partner in the Rome office, and Benjamin Thaidigsmann is a consultant in the Berlin office.
1 For an introduction to modular strategy and design approaches, see the relevant articles in "Product Excellence".