The McKinsey Quarterly

  • Recommend (4)
  • Text Size
  • Print
  • Download PDF
  • Link to This

The future of product development

By focusing on better information management rather than processes, companies can dramatically boost their product-development performance.

Product development is facing a fundamental challenge. Most companies are under pressure to bring new products to market more and more quickly, and companies in many sectors must work harder to ensure that they address the needs of ever-narrower customer segments. These pressures are particularly acute in fast-paced markets, such as those for high-tech, medical, and consumer goods, and in competitive markets for complex products that require large investments and long development times, such as automobiles and airplanes. CEOs wonder how their product-development organizations can meet the new challenges.

Unfortunately, at the very moment when companies need to make better products more efficiently, previous performance innovations in product development have hit a plateau. Over the past 15 years, most companies have adopted standard product-development processes, with disciplined time lines, strict design reviews, "gates" to decision making, and cross-functional development teams. While these changes have made the devel-opment of new products much more efficient, further improvements are returning smaller gains. What is needed now is a way of raising product development to a new level.

Some companies have done exactly that: they have reduced the time needed to launch new products while dramatically raising their sales of new products and their market share (Exhibit 1). The key to the new approach is an entirely different way of making product-development decisions. By improving the quality, timing, and synthesis of product and process information throughout the development cycle, such companies have turned a linear, sequential process into a flexible one that reacts to information continually rather than at intervals and in batches. They keep their product options open longer than most of their rivals and can act on new information about customers, markets, suppliers, and production capabilities later in the development process. Decisions are made when all options have been understood fully, not at rigidly scheduled meetings that open the gate to the next stage. As a result, such companies make better decisions at each step and therefore reduce the bottlenecks, information gaps, rework cycles, and wasted effort that can add so much time and expense to the development of new products. They create more successful products more effectively, in less time and with fewer resources.

Chart: Better, faster, cheaper

The new approach does have its challenges. Without skilled leadership and some new organizational capabilities, companies may lose control of a disciplined process that has improved their performance significantly. They will have to manage their resources more flexibly and monitor their teams' ability to generate the right information and to use it effectively. Yet for many companies, the opportunity to change products significantly later in the development cycle while also developing better ones more quickly is just too compelling to pass up.

The information-driven approach

Product development must now be changed in ways resembling the lean-manufacturing techniques that transformed mass production

The changes currently required in product development resemble the lean-manufacturing techniques that have transformed mass-production lines. Besides optimizing the efficiency of each station on the factory floor, lean procedures create a flexible, efficient work flow intended to meet customer demand just in time. To minimize waste and inventory and to optimize the efficiency of the line, parts are fed into the process as they are needed.

By contrast, the current approach to developing new products resembles the traditional mass-production line: companies follow a fixed sequence of steps, moving from market research to product concept, design specification, prototype testing, and so on. Like a production line, this process can be improved significantly by ensuring a continual flow of work. To achieve the next step change in performance, companies must therefore improve the efficiency of the entire process, from generating ideas to launching products. Adopting lean techniques has helped companies increase their manufacturing efficiency by 30 percent or more. We believe they can get a similar boost in the performance of their product-development teams by adopting an information-based approach. In our experience, during a typical development cycle as much as one-third of the time is spent doing unnecessary work or waiting for decisions or information.1 By managing information flows rather than only process steps, companies can eliminate these sources of wasted time.

In practice, the new approach requires some fundamental changes in product development (Exhibit 2). Rather than rigidly adhering to a standard sequence of activities, the work of teams developing new products is organized to ensure a continual flow of high-quality information into the development process. Companies solve problems and synthesize new information continually instead of merely collecting bits of information from various functions and compiling the results just before gate meetings. By using a more flexible, information-driven methodology, teams reach better solutions more quickly.

Chart: A better way to develop products
Organize around information flows

The first step for any team developing a new product is to determine which attributes are critical to its success. In the information-based approach, the team goes a step further by identifying the information required to make each key decision along the way. Companies then reconfigure the development process around these needs, ensuring that the right information is gathered at the right time and then flows to the right people.

