Planning for Product Platforms

Reading Time: 28 min 

Topics

Permissions and PDF Download

In 1987, Fuji introduced the QuickSnap 35mm single-use camera in the U.S. market. Kodak, which did not have a comparable product of its own, was caught unprepared in a market that was destined to grow by more than 50 percent per year for the next eight years, from 3 million units in 1988 to 43 million in 1994. By the time Kodak introduced its first model almost a year later, Fuji had already developed a second model, the QuickSnap Flash. Yet Kodak won market share back from Fuji; by 1994, Kodak had captured more than 70 percent of the U.S. market.

The success of Kodak’s response resulted in part from its strategy of developing many distinctively different models from a common platform. Between April 1989 and July 1990, Kodak redesigned its base model and introduced three additional models, all having common components and common production process steps.1 Because Kodak designed its four products to share components and process steps, it was able to develop its products faster and more cheaply. The different models appealed to different customer segments and gave Kodak twice as many products as Fuji, allowing it to capture precious retail space and garner substantial market share.

The platform approach to product development is an important success factor in many markets. By sharing components and production processes across a platform of products, companies can develop differentiated products efficiently, increase the flexibility and responsiveness of their manufacturing processes, and take market share away from competitors that develop only one product at a time. For example, in the auto industry, firms taking a platform approach enjoyed market share gains of 5.1 percent per year, while firms pursuing a single-model approach lost 2.2 percent market share per year.2

The platform approach is also a way to achieve successful mass customization — the manufacture of products in high volumes that are tailored to meet the needs of individual customers.3 It allows highly differentiated products to be delivered to the market without consuming excessive resources.

In this article, we define what we mean by a platform, describing the benefits and challenges of platform planning. We articulate three ideas underlying the platform approach to product development and present a method for planning a new platform of products. Finally, we provide recommendations for managing the platform-planning process.

Fundamentals of Platform Planning

Platform planning poses both opportunities and difficulties for companies. Basic to the effort is understanding what a product platform consists of. We define a platform as the collection of assets that are shared by a set of products. These assets can be divided into four categories:

Components — the part designs of a product, the fixtures and tools needed to make them, the circuit designs, and the programs burned into programmable chips or stored on disks.

Processes — the equipment used to make components or to assemble components into products and the design of the associated production process and supply chain.

Knowledge — design know-how, technology applications and limitations, production techniques, mathematical models, and testing methods.4

People and relationships — teams, relationships among team members, relationships between the team and the larger organization, and relationships with a network of suppliers.

Taken together, these shared assets constitute the product platform. Generally, platform products share many if not most development and production assets. In contrast, parts-standardization efforts across products may lead to the sharing of a modest set of components, but such a collection of shared components is generally not considered a product platform.5

Benefits of Platform Planning

Companies that engage in successful platform planning realize benefits in many areas. They have greater ability to tailor products to the needs of different market segments or customers. The platform approach reduces the incremental cost of addressing the specific needs of a market segment or of an individual customer, enabling market needs to be more closely met.

Companies can reduce development cost and time. Parts and assembly processes developed for one model do not have to be developed and tested for the others. This benefit applies to new products developed from the platform and to updated products. They can also reduce manufacturing cost. When producing larger volumes of common parts, companies achieve economies of scale. Companies can also reduce production investment. Machinery, equipment, and tooling, and the engineering time needed to create them, can be shared across higher production volumes. Companies can simplify systemic complexity. Cutting the number of parts and processes lowers costs in materials management, logistics, distribution, inventory management, sales and service, and purchasing.6

Another benefit is lower risk. The lower investment required for each product developed from a platform results in decreased risk for each new product. Companies will also improve service. Sharing components across products allows companies to stock fewer parts in their production and service parts inventories, which translates into better service levels and/or lower service costs.

Challenges of Platform Planning

Companies developing platform products must meet the needs of diverse market segments while conserving development and production resources. The effort involves two difficult tasks. First, product planning and marketing managers address the problems of which market segments to enter, what the customers in each segment want, and what product attributes will appeal to those customers. Second, system-level designers address the problem of what product architecture should be used to deliver the different products while sharing parts and production steps across the products. These two tasks are challenging because they are inherently complex and because their completion requires coordination among the firm’s marketing, design, and manufacturing functions. Since these functional groups may be unaccustomed to working with each other, conflicts may arise over differing time frames, jargon, goals, and assumptions.

