FEATURE ARTICLE

Do You Need a New Product-Development Strategy?

Aligning Process With Context
There is no one-size-ts-all product-development process; designing new products for different business contexts requires different new-product development processes.
Alan MacCormack, William Crandall, Paul Henderson, and Peter Toft

OVERVIEW: Many rms rely on a single new-product development process for all projects. But designing new products for different business contexts requires that a rm deploy different new-product development processes. Products designed for stable and mature end-user markets require a process optimized for control and efciency. In contrast, rst-of-a-kind breakthrough products require a more emergent process that aims to discover whether there is any market to be served in the rst place. Applying a uniform best-practice process to all development efforts ignores the major differences between these projects and may result in missed opportunities. This article describes a framework to address this problem, allowing a rm to better align the design of its development processes to the specic aims of individual projects. We illustrate this framework with examples from Hewlett-Packard, a large, diversied electronics rm that has successfully piloted this new approach across multiple business units. KEYWORDS: Product development, Process design, Stage-Gate processes, Agile development processes

Over the past decade, rms have invested millions of dollars to dene and standardize the way they bring new products and services to market. Despite these investments, however, studies of new product success rates have shown little or no improvement (Grifn 1997; Adams and Boike 2004). Indeed, recent data suggest that rms

struggle more than ever to develop and launch new products on time with acceptable features, cost, and quality (Christensen 1997). And remarkably, some of these rms blame the very processes designed to help. So what went wrong? Often, rms fail to align product-development strategy to business needs.

Alan MacCormack is the MBA Class of 1949 Adjunct Professor of Business Administration at Harvard Business School. His research examines the management of innovation and product development in high-technology industries, with a particular focus on software. Alans research has been published in a variety of leading journals, including Management Science, Research Policy, and Harvard Business Review. In addition, he has written over 50 cases and notes that explore how organizations like Intel, Microsoft, and NASA manage product and service innovation. Alan holds a DBA from Harvard University, an MSc from MIT, and a BSc from the University of Bath. amaccormack@hbs.edu Bill Crandall is principal of Clarify LLC, a business advisory rm that works with leaders in transition in situations that need quick but comprehensive strategy development tied to measurable execution plans. At Hewlett-Packard, Bill led HP Global Engineering Services, a $35 million, 200-person professional services business operating in 20 countries that generated $60 billion in revenue each year from 650 new-product introductions. Bill holds an AB from the Woodrow Wilson School at Princeton University. He received an MS in computer science and an MS in management from Massachusetts Institute of Technology where he was a Fellow in the MIT Leaders for Global Operations program. bill.crandall@ clarifyllc.com DOI: 10.5437/08956308X5501014

Paul Henderson is managing director of Clarify LLCs. Paul spent 20 years at Hewlett-Packard in a variety of management roles in product development and strategy. He has deep expertise in intellectual property, new business creation, business model innovation, and competitive positioning. Paul was named one of the worlds top IP strategists by Intellectual Asset Management magazine in 2011. Paul is also a teacher of special programs at the University of California, Berkeley, Haas School of Business, teaching leadership and strategy classes to MBA students. Paul holds an MBA from the Haas School of Business at UC Berkeley, an MBA from the Columbia Graduate School of Business, and a degree in chemical engineering from the University of Washington. paul.henderson@ clarifyllc.com Peter Toft is a program manager in Hewlett-Packards Cloud Services business, engineering HPs global-scale public cloud. Prior to this, he led HP Labs research on secure cloud computing infrastructure and managed the HP SE3D program, a cloud-based service for digital media production. Peter contributed to the concepts in this paper while working as a consultant in HP Global Engineering Services, working with diverse businesses across the company on product generation strategies and processes. Peter holds a BA in physics from Oxford University and an MSc in information engineering from Bristol University. peter.toft@hp.com

34 | Research-Technology Management JanuaryFebruary 2012

Different business contexts demand different productdevelopment processes; one size does not t all (MacCormack 2001; De Meyer, Loch, and Pich 2002). Consider the type of process needed to nurture a rapidly growing new-business venture aimed at developing a breakthrough technology in an emerging market. How well would this process work for a product aimed at a mature industry with at revenues and an established technology base? These different contexts place different demands on a development organization; the optimal process for each should differ. Yet all too often, senior managers are unaware of these distinctions and, as a result, end up using the wrong type of development process for the project at hand. The mistake is easily made. Many managers spend their entire careers using a single style of development and dont realize that multiple choices exist. Furthermore, many rms have standardized their processes, stripping managers of the freedom to select or design something better suited to the task (Cooper 1990). Seldom is there an explicit step in the business planning or product-development process that forces managers to consider the type of process to use. The default is typically what was done before, regardless of the differences between the current project and a rms past experiences. The results can be catastrophic. Rigid, inexible processes that require extensive planning and forecasting are applied to breakthrough projects where little is known up front. Conversely, exible, exploratory processes that emphasize creativity are applied to projects where tight control of costs and features is required. In either case, the nal product almost certainly doesnt meet market needs or rm goals. Tackling this problem requires that the rm craft a development strategy to t the context in which it competes and update development processes as this context evolves over time. One rmHewlett-Packard (HP)has succeeded in meeting these objectives by developing a framework that species several distinct styles of development and helps managers choose the one most suited to their business needs. HP has a large, heterogeneous business and product portfolio, introducing a signicant number of new products each year (over 500 from $3 billion in R&D investment in 2010). The companys businesses serve a broad range of customers, from consumers to enterprises; they include early-stage start-ups and divisions competing in mature or declining markets, and they span a broad range of technologies, from hardware to software to medical instruments and professional services. In short, HP competes in a variety of contexts, each of which places specic demands on its development organization, and the company has learned to adapt its development strategy to t these different contexts. Via an extensive series of interviews with HP managers and staff at different levels of the organization and across different business units, we sought to understand how the company had achieved this. We also beneted from the experience of several of the authors of this paper who worked at HP during the study period and participated in the design and implementation of the framework as part of an internal
Do You Need a New Product-Development Strategy?