In this way, the sequence and concurrency of specific tasks vary for each new-product team. If costs, say, are critical, the product team defines a work flow built around determining and meeting cost targets instead of allowing costs to be an uncontrolled output. As a result, the development process may change: key suppliers and operations managers might, for example, produce cost estimates for design features at an unusually early stage rather than try to minimize costs only after the development team had decided on a concept.

Each task is always optimized to promote the end goal, not the efficiency of the task itself. Consider, for example, the testing of prototypes. Under the old approach, the prototype team tries to make the most representative model of the product. To do so, however, the team needs detailed product specifications, which are available only late in the development cycle, and a lot of time to construct the model. In the information-based approach, the first step is to decide which information gaps must be filled during the testing of the prototype and when that information will be most useful. Sometimes an earlier, simpler model might yield it without additional work—thereby eliminating one source of delays.

Organizing product development in this way might seem simple and even obvious, but it is a radical departure from what most companies do today. Consider the experience of a global company that makes medical devices. Under its old process, teams focused mostly on defining the features and functions of new products. Market research was secondary, and no input from operations people and suppliers was sought until prototypes had been built. The cost and reliability of the products were outcomes of the chosen design though not key considerations during its creation. Subteams only loosely coordinated their development activities, and six months or even more were needed merely to settle on a concept for a new product and to choose its features.

A team participating in a project using the information-based approach started by creating three simultaneous work flows: one for the needs of customers and the design features of the product, a second for its cost, and a third for its reliability (Exhibit 3). The three subteams communicated daily and assessed all of their findings every week. By organizing around the flow of information, the team looked at market research through a new lens and made an important discovery: customers care most about the cost and reliability of products, not their throughput performance and other advanced features, as the team had previously assumed.

Chart: A medical-equipment company transforms its product-development process

Still more important, the new approach inspired the team to react to this new information in a new way. Customer service and operations were consulted early on to analyze what had made previous models break down and to estimate the trade-offs between design features and costs. Instead of having the marketing department undertake the research and throw the results "over the wall" to R&D, the product team and the marketing department conferred frequently. They could therefore quickly tweak the design of the product and then determine the implications for its cost and reliability as well as the reactions of potential customers. In this way, the team settled on the product's concept and features in two months instead of the six previously needed. In the end, it designed a new machine that cost 20 percent less to manufacture than previous models, took 40 percent less time to develop, and had 50 percent fewer breakdowns. Since launch, the company has nearly doubled its market share in that product category.

Solve problems continually and share the results

Instead of using a linear approach to collect information, make a decision, and then base other decisions on the first one, information-based teams solve problems continually and combine their findings frequently. Like the medical-device company's team, they work in a way that allows them to converge on the best solution. This style of work resembles the "daily-build" method many software companies use: the code produced by individual programmers is compiled every day so that project leaders can test it for bugs and functions. Problems are reported immediately, and the team knows, on a daily basis, how close it is to its ultimate goal.

By gaining the ability to delay the point when product designs must be "frozen," information-based teams keep their options open longer and can respond to changes in the market at later stages of the development process. Senior management imposes fewer constraints on these teams than on their conventional counterparts, so they can consider a broader set of solutions; concepts may take longer to develop, but the company saves time later on. Toyota Motor, which uses some aspects of the information-based approach, routinely develops new car models in at least 20 percent less time and with 30 percent fewer resources than its competitors, even though it evaluates more design alternatives and keeps its options open longer.2 The reason is that its developers understand design trade-offs better than conventional developers do, avoid costly rework, and respond more quickly to problems arising later in the process. Moreover, by amassing deeper knowledge about any one project, Toyota's teams can often develop other, related products more quickly.