Furthermore, platform planning is difficult because of the many ways in which it can fail. We have observed two common problems in companies attempting to create product platforms:

First, organizational forces frequently hinder the ability to balance commonality and distinctiveness. One perspective can dominate the debate. For example, design or manufacturing engineers often prepare hard cost data showing how expensive it would be to create distinctive products, leading to products that are too similar from the customer’s perspective. The resulting imbalance was illustrated (if perhaps inaccurately) by a Fortune cover photo showing “look-alike” Chevrolet, Oldsmobile, Buick, and Pontiac automobiles.7 Alternatively, the marketing function may argue convincingly that only completely different products will appeal to the different market segments and that commonality is penny-wise and pound-foolish.

Second, even when platform planning takes place with a balanced team committed to working together, the process can get bogged down in details, resulting either in the organization giving up or in products lacking character and integrity.8

Platform Planning in the Auto Industry

We believe that the platform-planning method we describe next is applicable to many types of products. To illustrate the method, we use an example from the auto industry: the design of an instrument panel, or dashboard. A critical part of a new car’s design, an instrument panel plays several important roles. It provides structural support for heating, ventilation, and air conditioning (HVAC) ducts; components; switches; gauges; audio components; storage areas (such as the glove compartment); airbags; and tubing and wiring. The instrument panel also must help absorb the shock of a front or side collision and help prevent the car body from twisting during normal driving. Finally, the instrument panel plays an aesthetic role: the look, feel, and even smell of an instrument panel can affect the appeal of the car and distinguish one car from another. (The instrument panel example is drawn from our experience with a major auto manufacturer; for the sake of clarity, we have minimized technical details.)

Balancing Commonality and Distinctiveness

At a fundamental level, product variety is valuable in the marketplace, yet it is usually costly to deliver.9 The sharing of assets across products allows companies to manage the trade-off. Platform planning balances the need for distinctiveness with the need for commonality. Three ideas underlie the platform-planning process.

1. Customers care about distinctiveness; costs are driven by commonality. Customers care whether the firm offers a product that closely meets their needs; they are not particularly concerned about how many parts a collection of products has in common. Closely meeting the needs of different market segments requires distinctive products. At the same time, the cost of a firm’s internal operations is largely driven by the level of parts held in common among a collection of products and is not directly related to how distinctive those products are in the marketplace.

We use the term differentiating attribute (DA) to denote a characteristic that customers deem important in distinguishing between products. Two products are distinctive from one another if the values of the DAs that characterize the products are noticeably different. For example, interior noise level is a DA for automobiles. Customers generally expect different values of this DA for different kinds of vehicles, such as audible cues from the engine in sporty vehicles but near silence in luxury vehicles.

We use the term chunk to refer to the major physical elements of a product, its key components, and sub-assemblies.10 A set of products exhibits high levels of commonality if many chunks are shared. At many car companies, for example, the engine compartment is treated as a chunk that may be shared across several vehicles.

Although DAs and chunks are related (interior noise level, a differentiating attribute, is influenced by insulation, a chunk), they reflect two very different ways of describing a product. DAs reflect the level of distinctiveness as perceived by the external customer; chunks reflect the level of commonality as perceived within the firm.

2. Given a particular product architecture, a trade-off exists between distinctiveness and commonality. Consider a pair of products. If these products shared 100 percent of their parts, they would have commonality but no distinctiveness. If these products shared no parts, they would have no commonality but could have an arbitrarily high level of distinctiveness. As the percentage of common parts increases from zero to 100, the distinctiveness of the two products declines to zero. For example, the instrument panels for two different automobile models could be arbitrarily distinctive if they shared no parts. A manufacturer might share several parts of the instrument panel, such as mounting screws and small brackets, with little loss of distinctiveness. As more and more parts such as gauges, environmental controls, and audio systems are shared, the two instrument panels lose more and more distinctiveness. Of course, if every part were common, the two panels would be indistinguishable.

The trade-off between distinctiveness and commonality is represented in Figure 1. Two products that are very distinctive and share few parts correspond to scenario A; two products that are less distinctive and share many parts correspond to scenario B. For a given product architecture, product designers face a trade-off between distinctiveness and commonality. Conceptually, this trade-off can be thought of as constraining the distinctiveness and commonality of a pair of products to fall along the curve, architecture 1.