consulting organization that supported the companys many business units. As a result, we had access to rsthand knowledge of the problems that led HP to develop this new framework, and we observed the challenges the company faced when implementing this approach across the rm. The Need for Different Product-Development Styles Industries tend to evolve in consistent patterns (Abernathy and Utterback 1978). Early in the life of an industry, there is tremendous uncertainty over the market needs that must be met and the choice of technical solution to meet these needs. This is a period of great variety, in terms of the offerings available to customers (Tushman and Anderson 1986). Furthermore, as it is not yet clear what attributes customers value or how much they are willing to pay for them, these offerings frequently focus on different dimensions of performance. As an industry matures, the uncertainty surrounding market needs declines and the basis of competition shifts. Rather than exploring new opportunities, the aim at this stage is to exploit existing ones (March 1991). The main dimensions of performance become clear and advantage shifts to those rms that can effectively execute projects to improve these features in each new generation. Paradoxically, the skills that serve a rm well early in the life of an industry creativity, exibility, and the ability to experiment rapidly with alternativescan be weaknesses later on, especially if those competencies are costly to maintain and deploy (Christensen 1997). This challenge is not related solely to the different stages of the industry lifecycle. Even within an industry, different projects present different challenges (Wheelwright and Clark 1992). For instance, the next face-lift for the Chevy Camaro faces a market that is well understood, customers who can be easily identied and surveyed, and technologies that are mature and predictable in their evolution. Building a fuel cellpowered vehicle that runs on hydrogen and emits water from its tailpipe, however, is a very different affair. Such a project requires fundamentally different capabilities and a knack for revisiting deep-rooted assumptions about how an automobile is dened. Why does this matter? Because in the search for universal development best practices, we seem to have forgotten that sometimes a practice can be good in one situation but ineffective or worse in another. That is, the value of a practice is often contingent on the context (MacCormack and Verganti 2003).

Tackling this problem requires that the rm craft a development strategy to t the context and update development processes as this context evolves.

JanuaryFebruary 2012

| 35

Managers often intuitively realize that projects facing different environments require different processes, even if the procedure manuals do not explicitly recognize this fact. For example, during the early years of the rst dot-com boom, Microsoft was attempting to develop an Internet browser to compete with its archrival, Netscape (Cusumano and Yofe 1998). The challenge was, at that time, many potential customers did not yet know what a browser should do, or the features they would want in such a product. Hence the team building Internet Explorer, Microsofts new offering, decided to adopt a much different development process from that used by other groups in the rm. Microsofts typical process relies upon establishing a clear vision for the product up front, followed by a staged approach to implementation in which three or four sets of features are developed and tested in sequence. Once the design is complete, a formal beta program is run with select customers to detect and x any defects in the product. By contrast, the Internet Explorer process relied on much more frequent and rapid design iterations, with early beta versions put online for customers and non-customers to test, and regular design meetings at which major changes to the specication were not only tolerated, but expected and encouraged (MacCormack 2001). Ultimately, the Explorer teams process looked more like Netscapes process than it did the processes used by the Windows and Ofce groups (Cusumano and Selby 1995). This was entirely appropriate; after all, the Explorer team faced a very different context than these other Microsoft product groups. The bottom line is that rms must strive to ensure that their product-development approaches are better aligned with their business needs. Recent academic studies of the product-development process reach similar conclusions (MacCormack, Verganti, and Iansiti 2001; De Meyer, Loch, and Pich 2002; Loch, De Meyer, and Pich 2006; Sommer, Loch, and Dong 2009). In particular, these authors argue that rms must adopt more exible processes in environments of high uncertainty and conduct multiple parallel trials where the costs of this technique can be justied by the payoffs. Important as these studies are, however, they seldom provide rich descriptive data on how a rm can manage a portfolio of different development styles, or clear guidance on the steps that must be taken to design a repertoire of styles. HPs experience in overcoming these challenges can be traced to a series of strategic moves set in motion around 2001. The rm was responding to the fact it had been slow to recognize and exploit opportunities created by the Internet, a problem brought about by the use of processes designed for more stable contexts. Over a multiyear period, the rm reviewed the approaches to R&D used across its various business units to capture what wasnt working and to explore how performance could be improved. The result of this project, which was led by an internal consulting organization, is a framework for choosing and implementing a productdevelopment process appropriate to the business context and the needs of the individual project. Of course, HP was by no means the only rm to encounter these challenges, or to
36 | Research-Technology Management