Effective teams that can solve problems, synthesize findings, and orchestrate information flows are vital to the new process. Subteams meet daily to review their progress and to ensure that new results are fed immediately to different branches of the team and, where necessary, to the broader business. Team leaders bring together people with the right mix of skills to solve problems as soon as they arise and eliminate barriers to progress. Meetings with senior executives are used not to make routine decisions but to review the progress of development projects and to discuss product strategy. Teams can slow down or speed up their work as needed and adjust the process in midstream as new information becomes available. Companies using the new approach sometimes appoint senior managers from marketing, R&D, and operations to lead cross-functional teams in hopes of getting the three key disciplines to work together from the start. Typically, one of them is first among equals and ultimately leads the project.

Product development based on this approach is relatively flexible but doesn't want for discipline. Companies set their performance targets and conduct management-review meetings, much as they do in the conventional process. The difference is that they reach decision gates when criteria are met, not when a given amount of time has passed; a product concept might, for example, be made final when certain technical functions have been validated and the product's cost falls within a particular range. Project leaders may estimate in advance how long it might take to realize these goals, but since the team strives to do so as quickly as possible, waiting time and the information gaps created by premature decisions are eliminated (Exhibit 4). The result is better decision making, more efficient development cycles, and fresher products that better fit the market's needs.

Chart: Just-in-time decision making
The challenge

Moving from today's less flexible, process-oriented approach to a dynamic and flexible one demands new organizational capabilities and skills. Without the right project leaders, the ability to allocate resources as needed, and new ways of measuring the performance of project teams, companies won't capture the potential efficiency improvements of the new approach and, worse, may find that it lacks discipline and forfeits many of the past decade's gains. Several companies have found ways of combining the two approaches. They have learned a few lessons along the way.

Let leaders lead

Strong project leaders—the key to any good product-development organization—are even more important in the information-based approach. In conventional product development, process discipline keeps the organization in check and thus limits a good manager's ability to make the process more efficient and effective, though it also controls the potential negative impact of a poor project manager. With the new approach, project leaders drive performance by focusing on the highest-value activities, skipping unnecessary ones, and shaping the team and the work flow in response to new information. Successful project leaders must therefore be both inspired people managers and skilled problem solvers. They must bring the right individuals and information together to develop the best solutions for problems, coach subteams to perform at a higher level, and have a working knowledge of all areas of their projects, including the technical side, marketing, operations, and supply chain management. Above all, senior executives must trust these leaders to make sound, fact-based decisions about the direction of their projects without always seeking input from above.

Do such people exist? The good news is that they do, but only the very best project leaders can now perform at this level. In our experience, the potential of the best leaders is stifled by the current inflexible approach. Giving them enough flexibility and authority to make decisions will unleash their potential and raise the performance of their teams a few notches. Meanwhile, most project managers will have to upgrade some combination of their leadership ability, their problem-solving skills, or their cross-functional expertise—hardly surprising, since many of them are engineers promoted to management without training or even, in some cases, natural aptitude. Organizations now have the task of creating processes to spot project leaders with strong potential and to develop their skills.

To address the shortage of project leaders, one high-tech company with sales of more than $4 billion identified the 20 most promising ones it had and then put them through a training workshop (later rolled out to all project managers) on problem solving, coaching techniques, and leadership skills. The company also created an apprenticeship program. Average project managers became deputies to one of the top leaders for a year; after active mentoring and on-the-job training, they were sent back to manage new teams on their own. Unusually, the company also offered large bonuses to project leaders and team members if their products met or exceeded specific targets, such as a certain level of sales after six months.

Allocate resources dynamically

The ability to allocate resources flexibly to each new-product team is vital as well. Indeed, flexibility is the key to information-based product development: the testing of prototypes might take place sooner than planned, for example, or certain developers might be needed longer. To accommodate the uncertainty, it is necessary to be able to allocate resources dynamically.

Product-development units must hire or train staff members who can wear more than one hat