3. Product architecture dictates the nature of the trade-off between distinctiveness and commonality. Although a trade-off exists between distinctiveness and commonality, the nature of the trade-off can be influenced by changing the product architecture. The curve, architecture 2 in the figure, results in a tradeoff in which slight efforts at commonality mean drastic reductions in distinctiveness (scenario C). It is also possible, as illustrated by architecture 2, that even with no parts in common, two products may not be viewed as completely distinct. In the ideal case, the product architecture presents the company with a trade-off in which a relatively high level of commonality can be achieved without much sacrifice in distinctiveness, and distinctiveness declines slowly as commonality is increased. This situation is represented by architecture 3 and scenario D.

For example, consider the two different instrument panel designs shown in Figure 2. One architecture consists of a tubular metal structure over which a contoured plastic skin is assembled; the other consists of a curved plastic panel with metal reinforcements integrally molded as part of the structure. The first designs are called modular; the second, integral.11 In the first case, the underlying metal structure can be common across instrument panels A and B, while the plastic skin can be different. This commonality results in relatively little loss of distinctiveness. In the second case, an attempt to standardize one of the integral metal-plastic panels leaves the two vehicles with similar exterior appearances for the dashboard, a large decrease in distinctiveness.

Another type of architecture that is important to consider in platform planning is the production architecture. The production architecture defines the range of products that can be produced. For example, if the different models of a new platform of cars are to be assembled and painted on the same production line, then the structure of the production line will determine the range of possible heights and widths, the allowable sizes of the different systems in the car (e.g., how big or small the dashboard, seats, and other systems can be), and the assembly sequence of the car. This production architecture is not a fixed constraint, but the cost of revising it may be significant.

The Platform-Planning Process

Platform planning is a cross-functional activity involving at least the firm’s product marketing, design, and manufacturing functions. In most cases, platform planning is best carried out by a core team of representatives from each function. For large development projects, each representative should in turn be supported by an experienced staff.

We advocate a loosely structured process for platform planning focused on three information management tools (see Figure 3):

  • The product plan
  • The differentiation plan
  • The commonality plan

The three plans are top-level summaries of deeper analyses by members of the extended platform planning team, but they explicitly display the degree to which coherence has been achieved among product strategy, market positioning, and product design. The goal of the platform planning process is to achieve coherence among the three plans. The process of platform planning is likely to be iterative. The team begins by constructing the three plans and then works iteratively to achieve coherence among them.

Establish Product Plan

The product plan for the collection of products encompassed by the platform specifies the distinct market offerings over time and usually comes from the company’s overall product plan. In a product plan for a new platform for a sporty coupe, a family sedan, and a family station wagon, the two axes of the chart correspond to the segments of the marketplace and to time (see Figure 4). The timing and segment of each planned product are indicated by location. The genealogy of the products is indicated by links.

The product plan is supported by a top-level description of each product. This description contains the customer profile (needs, psychographics, and demographics) and a basic business plan (expected sales volumes and selling price range). The product plan indicates major models but does not show every variant and option.

The product plan is linked to several other issues and pieces of information:

  • Availability of development resources
  • Life cycles of current products
  • Expected life cycles of competitive offerings
  • Timing of major production system changes
  • Availability of product technologies

The product plan reflects the company’s product strategy. Some companies choose to issue several products simultaneously; others choose to launch products in succession.

Specify Each Product’s Differentiating Attributes

DAs are the dimensions of the product that are meaningful to customers. The differentiation plan indicates the target values of the DAs for each product in the plan (see Table 1). The first column of the table shows the values of the DAs; the second and third columns show the critical DAs for each product in the product plan; and the fourth column gives an approximate assessment of the relative importance to the customer of each DA. A common pitfall in platform planning is to become bogged down in detail. We generally find that the best level of abstraction for platform planning results in no more than ten to twenty DAs. In the beginning of the process, these DAs focus on the overall properties of the product. As the planning process evolves, the work shifts to the system level, and the DAs become increasingly detailed.

On the first pass, the differentiation plan represents the ideal case of each product’s differentiation for maximum appeal to customers in the target segments. On subsequent iterations, the ideal case is adjusted to respond to the need for commonality.