design solutions to themIBM now also applies unique organizational processes and structures to manage in different contexts (Garvin and Levesque 2006). We chose to focus on HP due to the unique access we had to the key decision makers who shaped their organizational response. We set out rst to understand how HP overcame these challenges and then to capture this approach in a framework that can be applied to other rms circumstances. Aligning Product-Development Strategy to Business Context at HP To select the right product-development style for a particular project, HP starts by understanding the demands of different business contexts. Consider, for example, three product segments in which HP competes: cloud computing, blade servers, and personal computers (PCs).1 The market context is different for each of these products. Cloud computing is situated in the torrential storm of a start-up, blade servers in the tornado of explosive growth, and desktop PCs in the trade winds of a mature business with intense competition. Each of these contexts comes with distinct questions and challenges (Table 1). In each of these contexts, managers will have different objectives for their product development activities. Managers in the cloud computing business must decide if there is a market opportunity that can protably be served by HP, and if there is, determine the specic nature of the products and services that should be offered. Managers in the blade server division, by contrast, know that a great market opportunity exists. But they need help understanding rapidly changing customer needs for these products and scaling the business to meet growing demand. Finally, managers in the desktop PC business must defend the companys strong position in a mature market, ghting lower-cost competitors in a context where customer needs are easily understood and stable over time. To meet these different objectives, HP denes a product development style to apply in each contextan emergent style to be applied in start-up contexts such as cloud computing, an agile style for use in growth sectors such as blade servers,2 and a style focused on efciency for mature markets such as desktop PCs (Table 2). Each style has a different core objective as well as explicit criteria for dening success. Identifying the objectives and criteria that must be optimized in

Cloud computing refers to the provision of computing capacity via a network, so that the user of the utility is remote from the provider of services. Cloud computing provides access to computing power on demand, with the user generally paying only for what is used. The term encompasses access to high-level applications and services as well as access to raw computing resources. Blade servers are compact, self-contained computer servers that are designed to be linked together to meet high-power application demands. Blade servers have many components removed to optimize space, power, and other resources. A desktop personal computer (PC) is a microcomputer whose price, size, and capabilities make it suitable for personal usage in a stationary environment. 2 Agile development is a specic style of development commonly used in the software industry (see, for example, MacCormack 2001). HP uses this term more broadly to refer to the capability needed to meet development objectives in a particular market context.

Do You Need a New Product-Development Strategy?

TABLE 1. Different product lines operate in different market contexts. Start-up Cloud computing Key Questions Customers Customer Needs Market Size Technology Maturity Solutions Available Knowledge Does a market exist? If so, in what form? Lead users and enthusiasts Largely unknown Very smallmay not even exist yet Very immature, but improving in leaps Many unexplored design possibilities <20% of nal design parameters Growth Blade servers How quickly can we adapt and scale? Early majority in the adoption bell curve Known, but changing rapidly Small, but growing rapidly Maturing quickly, following well-dened trajectory Competing design possibilities 4070% of nal design parameters Maturity Desktop PCs How can we sustain margin and share? Late majority and laggards Well known and stable over time Large, but with at or declining revenue Proven and stable, predictable Well-known single dominant design >90% of nal design parameters

each case helps HPs managers set clear expectations for the outcomes of the product development process. For example, the business context for cloud computing requires optimizing for emergence. The strategy driving the development process must elicit the emergence of a breakthrough new product in a complex landscape where the primary customers are not yet clear and technical solutions are still undened. These expectations, ideal for cloud computing, are a lousy way to manage the PC business. The continual rework and frequent changes in direction needed in a process that facilitates emergence are wasteful in a well-dened market with wellunderstood needs that can be met with a process targeting efciency. In the PC business, a dominant design has emerged, meaning the basis of competition has shifted from product innovation to process innovation (Utterback 1996). Rapid evolutions in product concept, design, architecture, and core technologies based on intensive market feedback once made sense, but no longer. The development strategy must now reduce design-driven end-to-end coststhat is, the cost of