The first step is to organize product development around project or product teams, not functional areas. New-product teams that have to beg resources from functional "silos" inevitably lack the required flexibility and focus. Second, most product-development organizations will find that they need to hire or train staff members capable of wearing more than one hat at a time—for instance, developers who can play a variety of design roles, engineers who have training in several disciplines and can undertake both series and advanced engineering, and operations people who know how to build prototypes and manage suppliers. In general, the most valuable employees have experience in several technical functions as well as some business training.

Finally, companies must build up their reserves for dealing with unexpected demands. They can do so by making sure that some key multitalented employees are always at work on projects with flexible time constraints (such as long-term ones) so that these people can be moved to higher-priority projects in emergencies. (The same applies to market-research, prototype-testing, and operations units.) Companies can also create outsourcing options for part of their development efforts (such as market research) or rank projects in order of priority and identify those that can surrender resources when necessary. We have found that the productivity gains generated by the information-based approach free up resources, thereby making it easier to create reserves and develop multitalented employees. Like a lean-manufacturing environment, in which multitalented workers are the key, this approach improves employee morale.

Measure performance

Most companies track the costs of their projects, their ability to complete projects on time, and the resulting sales to judge how good they are at developing new products. Companies that take the information-based approach also need metrics for the quality of the information they gather and the efficiency with which they process it. In short, teams must be sure they are gathering the best information possible and spending the right amount of time analyzing it.

Just as wastage is a key metric in lean manufacturing, information wastage is important in gauging the efficiency of information-driven product development. This metric should show the amount of time development teams waste—for example, by undertaking unsuccessful projects, waiting for information, doing avoidable rework, or taking extra time to ramp up production to the specified quality and scale.

Measuring the quality of information processing is equally important. How, for example, did initial market forecasts or cost estimates compare with actual results? Did information gaps become apparent during the process and, if so, why? Were customer complaints fully addressed while the concept was under development and, if not, why not?

For the past couple of decades, product developers have improved their performance largely by making the process more disciplined and rigorous. Such improvements can no longer satisfy the increasing demand for better products launched more frequently and aimed at ever-narrower customer segments. Companies must now turn their attention to building a more nimble and flexible product-development organization. To do so, they will have to focus on information flows within the development team, coordinate the efforts of dozens of subteams more successfully, learn to solve problems and synthesize results on an ongoing basis, and give more decision-making authority to project leaders. Those companies that meet the challenge will have an undeniable edge over their competitors because they will succeed not only in responding to customer and market changes right up to a fairly late stage in the process but also in bringing their products to market more quickly and efficiently.

About the Authors

Rick Holman is a consultant in McKinsey's New Jersey office; Hans-Werner Kaas is a principal in the Detroit office; David Keeling is a principal in the Chicago office.

Notes

1These figures are consistent with research reported in Colin Mynott, Lean Product Development, Northampton (Great Britain): Westfield Publishing, 2000. Mynott indicates that in one study, 25 percent of the team's time was spent on value-adding necessary work (doing the right things correctly at the right time), 10 percent on necessary work that didn't add value (such as traveling and writing reports), 30 percent on rework (fixing errors and redesigning products), 25 percent on activities other than work (vacations and waiting), and 10 percent on unneeded work (attending meetings and writing reports that no one read).

2For more on Toyota's "set-based" design approach, see Durward K. Sobek II, Allen C. Ward, and Jeffrey K. Liker, "Toyota's principles of set-based concurrent engineering," MIT Sloan Management Review, Winter 1999, Volume 40, Number 2, pp. 67–83.

Recommend (4)
Comments
Submit Your Comments

The user information you enter into this form will not update your site profile. To update your profile, please visit your profile page.

Subject The future of product development

*Required

We may publish your comments online and in the print edition of McKinsey Quarterly. Those chosen, which may be edited for length and clarity, will appear along with your name and details, but not your e-mail address. We will use your e-mail address only to send you a confirmation copy of your comments and to notify you if we publish them online.

We value your feedback and will consider it carefully. Nonetheless, we receive so many comments that we cannot acknowledge all of them.

See also:
Preview

Embed E-mail