The values of the DAs for competing products serve as a useful benchmark for differentiation and can be entered in additional columns of the matrix. However, the team must avoid a focus on existing competing products at the expense of anticipating the future market.

Objective metrics are particularly useful for representing the target values of the DAs when such metrics are widely accepted as meaningful in the marketplace (e.g., miles per gallon for automobiles). When such metrics are not available, direct comparisons may be useful (for example, “similar to a Lexus ES300”).

Quantify Commonality across Products

The commonality plan describes the extent to which the products in the plan share physical elements. The plan is an explicit accounting of the costs associated with developing and producing each product (see Table 2). The first column of the table lists the critical chunks in the product. To manage complexity, the team should limit the number of chunks to roughly the number of DAs — no more than ten or twenty. The remaining columns identify the products in the plan, according to the timing of their development, and the four metrics used in the commonality plan.

For example, consider the first row of the commonality plan in the table, the HVAC system. The sporty coupe requires forty-five unique parts, $4 million in development cost, and $9 million in tooling cost; it has a unit manufacturing cost of $202. To then produce the HVAC system for the sedan and wagon requires an additional thirty-five unique parts, $3.8 million in development cost, and $7.5 million in tooling cost. The unit manufacturing cost of the HVAC system for the sedan and wagon is $200.

For different product contexts, the relative importance of these metrics may vary. For example, in some settings, tooling cost may be insignificant and may be dropped from the plan. In other settings, other metrics may be important. For example, development time may be the most important metric for a product because of the potential loss of market share for being late to market. In this case, a time metric could be added to the commonality plan.

The values of these metrics are estimated because actual values cannot be determined until the products have been designed and produced. Note that, with the exception of unit manufacturing cost, the values in the commonality plan are incremental, assuming the preceding products are developed and produced. If the sequence of products in the product plan changes, the incremental values may also change. The commonality plan in the example considers the incremental parts and costs associated with producing the sedan and station wagon after the sporty coupe.

Underlying the commonality plan are the basic engineering design concepts for the product. In most cases, engineering layouts of each product are created to support the estimation process. Once the values of the metrics are estimated, the total values for each product and for each chunk can be added.

Iteratively Refine the Plans

Given the objective of maximizing market presence, a company would most likely want to enter many segments with many products and replace them all regularly. Given the objective of capturing a large fraction of each segment, the company would attempt to ideally position the product with respect to the values of the DAs. Given the objective of minimizing development cost, tooling investment, and complexity, a large fraction of all the products in the plan would be identical. Typically, of course, these three objectives conflict. For most product contexts, an unconstrained product plan and an unconstrained differentiation plan lead to high costs. For this reason, iterative problem solving is required to balance the need for differentiation with the need for commonality. After completing the commonality plan, the team may return to the differentiation plan and modify the target level of differentiation on DAs that are particularly critical drivers of product costs. After reviewing the costs of effectively differentiating a product for a particular segment, the team may decide that it is simply infeasible to consider that product part of the platform.

Conceptually, this iterative activity involves both moving along the distinctiveness-commonality curve and exploring alternative product architectures with different associated trade-off characteristics (see Figure 1). Several practices can help companies achieve coherence across the three plans:

1. Focus on a few critical DAs and chunks.

The relationship between the DAs and the chunks can be shown on a matrix (see Figure 5). The first column shows the DAs, and the column heads going across the matrix show the chunks. A cell of the matrix is filled when the DA and the chunk associated with that cell are interrelated (i.e., when variation in the DA is likely to require variation in the chunk). Because the exact relationships between chunks and DAs depends on the final product architecture, the matrix is approximate and representative of the team’s best estimates.

The matrix is most useful when the DAs are arranged in order of decreasing value of variation to the customer and when the chunks are arranged in order of the decreasing cost of variation. When organized this way, the DAs and chunks in the upper-left portion of the matrix whose corresponding cells are filled have special significance. These are the important DAs and costly chunks that are interrelated. These elements are the critical few on which platform planning is focused.

The chunks that are not related to important DAs should be rigorously standardized and incorporated into the platform. Variation in these chunks does not offer value in the marketplace. Furthermore, the valuable DAs that are not related to costly chunks can be varied arbitrarily without incurring high cost and so should be varied directly in accordance with market demands.

2. Search for architectural solutions to apparent conflicts.