development itself plus those costs driven by decisions made during development (for instance, supply chain costs, material and packaging costs, warranty and other support costs). In this market, efciency is far more important than emergence, agility, or any other objective for which the strategy could optimize. Many robust processes have been designed to help with this task (see, for instance, Cooper 1990). Optimizing for efciency means that HPs desktop PC managers care about different things, and in different ways, than its cloud-computing managers do. For example, although innovation is important in every style of development, the nature of innovation changes in a process focused on optimizing for efciency. For desktop PCs, innovation might involve continuous improvements to quality, reliability, and the total cost of ownership (things that customers value that also help reduce HPs end-to-end costs and +1 feature innovations (for instance, removable skins) that meet customers needs and provide greater differentiation but do not affect the dominant design or core technical choices (Utterback and Suarez 1991).

TABLE 2. Matching product-development styles to business context. Business Context HP Style Core Objective Start-up Emergent Probe and learn via multiple prototypes to understand the value proposition to different customers Deployments Beta customers Feedback received Value generated Growth Agile Rapidly evolve the product design to meet changing customer needs and technical choices Speed Flexibility Responsiveness Scalability Questions to evaluate how well the design ts evolving customer needs: What is customer response to early beta versions and prototypes? What features should be prioritized in the next iteration? What changes in technology should be incorporated in the next version? Maturity Efcient Improve only those features valued by customers and reduce end-to-end product costs Productivity Costs Margins Schedule

Criteria for Success

Key questions

Questions to gauge whether value exists at all: Who is the customer? How does our product create value for them? Will anyone pay for what we offer? Can we make money on it? Is this opportunity unique to us? What are the risks associated with it?

Questions to evaluate progress versus the plan: How are we doing on schedule, features, and quality? Does the design meet all of the exit criteria for this stage? How much will it cost to complete the project?

Do You Need a New Product-Development Strategy?

JanuaryFebruary 2012

| 37

Adopting a different style of development in different contexts is valuable in that it forces managers to pay attention to specic, relevant questions.

Industry lifecycle is not the only factor that determines the objectives for a rms product-development strategy; the rms position within the industry is also critical. In the market for electric and hybrid vehicles, for instance, rms like General Motors (GM) and Toyota are optimizing for efciency, taking advantage of their strong positions in gasolinefueled vehicles. Upstarts like Tesla Motors, on the other hand, are optimizing for emergence, developing high-margin niche products that give them the nancial and design freedom to compete against incumbents. Teslas rst product, the Tesla Roadster introduced in 2010, is a $100,000, 100 percent electric sports car that accelerates from 0 to 60 mph in 4 seconds, has a top speed of 130 miles per hour, and travels up to 250 miles per charge. Tesla is targeting high-end sports car acionados who are as interested in the performance attributes of the car as much as its emissions; part of the appeal for this market is that they could not have bought a car with this combination of attributes 12 months ago. GM and Toyota are targeting traditional customers who wish to improve their fuel consumption, but only if it makes economic sense. These distinct segments present different levels of uncertainty to decision makers. Hence Teslas process has to be much more exible than GM or Toyotas, as it seeks to discover the ideal product to offer customers, and whether these customers will pay enough for these products to make the business viable. Adopting a different style of development in different contexts is valuable in that it forces managers to pay attention to specic, relevant questions. A managers announcement that customers hate the beta release! is a crisis when optimizing for efciency, but a reason to celebrate when optimizing for emergence. The former reects a large investment gone awry; the latter, a small, quick investment in learning that provides input to the next iteration of development. When a company implements a portfolio of development styles, as HP has done, senior managers must learn to ask different questions in projects that use different styles. Ultimately, a rms product-development strategy must be concerned with achieving the best match between productdevelopment styles and different business contexts. Doing this well allows new opportunities to ower and thrive and mature opportunities to be managed in a way that harvests the greatest possible value. Conversely, mismatches between development approach and context can generate fundamental threats to a businesss viability. HP has learned from both types of outcome, as the following cases demonstrate.
38 | Research-Technology Management

Case 1: Emergent Product-Development in the Cloud With the increasing deployment of broadband Internet access, many enterprises are moving to an IT model based upon web services, in which software is offered and consumed as a service rather than sold in shrink-wrapped boxes and installed on local computers as a product. The services are delivered to users from a set of servers in a central location via the Internet. To the users eye, the software, storage, or other services reside in the cloudthe collection of resources that make up the Internet. Cloud computing represents a new approach to the provision of computing resources, allowing individuals and organizations to tap into computing power when it is needed, wherever they are located. It is a good t for applications with wide variations in demand, where large amounts of power are needed for short periods, as well as for smaller organizations, which dont need continuous access to the power of an onsite product. HP Labs, the advanced research arm of HP, led the companys foray into the nascent cloud-computing market. Its managers understood the high level of uncertainty on most dimensions of this context; in particular, they had no idea of the nature of the customers who would use such services or the particular combination of technologies that would create maximum value for these customers. As a result, the rm chose a strategy that optimized for emergence, using a series of iterative prototypes to create unique, rst-of-a-kind services, which were further evolved as information gathered in previous iterations allowed the rm to understand the opportunity more fully. As the rst application for its experimental product, HP focused on a rendering service for computer-generated images. Rendering is the process of generating the nal, lmready output frames of digital animations; it adds color, texture, lighting, and special effects to the 3D character models and scenes. It is a computationally intensive part of the animation process; generating a single frame of an animated lm can take many hours of processor time. Thus, HPs Utility Rendering Service (URS) addressed a real and expensive problem by offering a simple, exible, and scalable service that provided huge amounts of computational power for rendering lm animation. The choice of URS for the rst application was driven less by the attractiveness of this market per se and more by the desire to nd a suitable sandbox within which to learn about opportunities in this new market. The rm was prepared to lose money in its rst efforts, as long as the lessons learned helped determine where the real opportunity was. In other words, the rm sought a market and a customer that would allow its researchers to explore the landscape quickly through rapid, evolutionary prototypes and direct contact with lead users. The initial prototype served a single customer: a small animation company in the United Kingdom, near the HP Labs European facility. The technology was used to create an award-winning short animated feature, generating early customer feedback that was used to evolve the prototype substantially during use. Thereafter, a series of prototypes was developed in conjunction with other lead-user customers.
Do You Need a New Product-Development Strategy?

This allowed rapid, parallel exploration of customer requirements, product features, and emerging technologies. One of the customers that joined the effort was DreamWorks Animation, a close HP partner and long-standing technical collaborator. A company with high creative ambition, DreamWorks already owned an extensive computer facility for rendering, but an upcoming projectShrek 2was anticipated to stretch even its large capacity. DreamWorks found the idea of augmenting their computing resources with an on-demand cloud-computing service to be highly attractive. Ultimately, HP designed and built a 1,000-processor computing facility at their Palo Alto facility, which was used to render more than 500,000 individual frames for Shrek 2 the rst time a major lm animation company went outside its gates for a signicant share of the rendering process. This experience, involving a highly sophisticated customer that stretched the teams prototype service in many different ways, helped HP to evolve its thinking even further. The subsequent generation of URS was developed to support multiple customers working simultaneously on different lms, with advanced approaches to the dynamic allocation of computing power between customers. HP took advantage of the proximity of several local lm companies and the internationally recognized Animated Encounters lm festival to work collaboratively and conduct iterative testing with lead users; a group of 11 professional animation groups used evolving, experimental versions of the service to create festival-quality lms. Once again, lead-user insights, experiences, and suggestions were fed into development of the next prototype. Critically, much of this learning was applicable not just to the rendering service, but also to the broader development of cloud-computing services for other types of customers. Ultimately, the managers of the URS project designed a strategy to t the context of a disruptive, unproven new technology, facing uncertain customer needs. Their approach adopted relatively lightweight processes and simple rules used within an overall strategic vision (Eisenhardt and Sull 2001). The team accepted rework as the norm, throwing out early prototypes while keeping the learning they had generated as the project progressed. The approach was founded upon constant interaction with lead-user customers in a highly responsive, high-bandwidth mode (von Hippel 1988). Almost everything was treated as an experiment. This was quite different from the dominant mode of development in other HP businesses. By the end of this rst stage of experimentation, many early uncertainties were resolved and HP had gained signicant knowledge with which to attack this

new opportunity. Critically, it had done this while the market itself was still small and immature, and with only a modest R&D budget.3 With the market opportunity dened, the key business objective turned to one of managing rapid growth, heralding the shift to an agile style of development. Case 2: Efcient Product Development By the Numbers The calculator business provides a stark contrast to cloud computing in thinking through how to craft a productdevelopment strategy that ts the business context. Here, HP had to overcome early mistakes that led to a fundamental mismatch between style and context. These mistakes, as well as the solutions to them, were part of the motivation that led HP to develop a new framework to help match process to context. For many people, HP is synonymous with calculators. Bill Hewlett conceptualized the pocket calculator in the early 1970s. But by 2001, the calculator market had matured and HP was doing poorly, in part because its strategy had not kept up with an aging industry. HP had low gross margins and high expenses, resulting in operating losses, and its products were outdatedonly one new product had been introduced in four years. The company was on the verge of exiting the calculator business and likely would have done so were it not for its strong historical ties to this market. But when Fred Valdez became manager of the division in 2001, he recognized an opportunity in its strong brand recognition and loyal customers (Valdez 2004). Valdez developed a new strategy based upon an 88 percent reduction in headcount, the outsourcing of key functions, a no-returns policy, zero price protection for channel partners, and an aggressive ow of new product introductions. The mature business contextone in which customers had stable and predictable needs and the technologies required to meet these needs were mature, cheap, and widely availabledictated new objectives for development. First among them was an order-of-magnitude improvement in cost. Prior to 2001, the division had thought that it was efcient, but an ever-maturing market meant that it had drifted off target. The new goal meant substantially reducing R&D expenses, stripping waste out of the development process and reducing design-driven end-to-end costs. HP took advantage of a highly capable yet competitive supplier base to outsource the design of its new calculators while leveraging its in-house intellectual property (IP), resulting in lower-cost products with quality comparable to those designed in-house. Reducing its R&D costs allowed the rm to introduce more new products, developed in parallel. And by emphasizing reliability and usability for these products, HP was able to reduce calls to customer support centers, warranty claims, and other support costs. Outsourcing the design of calculators was easy to do given the maturity of the marketthere was little technical or market uncertainty. Yet this step involved more than just a simple make vs. buy decision. The new approach required the rm to develop a different system of development practices, including better product specication processes;
JanuaryFebruary 2012

The nature of the cloud-computing business played a large role in facilitating this style of development. Services could be evolved quickly because they were running under the control of HPs development team; responding to customer needs was achieved, in some cases, simply by having customers hit reload on their web browsers. Just as applications from Google or SalesForce.com can be rapidly rolled out and sampled by new customers every few minutes, HPs new service innovations could be developed and tested very quickly. The feedback loop was far shorter than it would be for, say, hardware or shrink-wrapped software.

Do You Need a New Product-Development Strategy?

| 39

Many rms take a one-size-ts-all approach to development, applying a single style to all projects.

appropriate choices. Based upon HPs experience, we have developed four explicit steps that can help accomplish these objectives. 1. Dene different development styles Firms must rst add an explicit step in the business or product-planning process that deals with selecting or designing appropriate product-development styles for the contexts in which they operate. That step should be facilitated by a dened procedure to lead managers through the necessary steps to identify an appropriate style (Table 3). The primary task in this phase is aligning assumptions in terms of the objectives that each business must optimize with the maturity of the markets that it faces and its current positions within these markets. Disagreements over such issues are a major source of friction, resistance, confusion, and mistakes when trying to drive change in an organizations development strategy. Once a rm has dened the objectives it must meet across its target markets, the next step is selecting a coherent set of development practices to achieve each objective. There is no magic way to do this; it requires a thorough evaluation of a range of factors, including the different levers available to the rm, such as the choice of overall development process; team structure and organization; processes for developing understanding of customers; processes for technology development; intellectual property strategy; platform and product architecture; partnering strategy; and systems for measurement, evaluation, and reward. None of these practices alone can deliver optimal results. Only a set of interlocking and complementary choices will work. Of course, rms often do not have the time or resources to design a unique process for every project. Firms can still reap

procedures for identication, selection, and coordination of design partners; and systems for validating and accepting nal designs from partners. The new style required that the deliverables from these processes be much more explicit and complete than ever before. The result was dramatic improvement. Within two years, HPs gross margin tripled, operating expenses fell by 80 percent, support costs fell by two-thirds, and prots skyrocketed. Furthermore, eight new calculators had been introduced, most leveraging in-house IP, including the hot-selling platinum HP 12C, a perennial favorite of nancial analysts. Dening Styles, Overcoming Inertia, and Managing the Portfolio Why do rms adopt styles that are not aligned to their business contexts? Many rms take a one-size-ts-all approach to development, applying a single style to all projects, regardless of context (Cooper 1990; Lene and Loch 2010). In addition, many managers are unaware of potential choices and default to what they know, regardless of whether their past experiences t the current context. Overcoming these challenges requires helping managers to understand the levers available to them, while giving guidance on how to make

TABLE 3. Selecting and dening an appropriate development-process style. Steps Step 1 Dene the business context Key Questions Who are the customers? How well known are their problems? How feasible and proven are technical solutions? How big and fast is the market growing? How well are we positioned versus competitors? Given this, what factors should the strategy optimize?

Deliverable: Criteria to be optimized by chosen style Step 2 Select appropriate development style How well is the strategy delivering this today? Is a change in style required? Can we apply an existing style of development or should we dene a new style? If the former, step 3 will require incrementally adapting current practices to new demands. If the latter, step 3 will allow greater degrees of freedom in picking a new set of practices. What coherent set of practices will produce the desired result: development process, product specications, customer understanding, technology invention, intellectual property strategy, organization, team leadership and structure, platform and product portfolio, architecture, partner strategy, and measurement, evaluation, and reward? What is the roadmap for implementing these changes to the system over time? Deliverable: Style implementation road map Step 4 Monitor and review over time How can we embed a review of style performance in the life cycle for each project? What are the early warning signs that the style is not performing well or that a new style is required? Deliverable: Measures of style performance

Deliverable: Selected predened style or characteristics for new style Step 3 Dene and implement style

40 | Research-Technology Management

Do You Need a New Product-Development Strategy?

the benets of exibility while retaining the efciencies of standardization by dening a few template productdevelopment styles for the main contexts in which it operates. HP chose to adopt three styles, which provide enough

differentiation to meet the objectives for each of its different businesses (Table 4). Ultimately, the appropriate number of styles as well as the set of practices that each encompasses is a decision that rms must make for themselves.

TABLE 4. Development practices for HPs three product-development styles. Emergent Development Process Lightweight process with uid objectives; rapid exchange of information with potential customers to identify the customer value proposition High-level sketch only; Specications are the output of emergent projects, input to agile and efcient projects Create zero distance between developers and lead users. Interact via high-bandwidth, low-latency channels using frequent prototypes Link invention to customer understanding by getting functional prototypes into hands of customers early and often; help to establish a dominant design Patent core IP with sufciently broad claims to prevent design around OR publish it to retain access and drive new standards Organize by business opportunities Small, physically collocated, crossfunctional team of smart people who are comfortable with high levels of ambiguity Create one product and iteratively improve it; avoid platforms (dont yet know enough to commit to a platform). Revisit platform design once opportunity is validated Architectural concerns are not paramount; aim to throw away early version after market is validated; design the product solely to maximize learning rate Use partners to increase speed with which new ideas can be tested with potential customers; emphasize learning and responsiveness Opportunities validated, assumptions checked, specications dened, positive press mentions, sales growth, stickiness of implementations, burn rate, milestones Agile Evolutionary process based on frequent design-build-test iterations, milestone releases, and beta versions with actual customers; continually re-prioritize features Established in general up front; updated as feedback on performance and changing customer needs dictates Create mechanisms to work with real customers who are representative of the market. Interact via early beta versions for feedback on features and overall performance Efcient Well-dened staged, gated process with clear entry/exit criteria, explicit tasks and deliverables, and rigorous checkpoint review meetings; monitor to plan Established in detail up front; based on well-understood customer requirements and technical solutions Use traditional market research. No direct interaction between developers and customers

Product Specications

Customer Understanding

Technology Invention

Adapt technical choices and features Follow dominant design by adding through early releases to custom+1 features and emphasizing ers; respond to feedback by process/cost-focused innovations incrementally evolving features over product innovation and new within the current dominant functionality design Patent/protect incremental innovations; stockpile patents to block competitive moves; use speed of adaptation as primary differentiation Organize by innovation programs Program manager with direct responsibility for functional staff integrates information and evolves the design in a rapid, controlled fashion Dene platform, enhance portfolio via derivative products to explore adjacent sub-segments while refreshing basic offering frequently; leave minimal white space on the product road map Brand and trademark solutions to enhance the value of technologies with expiring patents; monetize non-core IP via licensing or sale Organize by specialized functions Functional structure with lightweight coordination to reduce costs and leverage expertise across products Create few, long-lived platforms that support differentiated products with many common components

Intellectual Property

Organization Team Structure

Platform and Product Portfolio

Product Architecture

Partition the architecture to limit Balance modular and integral ripple effects from components design for features and costs and interfaces that change the (Modularity can increase exibility most; limit changes to parts of the but reduce performance. Integral system that will add value to the designs do the reverse) customer Use partners who possess stronger capabilities in critical subsystems now that a dominant design has been established; emphasize capability Revenue and prot growth, new functionality added per release, customer satisfaction, responsiveness to changing demands, wins in competitive reviews Use partners to reduce cost and increase capacity; retain customer understanding, architecture, and core IP inside; emphasize cost Design cost/unit, production cost/ unit, contribution margin, customer loyalty, development cost, warranty and support costs, wage rate

Partnering Strategy

Measurement, Evaluation, and Reward

Do You Need a New Product-Development Strategy?

JanuaryFebruary 2012

| 41

2. Dene the criteria for style selection Once a rm has dened the styles available, it must dene how the choice between them should be made for individual projects. While the specic industry and the rms position in that industry will determine the broader environment for a project, the type of innovation being pursuedincremental, platform, or breakthroughis a critical factor in choosing the appropriate style for development. At HP, managers are asked to select a style based on a detailed assessment of both the technical and market risks present in the business context (Figure 1). When risk is high along both dimensions, an emergent style is best; where risk is low on both dimensions, an efcient style typically works well. When the context entails an intermediate level of risk, an agile style is often chosen for the task. This step is particularly important in large, successful rms dominated by mature businesses that must optimize for efciency. Firms in such contexts tend to have developed sophisticated styles of development based upon Stage-Gate type processes that keep a lid on costs while maintaining control over feature creep. But such processes will suffocate projects and teams facing a more ambiguous context. Without a well-designed style to run these types of projects, rms nd it increasingly difcult to bring novel ideas to market. Indeed, these dynamics likely contribute to the well-studied challenges facing incumbents in responding to disruptive change (Christensen 1997; Tushman and Anderson 1986; Henderson and Clark 1990). The often-referenced solution of building an ambidextrous organization (OReilly and Tushman 2004) is aligned to this framework. 3. Attack inertia when shifting styles Managers often must shift from one style to another as a market develops. For example, managers in HPs digital camera business had to shift from optimizing for emergence (1995) to focusing on agility (2000) and nally to prioritizing efciency (2005) as advances in sensor technology combined with increasing consumer acceptance of digital images to change the nature of the market. Hence, R&D managers must add explicit steps to their internal planning processes to help them recognize when to make these shifts as well as how to manage the transitions. Having different styles helps

managers by making explicit what has heretofore been implicit: the relationship between business context and product-development strategy. But people inside a business are often the last to recognize the impact of external shifts in the environment. Hence, rms must seek out objective, external information and expertise when assessing the contexts in which they operate, in order to spot disruptive transitions before their competitive positions deteriorate. Even when you know it needs to be done, shifting styles is difcult to achieve, and managers may be the source of resistance. In some businesses, as markets mature, managers resist moving from emergent to agile to efcient styles because this is perceived as leading to a loss in creativity, exibility, and resources. Some managers simply prefer the stage of a business where everything is an experimenta big reason that entrepreneurs seldom make good CEOs once a rm has achieved initial success. In other situations, managers may resist moving to emergent or agile styles because they equate them with a lack of control over budget and schedule. Long-time Microsoft employees who moved to its new Internet division in the mid1990s were faced with a similar transition, needing to unlearn some of what they knew about software best practices. In situations such as these, managers may recoil from the perceived anarchy, mistakes, rework, and lack of inuence in an emergent style. Like a classically trained musician discovering jazz for the rst time, they note the lack of a written score, conductor, or perfectly repeatable performances. But jazz and other improvisational art forms do have an underlying structure, a theme that is repeated and varied, and players who know how to send and receive musical cues. A classical musician can play jazz, but it takes openness to new experiences, a willingness to practice and experiment, and a tolerance for ambiguity. Similarly, managers can make the shift from efciency-focused styles to more exible approaches, but only if they are willing to work at it. In our experience, individual designers, developers, engineers, and even managers tend to have strong preferences for specic styles; some love to devote time to intensive research and planning before acting, whereas others prefer trial and error experimentation to navigate new design spaces. While a few might be agnostic, the majority will nd it challenging to switch between approaches. Cataloging the preferences and skills of key contributors is therefore a critical rst step in understanding how to shift from one style to another. 4. Manage the style portfolio Working within this framework, a rm may end up with a portfolio of different product development styles within a single organization. For example, managers of HPs server business are responsible for developing cloud computing (a small market with huge uncertainties), blade servers (a rapidly growing market), and industry-standard servers (a commodity market). Deploying more than one style of development under the same roof can be quite challenging, given differing objectives, processes, incentives, and cultures (Christensen 2003). Finding an effective response to this tension is critical to succeed.
Do You Need a New Product-Development Strategy?

FIGURE 1. Selecting a product-development strategy based on technical and market risks.

42 | Research-Technology Management

One approach is to divide the portfolio among different organizations, each of which is optimized for specic objectives, simplifying the work of managers within each. For example, IBM classies each of its businesses into one of three different horizons (Core, Growth, and Emerging) and manages and measures these in different ways (Garvin and Levesque 2006). Such an approach however, may fail to exploit assets and capabilities that could be shared across teams to provide competitive advantages (Westerman, McFarlan, and Iansiti 2006). Where such advantages are possible, a rm might allow multiple styles to coexist within the same organization, using the framework to make this fact explicit and to manage conicts proactively. We have seen both approaches employed and have success. The key is to share assumptions about the demands of each business context and to agree on an approach to meet these demands. Conclusion One size does not t all; there is no single, universal product development style that is right for all businesses at all times. Instead, different business contexts demand different product development styles. Learning from HPs experiences, R&D managers can become more adept at understanding what their business context requires from product development and assessing how their practices must change in order to deliver these objectives. By driving these changes explicitly and proactively, managers can systematically improve the responsiveness of their innovation processes and outperform competitors still caught in the best practices trap. The authors wish to thank their longtime collaborator, Joni Ohta, for her early and pivotal contributions to the body of knowledge that informs this paper. Her insights into different forms of product development, especially emergent and collaborative styles of development, were penetrating and revealing. References
Abernathy, W. J., and Utterback, J. 1978. Patterns of industrial innovation. Technology Review 80: 4147. Adams, M., and Boike, D. 2004. PDMA foundation CPAS study reveals new trends. PDMA Visions Magazine 28(3): 2629. Christensen, C. M. 1997. The Innovators Dilemma: When New Technologies Cause Great Firms to Fail. Boston, MA: Harvard Business School Press. Christensen, C. M. 2003. The Innovators Solution: Creating and Sustaining Successful Growth. Boston, MA: Harvard Business School Press. Cooper, R. G. 1990. Stage-gate systems: A new tool for managing new products. Business Horizons 33(3): 4454. Cusumano, M. A., and Selby, R. W. 1995. Microsoft Secrets. New York, NY: Free Press. Cusumano, M. A., and Yofe, D. 1998. Competing on Internet Time. New York, NY: Free Press.

De Meyer, A., Loch, C. H., and Pich, M. T. 2002. Managing project uncertainty: From variation to chaos. Sloan Management Review 43(2): 6067. Eisenhardt, K., and Sull, D. 2001. Strategy as simple rules. Harvard Business Review 79(1): 107116. Garvin, D. A., and Levesque, L. C. 2006. Meeting the challenge of corporate entrepreneurship. Harvard Business Review 84(10): 102112, 150. Grifn, A. 1997. PDMA research on new product development practices: Updating trends and benchmarking best practices. Journal of Product Innovation Management 14: 429458. Henderson, R. M., and Clark, K. B. 1990. Architectural innovation: The reconguration of existing systems and the failure of established rms. Administrative Science Quarterly 35: 930. Lene, S., and Loch, C. H. 2010. Lost roots: How project management came to emphasize control over exibility and novelty. California Management Review 53(1): 3255. Loch, C. H., De Meyer, A., and Pich, M. T. 2006. Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects. Hoboken, NJ: Wiley. MacCormack, A. D. 2001. Product-development practices that work: How Internet companies build software. Sloan Management Review 42(2): 7584. MacCormack, A., and Verganti, R. 2003. Managing the sources of uncertainty: Matching process and context in software development. The Journal of Product Innovation Management 20: 217232. MacCormack, A., Verganti, R., and Iansiti, M. 2001. Developing products on Internet time: The anatomy of a exible development process. Management Science 47(1): 133150. March, J. 1991. Exploration and exploitation in organizational learning. Organization Science 2(1): 7187. OReilly, C., and Tushman, M. L. 2004. The ambidextrous organization. Harvard Business Review 82(4): 7481. Sommer, S. C., Loch, C. H., and Dong, J. 2009. Managing complexity and unforeseeable uncertainty in startup companies: An empirical study. Organization Science 20(1): 118133. Tushman, M. L., and Anderson, P. 1986. Technological discontinuities and organizational environments. Administrative Science Quarterly 31: 439465. Utterback, J. M. 1996. Mastering the Dynamics of Innovation. Boston, MA: Harvard Business School Press. Utterback, J. M., and Suarez, F. 1991. Innovation, competition and industry structure. Research Policy 22: 121. Valdez, F. 2004. HP calculators and the strategic touch model: Proven business success, great future potential, HP Internal White Paper. September 15. Von Hippel, E. 1988. The Sources of Innovation. Oxford, UK: Oxford University Press. Online version available at http://web.mit. edu/evhippel/www/sources.htm (accessed October 20, 2011). Westerman, G., McFarlan, F. W., and Iansiti, M. 2006. Organization design and effectiveness over the innovation life cycle. Organization Science 17(2): 230238. Wheelwright, S. C., and Clark, K. B. 1992. Revolutionizing Product Development: Quantum Leaps in Speed, Efciency, and Quality. New York, NY: Free Press.

Do You Need a New Product-Development Strategy?

JanuaryFebruary 2012

| 43