In our example, the initial architecture of the instrument panel involved reusing only a few HVAC components, gauges, switches, wiring, brackets, fasteners, and other components. The initial commonality plan (see Table 2) shows that the development and tooling costs for the sedan or wagon would be $5.2 million less than for the coupe, reflecting savings from commonality in the initial design approach. However, the engineering team set out to develop an alternative architecture that would allow for greater reuse of components.

The first area that the team examined was the most expensive: the HVAC system. Team members realized that by designing the duct system using a modular architecture, they could reuse many HVAC components. They designed a system in which the ends of the ducts varied across models, while the main ducts and the mixing box that connects them could be reused (see Figure 6). They also realized that with some careful packaging, they could reuse the support structure for the entire instrument panel. The changes resulted in additional savings of $10.4 million in development and tooling costs (see Table 3).

The second area they examined was the cross-car beam. They found that, even though the coupe’s instrument panel was narrower than the others on the platform, they could standardize the attachment points of the dashboard cover and structure and reuse most of the cross-car beam components. The only change that was required was a main beam that was six centimeters shorter. This resulted in another $3.8 million of development and tooling savings (see Table 3).

Finally, the team examined the electrical equipment and steering system. Team members found that while the airbag itself had to be tuned differently for the different models, they could reuse the housing, sensors, and control module. They could also reuse the expensive combination switch (which controls the turn signal, wiper washer, and headlight switches) if the dashboard cover was styled correctly and if different covers were used for the switch arms. Between the electrical equipment and steering system, these actions saved an additional $4.7 million over the initial plan.

In addition to savings in fixed costs, the variable costs of producing components also fell because the volume of the components increased. Suppliers offered an average 5 percent price discount in return for standardizing components. The discount resulted in an annual savings of $9 million.

The team could have achieved further savings by using a common dashboard cover. However, the dashboard cover is absolutely critical in differentiating the two products. Therefore, the team chose to sacrifice commonality, even at substantial cost, because of the market value of the resulting distinctiveness.

3. Express costs and benefits in terms of profits.

To keep the problem-solving discussions productive, the team should use a common language. The best approach is to focus on the impact of choices on platform profitability. The group iteratively refining the differentiation plan must focus on the impact of decisions on market share and link share points to profitability. The group refining the product architecture should link product costs to profitability. Only when both groups are working from the same profitability model can they discuss constructively the bottom-line tradeoffs between commonality and distinctiveness.

In an ideal world, a company wants to explicitly optimize the platform to achieve maximum profits. While some current research efforts are directed at this objective, explicit profit maximization is hard for at least three reasons.12 First, data are scarce, especially data related to the value of a particular DA. Second, decom-posing the value of a product into the value of individual DAs is difficult. Third, much of the problem-solving activity in platform planning involves creative design problem solving on the choice of product architecture, for which there are no structured optimization techniques. For this reason, our underlying assumptions are that a correct answer is unlikely, that providing a clear way of displaying information helps, and that the team should work for a solution that is good enough. The key to making the process a success is to avoid “analysis paralysis”; the goal is to obtain data that support quick, creative problem-solving iterations.

4. Become as sophisticated as possible in describing DAs.

The ability to describe DAs well is vital to platform planning. Understanding how customers view products and what distinguishes one product from the next is a difficult task. By describing DAs clearly and in detail, teams can better understand the linkage to the chunks of a product. Developing an understanding of DAs that are holistic (i.e., that arise from the entire product as a system) is especially critical.13

A good example of careful DA definition comes from Lotus Engineering.14 To describe the handling characteristics of its cars, Lotus uses sophisticated and vivid terms. These terms help Lotus better connect a car’s handling characteristics to the components that determine them. For example, among Lotus’s attributes are:

  • Umbrella — the feeling that a car is descending after coming over the crest of a hill. A car has motions that make a driver feel that it is flying off the road and motions that bring it closer to the road; a car with good umbrella will have twice as many motions closer to the road than motions off the road.
  • Nibbling — the series of quick back-and-forth movements that happen when a car goes over a series of bumps.
  • Standing up — the feeling that the rear end of the vehicle is rising. The back end of a car that stands up feels like it rises more than it falls as it goes over bumps and hills.

These DAs allow the different groups at Lotus to better understand what to differentiate and how. By describing carefully how the attributes should be different, the team can more exactly determine specifications for the chunks of a car.

Managing Platform Planning

Top management should play a strong role in the platform planning process for three reasons: (1) platform decisions are among the most important a company makes, (2) platform decisions may cut across several product lines or divisional boundaries, and (3) platform decisions frequently require the resolution of cross-functional conflict.

Platform planning determines the products that a company introduces into the market during the next five to ten years or beyond, the types and levels of capital investment, and the R&D agendas for both the company and its suppliers. Because of the impact of platform decisions, they warrant significant top-management involvement.

Top management’s participation is also needed because making good platform decisions requires making complex trade-offs in different business areas. For example, making an instrument panel slightly less stylish could hurt the appeal to certain target segments, yet improve commonality and manufacturability. Or a product plan that requires spinning five products off a common platform may turn out to be unrealistic and have to be revised.

Different functions within the firm have different perspectives during product development. Some functions, such as sales, market research, marketing, and styling, concentrate on those product characteristics that the customer experiences while using the product. Other functions, such as engineering, production, and after-sales service, may be more focused on the product cost. When designing a new platform, the functions that focus on the customer features of the product are often in conflict with groups that care about the parts and production processes. Top managers should recognize that the various functions may fundamentally disagree about the goals of the platform and that their perspective may be required to achieve the best solutions.

When organizing a platform-planning project, top managers should:

  • Put someone in charge of each plan (the product plan, the differentiation plan, and the commonality plan) and someone else in charge of driving the whole process.
  • Make sure that all key functions are involved — engineering, market research, manufacturing engineering, industrial design, and so on.
  • Set up two support teams. One team estimates the value of differentiation or the cost of a lack of differentiation. The other team estimates the costs associated with a given level of commonality.
  • Spend time building a high-performing team. The planning process is difficult, involving many different functions that are not accustomed to working together. Time spent during the early phases clarifying objectives, building consensus, and creating a true team can pay off handsomely during the later phases of the process.
  • Set targets for the total cost of the platform, based on past performance or on benchmarked results. These cost targets will help prevent the activity from resulting in too little commonality.

Once the project is organized, top management should:

  • Help everyone understand that, while there is a trade-off between commonality and variety, it is not a zero-sum game. All functions may take a while to learn that choosing the right architecture can do much to balance commonality and distinctiveness. Working together can help improve the platform products from everyone’s perspective.
  • Drive for quick, approximate results, not for slow, perfect answers. Challenge the company to experiment quickly with different architectures, evaluating them on the basis of their ability to achieve commonality and distinctiveness. The secret to platform planning is not deep, detailed analysis, but fast, creative problem solving.
  • Push for facts, not someone’s “gut feel.” Management should ask for and receive the best possible data on customer needs, size of segments, and cost of differentiation before making decisions. This is not to suggest that analyses should be detailed, bullet-proof research papers. Rather, the analyses, however approximate, should be based on the best facts available, not on personal hunches.
  • Don’t insist on total agreement and perfect resolution of all issues; ask for design solutions that everyone agrees are good enough on all dimensions and very good relative to the few critical competitive dimensions.
  • Start at the top level of the product and then iteratively refine the plan in greater and greater detail. For example, in developing a new car, platform planning would first be directed at the overall vehicle and the twenty or so top-level chunks. Then planning would be directed at each chunk and its constitutive components.
  • Make the process a living one. The way in which platform planning is implemented is (and should be) different in every company. One key to successful platform planning is continuing evaluation and improvement of the process. A static, regulated implementation of the planning process is doomed to fail.
  • Evolve the planning process into the next phase. As planning nears completion, more and more members of the team that will execute the next phase of the project should be involved to ensure they understand and agree with the major decisions already made.
  • Use the results to drive the improvement agenda for the company. What should research work on? Where does production need to be more flexible? What are other customer segments? What dimensions of the product do the customers really care about? How can the product technology be made more robust so that it can be used in many platforms?

Conclusion

In many industries, the standard for minimum acceptable product development performance is high and rising fast. It is no longer possible to dominate large markets by developing one product at a time. Increasingly, good product development means good platform development.

To develop good platforms, a company must carefully align its product plan, its differentiation plan, and its commonality plan through an iterative planning process. No longer can the product planning group throw its plan over the wall to other groups; planning must be a cooperative process involving all groups and guided by top management. Just as good product engineering involves up-front consideration of manufacturing issues, good platform planning requires up-front consideration of marketing, design, and manufacturing issues.

Much academic and industrial attention has been concentrated on product strategy and on product development and project execution. Little emphasis, however, has been placed on coordinating the development of the set of products that realize a product plan. Platform planning fills that gap. Yet platform planning is difficult: teams may achieve high commonality but fail to differentiate the products; teams may differentiate the products but create products with excessive costs; or teams may create viable platform plans that are subsequently never realized.

The planning tools in this article provide a common language that a company’s marketing, design, and manufacturing functions can all understand. The platform-planning process we present gives them a method for applying these tools that captures all critical elements of the process and achieves coherence among the product, differentiation, and commonality plans.

Topics

References

1. K.B. Clark and S. Wheelwright, Leading Product Development (New York: Free Press, 1996).

2. K. Nobeoka and M.A. Cusumano, “Multiproject Strategy and Sales Growth: The Benefits of Rapid Design Transfer in New Product Development,”

Strategic Management Journal, volume 18, March 1997, pp. 169–186; and

K. Nobeoka and M.A. Cusumano, “Multiproject Strategy, Design Transfer, and Project Performance: A Survey of Automobile Development Projects in the U.S. and Japan,” IEEE Transactions on Engineering Management, volume 42, November 1995, pp. 397–409.

3. B.J. Pine II, Mass Customization: The New Frontier in Business Competition (Boston: Harvard Business School Press, 1993);

B.J.Pine II, B. Victor, and A.C. Boynton, “Making Mass Customization Work,” Harvard Business Review, volume 71, September–October 1993, pp. 108–111; and

E. Feitzinger and H.L. Lee, “Mass Customization at Hewlett-Packard: The Power of Postponement,” Harvard Business Review, volume 75, January–February 1997, pp. 116–121.

4. For an interesting discussion of the strategic role of knowledge platforms, see:

D.J. Kim and B. Kogut, “Technological Platforms and Diversification,” Organization Science, volume 7, May–June 1996, pp. 283–301.

5. M.L. Fisher, K. Ramdas, and K. Ulrich, “Component Sharing: A Study of Automotive Brakes” (Philadelphia, Pennsylvania: University of Pennsylvania, The Wharton School, Department of Operations and Information Management, working paper, 1996).

6. For an example of the magnitude of these costs, see:

K. Ulrich, D. Sartorius, S. Pearson, and M. Jakiela, “Including the Value of Time in Design for Manufacturing Decision Making,” Management Science, volume 39, April 1993, pp. 429–447.

7. “Will Success Spoil General Motors?,” Fortune, 22 August 1983.

8. K.B. Clark and T. Fujimoto, “The Power of Product Integrity,” Harvard Business Review, volume 68, November–December 1990, pp. 107–118.

9. K. Lancaster, “The Economics of Product Variety,” Marketing Science, volume 9, number 3, Summer 1990, pp. 189–206.

10. This usage is increasingly common in industrial practice and is consistent with that used in:

K. Ulrich and S. Eppinger, Product Design and Development (New York: McGraw-Hill, 1995).

11. K. Ulrich, “The Role of Product Architecture in the Manufacturing Firm,” Research Policy, volume 24, May 1995, pp. 419–440.

12. V. Krishnan, R. Singh, and D. Tirupati, “A Model-Based Approach for Planning and Developing a Family of Technology-Based Products” (Austin: University of Texas, Austin, working paper, April 1998).

13. K. Ulrich and D. Ellison, “Customer Requirements and the Design-Select Decision” (Philadelphia: University of Pennsylvania, The Wharton School, Department of Operations and Information Management, working paper, 1997).

14. H. Lees, “Word Perfect: How Do You Accurately Describe What a Car Feels Like to Drive?,” Car Design & Technology, August 1992, pp. 54–57.

Acknowledgments

We would like to thank Per-Ola Karlsson, Glenn Mercer, Jeff Sinclair, and Karl Swartling from McKinsey & Company for their contributions and the many McKinsey clients who helped develop the ideas in this article.

Reprint #:

3942

More Like This

Add a comment

You must to post a comment.

First time here? Sign up for a free account: Comment on articles and get access to many more articles.