Integrating the Fuzzy Front End ofNew Product Development

Anil Khurana • Stephen R. Rosenthal

The failure to integrate a product strategy, a well-planned portfolio, and a

facilitating organization structure with clearly identified customer needs, a

well-defined product concept, and a project plan can severely hamper new

product development. An examination of eleven companies aims at improving

the effectiveness of the front-end process.

Many companies formulate product strate-gies, routinely choose among new productconcepts, and plan new product develop-

ment projects. Yet, when asked where the greatestweakness in product innovation is, the managers atthese companies indicate the fiazzy front end.' Theyrecite some femiliar symptoms of front-end failure:• New products are abruptly canceled in midstreambecause they don't "match the company strategy."• "Top priority" new product projects suffer becausekey people are "too busy" to spend the required timeon them.• New products are freciuently introduced later thanannounced because the product concept has becomea moving target.

Times have changed since 1983 when Donald Schondescribed product development as a "game" in which"general managers distance themselves from the uncer-tainties inherent in product development and . . . tech-nical personnel protect themselves against the loss ofcorporate commitment."- Since then, new produa de-velopment has become a core business activity thatneeds to be closely tied to the business strategy and aprocess that mtist be managed through analysis anddecision making.' Now, general managers cannot dis-tance themselves from the uncertainties of produa de-

velopment, nor can technical personnel protect them-selves against corporate commitment.

As enhanced capabilities for concurrent engineer-ing, rapid prototyping, and smoothly frinctioning sup-plier partnerships have helped reduce product designand development times, management attention hashegtin to shifi: to the cross-functional front-end strate-gic, conceptual, and planning activities that typicallyprecede the detailed design and development of anew product.' Here, new product ideas gain the shape,justification, plans, and support leading to their ap-proval and subsequent execution. Yet, despite wide-spread recognition of the front ends importance, therehas been limited systematic examination directed atimproving its effectiveness.

Our exploratory study of front-end activity in ele-ven companies highlights best practice based on ourassessment of seven critical activities. We begin bytaking a systems view of the front-end process basedon existing academic and practitioner literature. Afterdiscussing how companies should manage the frontend as part of a normative model of the process, we

Anil Khurana is assistant professor of operations management and

Stephen R. Rosenthal is professor of operations management and director

of the Manufacturing Roundtable at the School of Management, Boston

University.

SLOAN MANAGEMENT REVIEW/WIN I'HR 1997 KHURANA & ROSENTHAL 103

use data from case studies to identify challenges andsolutions.^ Next, we describe an approach for creat-ing a successful process and present a checklist anddiagnostic for front-end practice.

What Is the "Front End"?

Prior research has focused on the success factors fornew product development (NPD). While many ofthese factors relate to design execution and projectmanagement issues, some penain to the front end.''Consistent with Roberts's model, we classified thefront-end-related success factors identified in prior re-search into foundation and project-specific elements.^The distinction is important because the two requiredifferent skills and levels of effort. Also, without ade-quate foundation elements, product and project suc-cess becomes a matter of luck. Project-specific activi-

"he product concept should beclear so thot managers can

sense whether the newlydefined opportunity seems worth

exploring.

ties focus on the individual project and require theproject teams effort to ensure a useRiI product defini-tion and project plan. These include a product con-cept statement and evaluation, product definition,and project planning. Foundation elements, on theother hand, cut across projects and form the basis forproject-specific activities. Thus they typicidly requireenterprisewide support, senior management partici-pation, and a cross-functional effort.

Foundation ElementsWitliout a c!e;ir product strategy, a well-planned port-folio of new products, and an organization structurethat facilitates produa development via ongoing com-munications and cross-Rmctional sharing of responsi-bilities, front-end decisions become ineffective.'' Achiev-ing these preconditions provides a foiindation for streamsof successfiil new products.

Key product strategy elements include the formu-

larion and communication of a strategic vision, aproduct'platform strategy, and a product-line strategyto support the go/no-go decision for a new product.''Previous research suggests that familiarity with theproduct strategy enables appropriate decisions onNPD timing and target markets and also an assess-ment of the fit between the product and the core com-petence of the business unit.'"

In addition to a product vision, business units needto plan their portfolio of new product developmentactivities, which goes beyond the traditional market-ing view of having a product for every segment, mar-ket, and price point. Portfolio planning should mapall new product initiatives across the business to bal-ance risk and potential return, short and long timehorizons, or mature and emerging markets. At thesame time, the portfolio plan should enstire consis-tency with the product and business strategy." It welldone, it fecilitates the allocation of scarce resources tonew product development projects.

An essential precondition is establishing the orga-nization structure for new product development. De-cisions on structure, communication networks, androles are made at a business-unit level. Research hashighlighted several requirements for the product de-velopment organization and its Riiictioning,'' such asusing a matrix or project form, orgtUiizing NPD aroundcore business/product teams rather than traditionalfunctions, using design and communication tools in-cluding information systems, and establishing con-trols and incentives as rewards."

Project-Specific ElementsProduct-specific front-end activities help clarify theproduct concept, define product and market require-ments, and develop plans, schedules, and estimatesof rhe projects resource requirements. However, theystop far short of creating detailed designs and specifi-cations for the product and its components.

The product concept is a preliminary identifica-tion of customer needs, market segments, competi-tive situations, business prospects, and alignment withexisting business and technology plans. Research sug-gests that the product concept should be clear so thatmanagers can sense whether the newly defined op-portunity seems worth exploring.'' Managers need tounderstand customer needs and identify the potential

104 KHURANA & ROSENTHAL SLOAN MANAGBMENT REVIEW/WINTER 1997

Figure 1 A Model of the New Product Development Front End^

Front EndFoundationElements

New Product DevelopmentExecution

Product andPortfolioStrategy

ProductDevelopmentOrganization:Structure,Roles,Incentives,and Norms

Pre-Phase Zero:PrelimiiiarvOpportunityIdentification.Market andTechnologyAnalysis

Phase Zero:ProductConcept andDefinition

Phase Dne:Product Definitionand ProjectPlanning

Specificationand Design

Prototype Testand Validation

VolumeManufacturing

MarketLaunch

Go/No-GoDecision

technologies and applications to satisfy them." Fortangible products, the product concept is usually il-lustrated with a sketch or three-dimensional model.Because such concepts are relatively inexpensive toproduce, managers often create several before select-ing one to fully design and develop. Early targets —measured in product cost, product performance, proj-ect cost, and time to market — set the stage for gen-erating various product concepts.

The product definition, an elaboration of the prod-uct concept,"' incorporates judgnients about the targetmarket, competitive offerings, and the time and re-sources for bringing the new product to market. Thedefinition activity includes identification of customerand user needs, technologies, and regulatory require-ments. These lead to a choice of product teatuies andftinctions, target market segments, and design priori-ties. Research on the implementation of the front endindicates that an explicit, stable product definitionand an understanding of the trade-offs among cus-tomer requirements, technology, and resource/costconstraints are important factors for success."

Project planning includes project priorities andtasks, a master schedule, projected resource require-̂ments, and other supporting information. Here, it iscritical to communicate the project priorities, pro-vide adequate resources, and anticipate contingen-

cies. And, despite progress in new product develop-ment practices, typical systems do not adequately ad-dress these critical issues."

The Front-End ProcessWe take a process view of the front end because earli-er studies and our preliminary research suggested thatthe individual activities, while logically interrelated,often are treated independently.''' Accordingly, wepresent a systems view of the front end {see Figure 1).This process description is consistent with growingempirical evidence of the need to simultaneously con-sider overall product strategy (foundation elements)with project-relevant input such as product ideas, mar-ket analysis, and technology options."" Thus under-standing the interrelationships between the activities isas important as the activities themselves.

Product strategy and portfolio plans should drivethe complete new product development effort, inconjimction with the capabilities and competenciesof the product development organization, with itsinherent assumptions about roles, communications,and culture. These elements are thus preconditionsor foundations for the explicit activities in new prod-uct development. Many companies implement a for-mal phase-review management system to define andguide the explicit project-specific activities; this re-

SL.OAN MANA(.hMLN|-Ri-VILW/WlNlER 1997 K H U K A N A & ROSENIKAI. 105

Table 1 Front-End Activities

FoundationElements

Project-SpecificElements

Typical Practices

Product strategyformulation andarticulation

Product portfolio planning

Product developmentorganizational structure

Product concept

Product definition

Value chain considerationsin product definition

Front-end project definitionand planning

Degree of Implementation

High

Clear and vi/ellcommunicated by aresponsible individualor group.

Explicit and thorough.

Clear and wellcommunicated.

Detailed customer andteclinologv choicesand features with clearpriorities

Complete and generallyunchanging.

Upstream and downstreamissues considered: part ofroutine core teamresponsibilities.

Explicit and thorough.

Medium

Partly exists, but noindividual or group isconsistently responsible-

Implicit at best.

Clear in theory but notalways in practice.

Detailed customer andtechnology choicesand features, unclearpriorities.

Complete but unstable.

Many issues considered:project manager responsiblefor ensuring all such issuesare covered.

Done but not rigorous.

Low

Unclear or nonexistent-

Notdone or considered.

Ambiguous.

Haphazardly done.

Incomplete at go/no-godecision.

Product developmentmeans product only;supply chain issuesrarely brought up.

Casual.

view process involves the process itself, roles thatmake it work, and primary deliverables.-'• Phases of the Front-End Process. G)mp;uiies gen-emlJy begin work on new product oppormnities (oftenallied "pre-phase zero") when they first recognize, in asemiformal way, an opportunity." If the newly definedopportunity is worth exploring, the company assigns asmall group, sometimes Including suppliers, to worktogether on the prociuct concept and definition {phasezero).

In phase one, the company assesses the business andtechnical feasibility of the new product, confirms theproduct definition, and plans the NPD project. Thustlie development team identifies the new product, itsdev'elopment, and the business rationale for proceed-ing. The front end is complete at the end of this phasewhen the team presents the business case and the busi-ness unit either commits to funding. stafFing, andlaunch of the project or kills the project.

• Front-End Roles. A core team (including the proj-ect leader) and an executive review committee of se-nior ftinctional managers responsible for making thego/no-go decision typically conducts the process weVe

described. During phase one, if not sooner, companiesassign individuals from all Rmaional areas as mem-bers of the core team for the product de\'elopmentproject. Normally, if a company approves the projeaat the end of phase one, a flill complement ot pc )̂pleto design, develop, test, manufacture, and lauiich thenew product supplements the core team. Previousstudies have indicated that team structure varies incomposition, size, and leadership.-' Ofren, the coreteam includes selected suppliers as partners; theirknowledge of technology, costs, and design and man-ufiicturing lead times can contribute to product defi-nition and project planning.• Primary Front-End Deliverables. The front-end ac-tivities result in the produa concept (clear and alignedwith ctistomer needs), the product definition {explicitand stable), and the project plan (priorities, resourceplans, and project schedules).'*

Front-End Challenges and Solutions

To understand tlie front-end processes and praaices atfifteen business units in eleven U.S., Japanese, and Eu-

106 KHU'RANA & ROSE^rTHAL SLOAN MANAGEMEMT REVIEW/WINTER 1997

Table 1 (Continued)

Implementation

Foundation Product strategyElements Product vision

Technology plaiuiing

Project-SpecificElements

Product portfolio planningEvaluation ot risk and diversificationCruss-project understandingLink to resource planning

Product development organizational structureCross-functional project organizationClear rolesEstablished comrrtunication structuresLeadership by executive reviews

Product conceptClear conceptUnderstand management vision for productIdentify customer needs

Product definitionComplete and explicit definitionStable: avoid unnecessary cbangeAnticipate mafket and technology evolution

Value chain considerationsEarly supplier involvementDownstream issues — logistics, serviceService and logistics representalive on team

Front-end project definition and planningClear project prioritiesAggregate NPD project planningContingency planning

NolB' Letters reler xa the eleven cumpanies m Ihe research

Degree of Implementation in Companies Studied

High

D,F,G,J

F,J

F.G.J

C.D,F,G

CF

A.F,J

F,J

Medium

B.E.H.I.K

A,D,E,G,K

A,C,D,H,I,K

A,B,I,J

A,D,G,I,J

C,D,G,H

A,C,D.G,H,K

Low

A,C

B,C,H,I

B,E

E.H.K

B,H,K

B,E,1,K

B,E,I

ropean companies, we interviewed more than seventy-five managers (for oiu" tesearch approach, see the Ap-pendix). Our study focused on incremental innova-tions — the majority of NPD efforts. Accordingly, ourfindings deal with improving the performance of exist-ing products or extending them to new applications.rather than with developing radically new products.

We have grouped the typical practices that charac-terize the foundation elements and project-specific ac-tivities into three implementation clusters — high,medium, and low (see Table 1). This analysis of ourdata also supports our earlier literature-based classifica-tion of the three foundation elements and the three

project-specific activities. Our analysis does recognizean additional activity: adding value-chain considera-tions to the front-end process.

We found significant gaps in how the case studycompanies implemented the seven front-end ele-ments, even for those companies that claimed to havethe front-end product generation processes we de-scribed earlier (see labie I). Even the companies thatprepared their own detailed prtxress descriptions gen-erally didn't avoid problems that they could have re-solved at the front end. In fiict, only companies F and,possibly, G and J could claim to have most of the ca-pabilities for an effective front end.

S L O / \ N MANAGEMEN-f t997 KHURANA & ROSENTHAI, 107

Foundation Elements at the Case Study CompaniesNext we discuss in detail how the case study sites tnan-iiged tlie fotuidation elements ui oaicr to provide iasightsfor companies tmng to improve dicir NPD eflorts.• Product Strategy. Our research suggests that despitetheir intentions, very few companies have clear prod-uct strategies to guide their decisions on new productopportunities. In our sample of eleven companies, werated only two as outstanding {F and G) and two assatisfector)' (D and J), while the remaining seven wereseriously lacking. We identified several deficiencies informulating and artictilating a product strategy andthe connections between product strategy and thecore NPD activities (see Figtire 1):• There were product development teams and ptoduamanagers, hut no one was in charge of formtilating aproduct strategy, even at the senior management level.• Several of the companies made new product devel-opment decisions based on project-specific criteriarather than considerations of strategic fit.• Business strategy was not specific to markets andprodticts.• R&D, largely insulated from the product develop-ment group, funded projects based on superior tech-nology rather than on dieir potential to satisfy par-ticular product requirements.

Ihe outstiinding companies in our sample had coun-tered these deficiencies. The power of a clear products t r a t ^ was evident at company F, where we studiedthe founh in a series of eight planned sequential prod-uct launches based on a common platform.-^ Thecompany had designed this platform to meet explicitcustomer, market, and technology guidelines, withwhich each successive release was consistent. The vi-sion of the husiness, prcxiuct, projcxt, and technologyenabled successive product development teams forthis platform to consistently deliver a product thatmet every target.• Product Portfolio Planning. More than a third ofthe companies studied did not plan a product devel-opment portfolio. Even when they did, planning atall but two of die research sites, F and J, was sporadicand incomplete. This n^lea can be traced to a combi-nation of vague product strategy, measurement diffi-culties in establishing risk/return profiles, and am-biguotis overall responsibilit)'.

While company H traditionally lacked a clear prod-

uct strategy, senior managers had begun to realize thatthey were in a mature, threatened business. In re-sponse, they made their flinctional maniigers aware ofbasic portfolio planning, with encouraging results.Their portfolio now includes a combination of differ-ent products with both established and new technolo-gies, instead of traditional projects with incrementalimprovements to the familiar product line. I he com-pany also enhanced the role of the executive reviewcommittee, known as the product approval commit-tee, to include assessment of the match between a new

"Regardless of the methods a^ compony uses for new\ product portfolio planning,

it needs to be part of an integratedfront-end process.

product concept and the existing product portfolio inrisk, time horizons, and markets.

In contrast, compiUiy F — which is very success-fiil in its business — constantly monitored the pa-rameters of its product development portfolio, suchas time horizon, risk, expected returns, required in-vestments, and needed capabilities. Senior managersand project and product managers continually dis-cussed the nature of the development portfolio andadditions to make.

R^ardless of the methods a company tjses for newproduct portfolio plajining, it needs to be pan of anintegrated front-end process. Our research suggeststhat there is ofi:en a discontinuit)' between portfolioplanning and the front end of the traditional prcxress.For example, if a project is killed at the front end be-cause of technological infeasibility, the resulting gap inthe development portfolio will become apparent onlyif front-end activities and portfolio planning are linked.* Product Development Organization Structure.We focus here on three roles ac the front end — theproject leader, the core team, and the executive re-view group — and on related communication struc-ttires. '̂' At the companies that measured best alongthis dimension (F, G, and J), the project leader was re-sponsible for promoting the interests of the project and

108 KHURANA & ROSINTHAL SI.OAN MANAGF.MKNT RKVirw/WlNTKR 1997

the core team right fi:om the start. This role includedlobbying for support and resources {being an "ambas-sador") and coordinating technical or design issues.'These project leaders initiated such communicationearly during the product/project definition and plan-ning stages. At company F, project managers estab-lished communication channels, role definitions, andcross-functional mechanisms for the developmentteam, as part of the product and project definition.

All the companies in our sample, except for compa-nies B and E, had a cross-functional core team do theanalytic work of product definition and project plan-ning. However, the role of the team varied among thecompanies and development projects. Company Asfirst autonomoLis product development team was suc-cessful because four amhitious, creative team memberscommunicated well. However, subsequent teams werenot as successful because the core team members wereunclear about their responsibility in creating the prod-uct concept and definition. In contrast, teams at com-pany F operated more systematically and sticcessfully.A small core team including the idea chaiTipion, a se-nior manager, and a potential project leader met earlyon and negotiated key roles and responsibilities. Thisnucleus group then recruited the fiill team and enstiredthat all members agreed on the definition oi roles andresponsibilities. This structure of team roles and re-sponsibilities was part of the product concept state-ment and was formally acknowledged in the productdefinition and project planning documents. Establish-ing the core team early, clearly defining roles and re-sponsibilities for the team, and facilitating supportingcommunications played a major role in company Fssuccess both in new prodtict development process anddie market itself.

Product success appears to be strongly associatedwith establishment of a cross-functional executive re-view committee. Only companies F and J had such areview. Company As review committee focused onteclinic;il issues, with the result that executives failedto have a holistic perspective. In contrast, the com-mittee at company F used each phase review to devel-op strategic and operational skills and establish normsfor communication and consensus building. It alsoguided the core team while making critical choicesand trade-offs or making decisions that might havean impact on the business unit's strategy beyond that

particular product. At both companies F and j , theexecutive group worked like a business team rathertlian functional representatives, consistently developed

stablishing the core team early,• ^ clearly defining roles and_ responsibilities for the team,

and facilitating supportingcommunications played a major

role in company F's success.

product strategy and engaged in new product portfo-lio planning, and formulated explicit project priori-ties (time, cost, and quality).

For an effective front-end process, the roles of dieproject leader, the core team, and the executive reviewcommittee must complement each other. Explicitlydefining these roles by answering the following ques-tions will make the front end less "fiizzy":• Should the core team resolve product definitionand project planning issues or refer them to an exec-utive committee?• Who is responsible for ensuring that product defini-tion and concept testing are balanced between thor-oughness and speed?• Who should ensuie that resources are allocated to aproject, as specified in the project plan?• Who should identify emerging technologies for in-clusion in Riture product platforms?• Who has the authority to ensure that products de-veloped by several business units or a unit ;ind one ormore "parmers" are aligned along product/componentinterfaces, development schedules, market foctis, andtechnology commitments?

Project-Specific Activities at Case Study CompaniesNow we concentrate on project-specific activities atthe front end: clarifying the product concept, stabi-lizing the product definition, considering the valuechain in the product definition, and defining andplanning the front-end project.• Product Concept. Our research revealed that clari-fying the product concept at the front end was surpris-

Si.oAN MANAGEMENT Rr.vira/WINTER 1997 KHURANA & ROSF.NI MAI 109

ingly diffictilt. Only fotir companies (C, D, F, and G)had succeeded in consistently developing clear, explicit,and precise descriptions of the product concept. Atseveral companies, the concept was unclear becausesenior managers did not communicate their expecta-tion of the products core benefits, choice of marketsegments, and pricing to the development team.

One company resolved this gap between manage-ment's vision of the product concept and the teamsunderst;inding of it by setting specific criteria for thefeatures appropriate to the product. It created a data-base for new prociua feamres — b;ised on variotis in-ptits fi^om field service, special customers, R&D, mar-keting, and customer feedback. It then assessed theseinputs in phases zero and one, b;ised on senior man-agements vision of the product, engineering feasibili-ty, market needs, resource requirements, price targets,and schedule — ;ind cLxssified them into "red," "green,"and "yellow" items. The company would never pur-sue red items in the current program (but could con-sider them for the next-generation product). Greenitems were necessary for the current product; the com-pany chose them based on need, feasibility, and other

Only four companies hodsucceeded in consistentlydeveloping cleor, explicit,

ond precise descriptions of theproduct concept.

constraints. Yellow items needed more evaluation, sothe company postponed them for subsequent re-lease.

At se\'eral aise study sites, the product concept wasunclear because the companies did not clearly under-stand customer needs. When sucb problems recur, aswe found at comp;inies H and K, products lack whatClark and Fujimoto call "external integrity."'' To makecustonier expectations and product features more con-sistent, sophisticated companies (such as companies Gand F) try to look beyond the customers "voice" to"aaion," by using techniques such as videotapes ofcustomers' use of existing products.• Product Definition. All the companies in our study

realized the pivotal importance of the early productdefinition. Yet most had failed to generate clear, stabledefinitions. While rapid shifi;s in technology and mar-kets make it impossible for some companies to freezethe product definition, most of the companies stud-ied acknowledged the difficulties this caused in theexecution stages of product development projects andthe high associated costs. In fact, only managers atcompanies G and F felt that the)' had developed ap-proaches for de;iling with instability and change.

For technology-driven companies (especially com-pany H), delays in product definition entailed therisk of an unstable, expanding definition in which de-sign engineers continued to add unneeded complexi-ty. Managers at companies G and F made a concertedeffort to freeze the product definition early on. Forthem, the challenge was to balance the requisite fiex-ibility with the avoidable uncertainty'.

Gompany F discovered a creative solution for keep-ing up with and capniring market information whileminimizing changes in the product definition —what we call the "missed elevator" approach. 1 he pro-gram manager realized that technological or featureenhancements for any product wouid never end. Herequired the product definition to include new fea-tures and feasible solutions to customer needs, as longas they could definitely be achieved by the plannedmilestone for that product release. If a customer needor technology-driven feature "missed the elevator," itwotild go into the next product release or "elevator."This approach to managing product development byhaving multireleiise platform planning ma\' becomethe next form of product development iind manage-ment. Not only does it help achieve a balance be-tween stability and flexibility, but it also leveragestechnological strengths and org-anization;il resources.̂ ''Thus more companies now include, in their front-end deliberations, the definition of multiple-releaseproducts, in which each release intentionally involvesonly a moderate level of new technology develop-ment.• Value Ghain Gonsiderations. While NPD researchhas highlighted the suppliers' role in new product de-velopment, we found that some companies have abroader value chain perspective at the product con-cept and definition stages."' This becomes necessaryas product designs and market delivery systems are

110 KHURANA & ROSENTHAL SLOAN MANAGEMENT REVIEW/WINTKR 1997

more competitive and complex. And customers donot buy only the tangible product but a package thatincludes the product itself, the company, the brandimage, the sales interaction, the delivery process, theafter-sales service, and the follow-up relationship.

Customers do not buy onlythe tongible product but apackoge that includes the

product itself, the company, thebrand image, the sales interaction,the delivery process, the after-sales

service, and the follow-uprelationship.

The development team should envision and plan forthis package at the front end; otherwise it may Ig-nore downstream requirements and not design prod-ucts for ease of distribution, installation, or repairs.

We found that these practices, while familiar at theexecution stage, are less aggressively and creativelypursued at the front end. Of the eleven companies indie study, only four (A, D, F, aiid J) were adequatealong this dimension. We observed several failuresand some creative solutions. Gompany A, a specialindustrial products manufacturer, faced new mainte-nance problems and poor telecommunications sup-port in providing field service. As a result, field ser-vice engineers became regular members of the coredevelopment team at the front end. At company D,the new product development team consulted withso-called "customer supply specialists."

As another example, Hewlett-Packard's printer di-vision had thousands of stock-keeping units (SKUs)for its products being shipped to different parts of theworld. HP resolved this problem of excess variety with"design for postponement"; it redesigned the productso that only the core printer SKU was stocked in re-gional distribution warehouses. It stocked attach-ments such as power packs, power cables, connectors,and even instruction manuals in different languagesat the distribution points and assembled the finalpackage for shipment only after it received a firm

shipment order. In feet, it designed the packaging it-self so that it cotild easily insert and assemble ali theattachments. The result was enhanced flexibility andreduced inventory costs, along with the needed prod-uct variety.̂ ' For all subsequent product developmentefforts, HP has routinely included downstream con-siderations at the front end.• Front-End Projert Definition and Planning. Atthis part of the front end, we observed confusionabout project priorities, incomplete resource planning,and inadequate contingency planning. Our discus-sions with core team members and project leaders ledtis to believe that fuzzy project priorities were the sin-gle most important reason for NPD delays, productoverengineering, and product-strategy mismatches.For example, company A initiated its mid-range prod-uct as a cheap-technology, low-performance versionof its high-end product. Yet management had alwaysvisualized a cheap-technology, high-performanceprodua. Finally, when the product came on the mar-ket several months behind schedule, it exceeded itsperformance targets but no longer met its unit-costgoals. At another company, managers solved this com-mon problem by comparing — at the fi^ont end —three kinds of project priorities for any new productdevelopment project: scope (product functionality),schedule (timing), and resources (cost). Senior manage-ment, the core team, and die (as yet unappointed) proj-ect leader at the pre-phase zero stage decided the rela-tive ranking of the three priorities for the projectsduration and communicated it to all project partici-pants.

Gompanies must anticipate resource requirements,train people to acquire the necessary capabilities, andthen ensure needs-availability matching based onproject priorities. Executives repeatedly told us thatthey had too few people to staff dieir many NPD proj-ects. At company J, managers used a capacity matrixto assess and assign sUifF. Senior managers selected thebest projects, set goals, and reserved resources. Gom-pany F, which also used a form of capacity matrix,faced a complicated challenge of resource planning.Like every organization, it had a core group of irre-placeable people who were in great demand for everyproject. When planning a next-generation product,the managers realized that the team member theywanted was heading a current project. To avoid such

SLOAN MANAGEMENT REVIEW/WINTI'R 1997 KHURANA & ROSENTHAL 111

probiems in the future, management resoived to bothtrain more people tor such assignments and also planeariy for staffing and sicilis requirements.

Companies can manage the tislcs oi new productdeveiopmcnt with thorough contingency pianning— generating multipie product concepts, developingalternative technologies in parallel and, in some in-stances, even creating competing designs for productsor subsystems.'- Yet, surprisingly, we found that mostcompanies {including company F) focused contin-gency pians mostly on regulatory issues such as safetyor environmental requirements. Apparently, projectplanners assumed that they would find technologysolutions without considering cost and qualit)'. Whenthe timing oi a new product introduction is impor-tant, reasonabie back-up plans are needed to avoiddelayed market launch. One approach is to build incontingent product features in case the planned onesdo not work. Taking risk management seriously andlinking product definition activities with project plan-ning can iead to appropriate contingency pians.

Recognizing InterrelationshipsNext we discLiss severai critiail interrelationships amongindividual success Factors and approaches for manag-ing them." Our examples are from company F, whichhad the mo.st effective front end of the cases studied.

• Companies should consider product strateg)' andthe product development portfolio at the stan of theproject-specific front end. Company F held a kick-oft meeting even before it had refined the conceptand assembled the full core team. Attendees includ-ed senior managers, che idea champion, and somecore team members. While much discussion focusedon the basic product concept, it also included how theconcept filled a gap in the btisiness strategj' and how itrelated to and compaied widi other products and on-going projects. As a restilt, subsequent problems ofmismatches between che product and the productstrategy or shortage of project staffing were rare.

• Companies should have a clear product strategy toenable a stable product definition. Everyone at com-pany F accepted the notion that product strategyshould guide technology choices and selected produafeatures. Thus the company used its miiltireleiise prod-uct strategy ct) simplify the definition: its adoption oithe "missed elevator" approach simultaneously encour-

aged stable technology and feature choices chat weregoverned by a long-term vision over several produce re-leases, while facilitating new relcises on time.• C'ompanies should integrate porcfoHo planningand NPD project planning. C>ompany F had estab-lished two discinct but formally linked planning pro-cesses. The scracegic planning process involved man-agers from various functions and considered productstrategy, product development portfolios, and overallresources. Thus portfolio planning yielded long-cermcommicments that the managers could invoke whenplanning scaff requirements and project priorities fora specific new product concept. 1 hey implementedtwo important practices when planning individual

Success depends on howcompanies integrate

dimensions ond elementsof product development.

projects: escablishmenc of schedules and allocacion ofscaff and budgecs, and specification of inputs such astechnology from other business groups. First, chq^made the strategic business plan available co all coreceam members and considered che product defini-tion in che concexc of che stracegic business plan.Second, senior managers oversaw che core ceams de-cisions and actions. For example, the project manag-er may be a part of the strategic business planningprocess or may report to someone who is.

A Well-Engineered Front-End Process

How can a company improve ies fronc-end practicesto achieve success in new product developmenc? Is icenough to improve the activities we have described?We surest chat best practice in new produce devel-opment goes beyond simply adopting these activi-ties. Success depends on how companies integratedimensions and elements of product development.-"

Our research higlilighted certain challenges in inte-grLicion of the front end be)'ond the obvious need forcross-functional eftorc. First, because projecc-specificactivities build on foundacion activicies, companies

I I 2 KHL'R.'VNA & ROSKNTHAI. SLOAN MANAGEMENT REviEw/WiN'reR 1997

should ensure chac che foundacion elemencs are alignedwich che product developmenc process and projecc-specific activities. Second, they should ensure consis-cency between scrategic and operacional activities. Thechallenge is to make scrat^ explicic e n o i ^ to guideday-to-day choices for new product development. Wefound che incegracion of chese cwo factors was rare butextremely potent. At the companies studied, we ob-served several kinds of integration problems:• Senior manors somecimes delegaced the formulationof a produce scracegy to product and R&D managers.• The product development staff often nivide deci-sions that affected otiier products and business unitstrategy. (While the core team faces technical uncer-tainty about the product and manufacturing and dis-tribution processes, resolving cross-project issues orproviding guidelines should be senior managementresponsibilities.)• Managers in various functions and organizationallevels rarely ensured consistency and links among

R&D activities, product strategy, and current produadevelopment. (Huge R&D investments can be wastedby pursuing superior technology capability unneces-sary to the organizations espoused business strategy.)• Managers frequently took on product developmentprojects without committing adequate resources. (Of-ten there is a misconception that product develop-ment staff working on multiple projects improves ef-ficiency. The restilt is long delays in product launchand lost revenues. With ongoing downsizing in manycompanies, this kind of neglect is becoming chron-ic/'̂ Senior managers need to help product and R&Dmanagers understand a projects relative importance.)• Senior managers did litde to meastire and reward cross-functional teamwork. (Front-end participants need toknow that management values their contribtitions.)

Balancing Front-End Explicitness and FlexibilityManagement of the front end also requires a balancebetween getting things right and being flexible during

Table 2 Checklist for Diagnosing the Front End

Formality of Front-End Process

1.

2.

3,

4.

5.

6,

7.

8,

9.10.

n.

Customer and market information is used early on toset scope for product (target markets, customer seg-ments, features, price).

Core team jointly reviews product concept andsenior management formally approves.

Early concept and other feasibiiity prototypes areplanned, tested, and completed at front end so thatthere are no surprises iater.

Product definition is explicitly developed and docu-mented.

Major supplier and tooling considerations are explic-it at front end.

Manufacturing, distribution, and logistics require-ments are planned: product concept is modified toreflect process and logistics constraints.

Need for new technology for products is clearlystated.

Project targets {time, cost, quality) and relativepriorities are clear.

Resource requirements are formaily defined.

Roles and responsibilities for tasks and communi-cations tor core team are clear and well executed.

Roles for executive review team are clear and wellexecuted (review criteria, decision responsibility,ongoing interaction with core team).

D

D

n

n

•

•n

•n

D

Integration of Activities

1.

2,3.

4.

5,

6.

7,

8.

9.

10,

There is a clear vision of product lines and platformsfor specific markets.

R&D and NPD have matching agendas and plans.

Balance is sought and achieved among multiple NPDprojects belonging to different platforms/productlines (e.g., risks, novelty).

Project priorities are consistent with product strate-gy, portfolio plans, and resource availability.

Resource allocations consider multiple projectrequirements and their relative priorities and pre-existing project commitments.

Early identification of technical and organizationalinterfaces is done for systems products so thatdevelopment can proceed smoothly.

Core front-end team includes representatives frommanufacturing, logistics, and after-sales service.apart from engineering and marketing.

Staffing policies and project-specific staffing areconsistent with the product strategy.

Need for new innovations is anticipated so thatextensive innovation is not required during the

product development process.If there is uncertainty on any dimensions — e.g.,technology or markets — organization has care-fully planned alternative approach.

•DD

n

n

c

D

D

D

n

SLOAN MANAGEMI-.N! REVIEW/WINII-K. 1997 K H U R A N A & ROSENTHAL 113

Figure 2 The Front-End Capabilitv Map

Full 10Integration 8

Degree ofProcess PartialIntegration Integration

LittleIntegration

-

14

Intuitive Explicit in Part

Degree of Formality

8 10Explicit

NPD execution. Other front-end elements and activ-ities should also be balanced. There is a natural ten-sion between planning to reduce risk and respondingto inherent uncertainties. For example, we suggestthat product strategy and portfolio planning be ex-plicit, yet we recognize that some subsequent shifts inthe product definition are inevitable, forcing contin-gent actions. Furthermore, postponing the final deci-sions at the front end by continuing the developmentof parallel concepts or solutions may reduce uncer-tainty.'" While our research did not focus on thisissue, we believe that there must be a biilance betweenfront-end planned activities and ongoing iteration dur-ing the NPD projeCT, between making "final" decisionseariy and intentionally keeping open parallel alterna-tives, and between establishing product developmenttargets through luialysis iUid working by instinct alone.'"

Diagnosing Front-End Activities

Based on our study findings, we propose that compa-nies evaluate their front end on degree of formalityand the integration of aaivities. The dimensions —formalit)' and process integration — can be measuredon a checklist (see lable 2). The items arc derivedfrom previous research and our case study findingson the need for formality and integration at the frontend. The diagnostic statements evaluate the explicit-ness and form;iJit\' of front-end practices. The state-ments on integration document how well these andother front-end activities are integrated.

A senior business unit manager such as the vice

president of R&D, chief technology officer, or direc-tor of new product development should assess busi-ness practices and then calculate the score of the busi-ness unit, counting a check for any item as one point.The sum of the scores on the formality statementsgives the formality score; the sum of the integrationstatements, the integration score. The manager canthen map the score on each dimension on the front-end capability map (see Figure 2).

The mapping indicates how well (or poorly) a busi-ness unit is doing along the two dimensions of for-mality and integration. Our research indicates thatworld-class companies score eight or more on bothdimensions. C^omp;mies tliat score three or less on ei-ther dimension have a deficient front end and are like-ly to have major problems with their product develop-ment efforts. Senior management neecis to find waysto improve these efforts; the checklist is a first step tounderstanding where and what to improve. What ismore difficult is to understand how. In the next sec-tion, we discuss how companies and biLsiness units

plan a transition to a better-m:uiaged front end.

Managing the Transition

All the companies we sttidied were moving toward amore explicit, integrated front end. They were tryingto build complementary capabilities to support thecritical go/no-go decisions and development plansfor new product concepts. Yet each was taking a dif-ferent path at a different rate.

Stages of EvolutionWe see three stages in the prcxiucrt development frontend, not including the snige in which a company has noformal front end — tbe pre-emeip:nt stage. ̂"̂ ITie nextstiiges are "awareness," "islands of aipabilit);"and "inte-grated capbility" {see Figure 3). The triggers to reach theawareness stiige from the pre-emei^nt stage are typicallygrowth, additional produci line complexity or competi-tive pressures for either more product innovation or lowerprodua development costs. In any case, at the awarenessstage, companies rea)gru2e the significance of the frontend but have linle capability associated with it. 1 beyscore jxKirly on both the formality and integration di-mensions, as did companies B, E. and H in our .s;miple.• Islands of Capability (Stage Two). Our study sug-

1 H KUDKAN.A & ROSI-NTHAL SLOAN MAN.'VIIEMENT RfviEw/WiNTrR 1997

Figure 3 Stages in the Transition to a Mature Front Endgests that most leading product innovatorsare at the islands of capability stage, includ-ing companies A, C, D, 1, J, and K. Thesecompanies realize the potential of having awell-managed front end and have some ofthe required capabilities, but inconsistently.Missing are many elements of front-end pro-cess integration. Companies find it easier toimprove the formality of this process than toaddress the subtle gaps in int^;ration.

How can companies evolve from "aware-ness" to "islands of capability"? That de-pends on what the business unit has iilreadyachieved and what capabilities it needs,given its industry and company. We identi-fied two broad approaches to achieving stagetwo. First, those companies that have barely begun managed as a single process. Stage three companies ex-

Full 10Integration 8

Degree ofProcess PartialIntegration Integration

LittleIntegration

10Intuitive Explicit in Part Explicit

Degree of Formality

to understand the importance of the front end — forexample, company H — should recognize that prod-uct development is a senior management responsibili-ty. Managers should carry out several structured activi-ties, such as the diagnostic test. Second, those com-panies that recognize the importance of the frx)nt end— such as companies B and E — should formallyand systematically conduct various front-end activi-ties. Those activities include having an explicit productdefinition, estimating technology requirements early,and planning resources.• Integrated Capability (Stage Three). Front-endproduct development integration, the hallmark of stagethree, is quite rare. We believe that most companies

Stage three companies executeNPD projects better and

faster than their competitorsand are more likely to introduce

a winning product.

ecute NPD projects better and faster than their com-petitors and are more likely to introduce a winningproduct. One am honesdy say of these companies that"well begun is more than half done."

How can companies make a transition from "is-lands of capability" to "integrated capability"? Somestage two companies have much of the required for-mality but not necessarily the degree of integration toyield substantial benefits. Most stage two companiesshould focus on understanding the various dimen-sions of integration. Among our sample, we identi-fied three clusters of companies that required some-what different approaches to get to stage three. Thesethree clusters represent generic front-end states andproblems that many companies face.

While companies in the first cluster, A and K, havepassed stage one, they still have a long way to go.They need to focus closely on senior management in-volvement in creating a product vision. Improvementsin front-end formality and integration, while noteasy, will be easier if the product development groupcan understand its purpose better.

Companies C and D make up the second cluster.These companies will realize improvements from re-finements in the front-end process. They need tomake their front-end activities more explicit and, in

don't understand diat this stage is significant in termsof required capabilities, and achieving it takes concert-ed effort. At the few companies with this degree of particular, understand how to better manage theirprocess integration — companies F, G, and, to some technology and resource requirements. Once theyextent, J — analysis and decisions have been both ex- progress on these dimensions, they can focus moreplicit and rigorous, and all front-end activities are I on cross-flinctional and integration problems.

SLOAN MANAGEMtNr REVIEW/WINTLR 1997 K H U R A N A & Rt)SF.NlHAI. 1 15

The third cluster of companies, I and J, were themost advanced among the stage two companies.Front-end explicitness is not their main problem.Instead, their challenge is to work on cross-project is-sues and technological uncertainties. By having closeties among strategic planners and project personnel,they will uiiderstmid the links among projects and an-ticipate matches or mismatches between future mar-ket needs and current technology and product plans.They need to establish closer connections betweentheir R&D and product development groups so thatthey am anticipate ovenill technological progress ;mdprodua-specific technological uncertainty.• Sustaining Stage Three. Clearly, reaching stage threeis not easy; even those companies that have achieved itcontinue to require improvements. Changes in com-petition, technologies, tools, and organizational struc-tures and relationships may need changes in at leastsome front-end praaices.*'

How can companies F and G improve? We foundthat these companies had minor deficiencies at theirfront ends (by using the diagnostic test in Table 2).Yet, the companies have potential for improvement.For example, knowing what to finalize and approvein product concept and definition, and what to keepflexible and open to change is important. Achievinga proper balance calls for more than just personal in-tuition and tacit understanding. Making explicit theconnections between product requirements and in-ternal technology development remains an elusivecapability. And maintaining continuous links amongbusiness-unit vision, product strategy, technology,and new products is an ongoing challenge. Managersat stage three companies need to evaluate and applyinnovations such as dcveltjping careflilly planned prod-uct architectures and platforms or adapting a front-endprocess — such as Coopers -— to deal with the dy-namics of current technological, market, and organi-zational realities."*

Conclusion

Most companies have unnecessarily fijzzy front-endsystems. The best way ro integrate the front-end pro-cess is to use an overall systems perspective and thor-oughly assess the current state of the front end. Fixingwhat appears to be broken requires the ability to see

the interrelatedness of issues and the development ofa coherent agenda.

We caution against oversimplification: not all com-panies shotild adopt the same front-end solution, andmost will need to adopt more than one. For example,we foimd that companies used executive reviews indifferent ways with mixed success; some case studycompanies changed the role of the executive reviewgroup for different products. In general, company size,decision-making style, operating culture, and frequen-cy of new product introduction are some factors thatare critical to a preferred front-end solution. We dis-course companies from importing a particular pro-cess or procedure that has worked well for others un-less their contexts are clearly similar.*'

Managing to become less flizzy means integratingseemingly disparate but related strategic and opera-tional activities, typically crossing functional bound-aries. The solution must be balanced with the emerg-ing realities of business and the environment. Withproper diagnosis, consensus, and commitment, com-panies can enhance product development perfor-mance over the long term. •

Appendix

We conducted our research between April 1994 andApril 1995.^ Of the sixteen companies invited to par-ticipate, eleven accepted. We chose companies biisedon whether they had a product-generation processand if they had NPD processes for one to eight years.Our final sample includes seven U.S. and four Japa-nese companies (all Fortune 500 companies or theirequivalent in Japan) in various industries ranging fromconsumer packaged goods to electronics to industri;ilproducts (see Table A for more information on thespecific industries). There are seven U.S., six Japanese,and two Euro^xan business units (we interviewed man-agers at multiple business units at two companies).Business-unit size ranged from $300 million to $2.5billion in annual sales, and 600 to 20,000 employees;company sizes ranged from $2 billion to $55 billion,and 20,000 to 300,000 employees. Further, we chissi-fied the companies as "active" or "neLitral"; the aaivesites participated very closely in the research, and wehad open access to them. At die neutral sites (compa-nies B, E, G, and K), we had only one opportunity to

1 16 KHL.IRANA & ROSl-NTHALSLOAN MANAUF-MtNT RKVIHW/WINTER 1997

Table A

BusinessUnit Code

A

B

C

D

E

F

G

H

1

J

K

Descriptions of Sample Companies

Ownership

United States

Japan

United States, Germany

United States

United States

United States

Japan

United States

Japan

United States, Europe

Japan

Core Businesses

Equipment for publishing industry

OEM for systems devices (e.g.. printers,PCs, software drivers) and majorelectronic components

Specialized health-care equipment

Consumer packaged goods

Pharmaceuticals

Medical products

Super, mainframe, and mid-range computers

Office equipment

Variety of electronics products from microdevices to printers to notebook computers

Ourable white goods, such as washers andcooking products

Production technologies and equipmentbusiness unit of major electronics company

Level of Analysis(Multiple products and/or NPO process)

NPO process and two specific product projects

NPD process

NPD process

NPO process

NPD process

NPO process and two specific product projects

NPD process

NPO process and four specific product projects

NPD process at corporate level and in threeseparate business units and one specificproduct project

NPO process in two separate business units andthree specific product projects

NPO process

get the data directly, i.e., only one visit or series of in-terviews. Naturally, the data from these companies areless detailed, although we obtained the essential infor-mation.

We adopted an exploratory and "action-oriented"approach because we iterated among data collection,analysis, and feedback. We conducted our research atthree to four company sites, analyzed data, presentedpartial restilts to a group of participants at "dis.semina-tion" workshops, wrote reports for their review, revisedour knowledge base and conceptual models, and wenton to the next case sites. Thus, implicitly and by de-sign, we adopted the grounded theory approach.

We spent more than 200 hours interviewing morethan seventy-five managers. On average, for each activesite, we spent between eight and forty hours interview-ing from three to twenty-five managers; for each neu-tral site, we spent eight to fifteen hours interviewing upto eight managers. We held four days of disseminationworkshops with more than twenty-five different man-agers from several research companies. We interviewedmanagers (ranging from ftinctional managers to com-

pany president) from marketing, R&D, software de-velopment, engineering, manufacturing, field service,finance, accounting, stmtegic planning, product man-agement, NPD process owners, and corporate/busi-ness-unit general man^ement.

For most of the case sites, we used secondary datacollection in an effort to understand the industry andcompany background. We then adapted our basic re-search and interview questions to match the compa-ny profile. Thus most of the interviews were largelyunstructured to support our exploration of the rela-tively undefined nature of the front end of productdevelopment.

The basic unit of analysis for our cases was the pro-cess of the front end of new product development.However, due to access, confidentiality, time, and con-trasts, we used several approaches to understand andevaluate the process. As Table A shows, our interviewstook two different forms: (1) a study of individualNPD projects (multiple projects at each company) and(2) an in-depth study of business tinit practices withregard to the process adopted for the front end of new

SLOAN MANACtMtNT RtiviEw/WiN II-K 1997 KHURANA & ROSKNTHAI- 117

product development. (We included multiple businessunits at two companies because these business unitswere in widely different markets or technologies, or be-cause they were perceived to have distinctive front-endNPD practices.)

d. In addition to ilie eleven cases directly involved in this research, wealso draw on and Lite examples froni prior knowledge of sn'eral casesof new product development projects that the second author re-searched in 198'J CO lWl , Sec:

S.R. RosL'iuhal. l-ffective Pmduct Desi^i and Deivlopruent (Homewuod,Illinois: Business One Irwin, 1992).

b. B. Glaser and A. SEraiiss, The Discoveiy ofGvowided Ti)eory: Strate^es

for Qiuditdtit'e Reseanh (C^hicago: Aldiiie I'ublisliers. I %7): andK.M. Risenhaidt. "Building Theoiy ftom Lase Research," Academy of

Management Review, volume 14, number 4, 1989, pp. 532-550.

ReferencesThis research w,is spoiuored and supponed by the Boston UniversityManufacturing Rotrndtahlt. School of Management, and a researchgram from Seiko Epson Corporation, Japan. The authors ackriow-ledge the cooperation of she U.S., Japanese, and European compa-nies that participated. They also thank Professors finichiro Nakaneand Hiroshi Katayama of Waseda University, Japan, <md ac-knowledge the help of Paul Callaghan. doctoral student at BostonUniversity, in data collection.

1. The notioti ol the Riz/y fuitif end and iis inipurtance was first in-troduced in:

P,G. Smith and D.G. Reinertsen. Developing Products in Half the7»Mc(New York: Van Nosirand Rcinhold, 1991).See also:

A. Khuranj iiiul S.R. Ro.senthal. "Discovering the Shortcomings inthe Front'Hnd" of New Producr Development: Findings from Cross-Industry Case Studies" (Boston: Bost(»ti University School of Manage-ment, Manufacturing Roundtahle working paper, 1996);K.B. C;iark and S.C. Wheelwright. Leading Producr Development(New York: Free Press. 1995);

S.R. Rosenthal, Effective Pjvdmt Design and Da'elopiiieiii {Huincmyod,Illinois: Business One irwin. 1992);

A.K. Gupta and [5.L. Wilenion. "Accderaiing the Development of'Fechnologv-Based New Products," Califomia Management Revieiv,volume il. Winter 1990, pp. 24-44; and

R.t;. Cooper and F.,| Kleinschmidt, 'New Products: What SeparatesWinners from \.me\s.\" Journal of Product Inmvation Management,volume 4. September 1987. pp. I h9-184.

2. See D.A. Schon, The Reflective Practitioner: How Professiomk Thinkin Action (New York: Basic Books. 1983). p. 266.

3. H.K. Bowen. K.B. Clark, C:.A. Holtoway. atid S.C. Wheelwright."Development Projects: The Etigine of Renewal," Harvard BusinessReview, volume 72, Sepieinbei-CXtober 1994, pp. 110-120.

For a business process view, see:

r Davenpon, Process Innovation: Reengineering Work through infomM-

ftflw (Boston: Harvard Bu.siness School I'ress. 1993), chapter I I .

4. See Cooper and Kleinschniidt (1987);

Gupta and Wilemon (1990):

Smith and Reinert.sen (1991);

Rosentha) (1992); andClaik and Wheelwright (1995).

For a study on factors explaining "good" product definition, see:C- Bacon, S. Beckman. D. Moweiy. and R. Wilson. "ManagingProduct Definition in High-Techno logy Indtistrics: A Pilot Study."California Management Review, volume 36, Spring 1994, pp, 32-56.Of the ke\- (actors for NPD success identified by Bacon et al. and otherreseairhers. several pertain to froru-cnd issues: produa-core competencefit. .senior nianager respotisibility for NPD planning, dear understand-ing of user needs, explicit description t)f prtniuct concept and definition.carefiil planning, specifying contingency plans, and resource planning.Foi purposes of description and understanding, we divide Bacon et al.'sinterpretation of protiuct defmition into puxiuct s t ra r^ . pnxhict defi-nition, and piojecT definition, primarily because tliese activities involvedifferent analytical and implementation approaches. See, also:W.E, Souder. Managing New Prodiici Innovations (Ladngton. Massachu-setts: Lexington Books. 1987);

Booz Alleti & Hamilton, "New Product Develojiineni in the 198Us"(New York.- Booz Allen & Hamilton. 1982); andR. Rothwell, C. Freeman. A, Horsley. V.'l.P Jervis, A.B, Rohertscm.and J. Townsend. "Sappho Updated — Project Sappho Phase II."Research Polity, volume 3, number 3. 1974, pp. 258-291.

5. We firsi identifed a series of operational problems encountered innew product development and linked them to acTi\ities and practicesat the from end. Foe rhat analysis, see:

KJiurana ajid R<«enthal (1996).6. Bacoti et al. (1994); andGupta and Wilenion (1990).

Wliile there has been limited research on the front end. re.searcherswho study new prcKliut devduptnent often indtide some NPD suc-ces.s fectors that pertain to the front end. See, fnr example:Smith and Reinertsen (1991);Rothwdletal. (1974); and

R.G. Couper and E.J. KIcinschinidt. "Deteiniinatiis of riiiieline.ss ini'rodiict Development." Joumal of Product Imioimioti Management,volume 1 1, November 1994. pp. .^81-396.

7. Roberts and FiLsfeld call a set of fotindation-type activities "criticalfiinctions for enhanced innovation." They poriray pioject-specific ac-tivities as a six-stage process starting with preprojea activities. See;E.B. Roberts and A.R. Fusfeld, "SEaffing the Innovative Technology-Based Organization." Sloan Management Revietv. volume 22, Spring1981. pp. 19-34.

8. M. McCirath. Product Strategy for High-Technology Companies (^wnRidge. Illinois: Iwin. 1995).

9. These are the top three Icveis of the strategic hietarchy presented byMcGrath (1995). McGrath describes product strategy in a four-levelhierarch)- starring wich strategic vision and then proceeding to prod-ucr-platfbiiri strategy, product-line strateg)'. and, finally, individualprojects.

10. Bacon etal. (1994).11. McGrath (1995): andR.G. Coofier and F.J. Kleinschmidt. "New Product Performance:Keys tu Success. Profitability, and Cycle Time Reducrion,"yo«mrf/o/Marketing Management, \n\\\mt 11, September 1995. pp. 315-337.12. McGrath (1995);Cooper and Kleinschmidt (1995);

D.C Ancona and D.F. tialdwdi. "Beyond Boundary Spanning:Managing External Dependence in Product Development Teams,"Joumal of High-Technology Management Research, volume 1. number2, 1990, pp. 119-135; and

118 &L RuSFNTHAlSLOAN MANAGEMENT RKVIF-W/WINTI-.R 1997

D.G. Ancona and D.E. Caldwell. "Bridging the Boundary: ExternalProcess and Performance in Organizational Teams." AdministrativeScience Qiuirtcrly. volume 37, December 1992. pp. 634-665.13- Selected research on these issues includes:

K.B. Clark and T, Fujimoto. Product Development Performance(Boston: Harvard Business School Press, 1991); andK. Imai. 1. Nonaka. and H. Takeuchi, "Managing the New ProductDevelopment Process: How Japanese Companies L^arn and Unlearn,in R. Hayes, K. Clark, and P. Lorenz, eds.. The Uneasy Alliance:Managing the Productivity-Technology Dilemma (Boston: HarvardBusiness School Press. 1985). pp. 337-375;

L Dwyer and R. Mellon "Oi^anizational Environment. New ProduaProcess Activities, and Project Omcames,,'' Joumal of Product Innova-tion Management, volume 8, March 1991, pp. 39-48; andD, Dou^eny, "Interpretive Barriers to Successftil PKxiua Innovations inLatgc Eirms," Organization Science, volume 3. May ! 992, pp. 179-202.

14. Cooper and Kleinschmidt (1995).15. The crearion of product concepts is discussed in:C M . Crawford, New Products Management, 3rd edition (Hotnewood.Illinois: Irwin. 1991).

Customer requirements should drive all product design and develop-ment, including the creation of product concepts. There is a growingbody of information on how such requirements ought to be obtainedand translated into product requirements. One familiar technique fortranslating customer requirements into product attributes is qualityfunction deployment (QED). See:

J.R. Hauser and D. Clausing (1988). "The House of Quality."Harvard Business Revietv, volume 66, May']une 1988, pp. 63-73; andG.L Urban and J.R. HatLser. Design and Marketing of New Products,2nd edition (Englewood Cliffs. New Jersey: Prentice-Hall; 1993).

16. Bacon etal. (1994).

17-Bacon etal. (1994); andK.M. Eisenhardt and B, Tabrizi. "Accderating Adaptive Processes:Product Innovation in the Global Computer Industry." AdministrativeScience Quarterly, volume 40. March 1995, pp. 84-110.

18. R.H. Hayes, S.C. Wheelwright, and K.B. Clark, DynamicManufacturing (New York: Free Press, 1988);DwyerandMdlor(1991);and

R, Cooper. "Third-Generation New Product Processes." Joumal ofProduct Innovation Management, voWiinc 1 I.January 1994. pp. 3-14.

19. See Rosenthal (1992);Smith and Reinertsen (1991);Cooper (1994); andR.G. Cooper, "Stage-Gate Systems: A New Tool for Managing NewProducts," Bidsiness Horizons, volume 33. May-June 1990. pp. 44-54.

20. Bacon etal. (1994); andCooper and Kleinschmidt (1995).

21. For a description of pha.se review systems, see:Cooper (1990); and

Rosenthal (1992), chapter 2. See also:M.E. McCirarh. M.T. Anthotiy. and A.R. Shapiro, Product DevebprnentSuccess through Product and Cycle-Time Excellence (Bostoti: Btittenvorth-Heinemann, 1992).

22. An alternative approach that is emerging in the best companies isbased on platform planning and emphasizes that product opportuni-ties are related to the development of product platforms. See:McGtath (1995); and

M.H. Meyer, P. Tertzakian. and J.M. Utterback, "Metrics for Manaj^ngResearch and Development" (Cambridge: MIT Sloan School of Man-agement, working paper 3817. 1995).

23. S.C. "Wheelwright and K.B. Clark, Revolutionizing Product

Developmenti^ew York: Free Press, 1992).Several product developmenc researchers have raised the issue of roles,'e.g.. project tnanagers (Wheelwright and Clark, 1992). and core teamand executive reviews (McGrath et al.. 1992). However, our interest isin looking at how these roles influence the front end of new productdevelopment and what challenges arise as a result of the interactionsamong these roles,

24. ln .some companies that do platform planning in a serious way,one can visualize the development of a platform concept or architec-ture also as a fi^ont-end deliverable.

25. Meyer etal. (1995).26. Wheelwright and Clark (1992).

27. Ancona and Caldwell (1990); andAncona and Caldwell (1992).28. Clark and Fujimoto suggest that in such ca.ses. there is often "littleor no attention to integrating a dear sense of ctLstomer expectationsinto the work of the product development organization as a whole."See:

K.B. Clark and T. Fujimoto. "Tlie Power of Produa Integrity," HarvardBusiness Review, voltime 68, November-December 1990, pp. 107-118.

29. Though not all platforms or pmduct lines c;in plan for multiple re-leases at frequent intervals, proactive planning of product releases a fewyears ahead is desirable. For example, Sony docs not necessarily planmultiple rdeases but achieves die same objective by freezing the productdesign early on. It tlieti begins work on the next product model concur-rently to incorporate changes in customer needs or technology. See:Meyer etal. (1995);

McGrath (1995); andS. Sanderson-Walsh and M. Uzumcri. "Managing Product Families;The Case of the Sony Walkman," Research Policy, volume 24,

September 1995, pp. 761-782; andP.R. Nayak and J.P. Deschamps, Ptvduct Juggernauts (Boston: Harvard

Business School Press. 1995).30. See. for example:R.R. Kaniath and J.K. Liker, "A Second l.ook at Japanese Produa De-vdopment," Harvard Business Revietv, volume 72, November-December1994, pp. 154-170.

31. K.A. Howard, "Postponement of Padcaging and Produa Differentia-tion Lowers logistics Co.'its." in A.K. Chakravarty. ed.. Globalization ofTechmlo^, Manufacturing, and Service Operahons {New Orleans: TulaneUniversity, Goldring Institute, A.B. Freeman School of Business,Proceedings of Symjiosium, 7-8 January 1994).

32. Apparendy. such rc-dundancj' is at the heart of Toyota's develop-

ment success. See:

A. Ward. J.K. Liker, J.J. Cristiano. and D.K. Sobck II. "The SecondToyota Paradox: How Delaying Decisions Can Make Better CarsFaster," Sloan Mamigenmn Ra'iav, volume 36. Spring 1995. pp. 43-61.In the context of design, simultaneously working on multiple subsys-tem/component alternatives generally leads to a faster product devel-opment cycle. We suggest that the same is true for planned and antici-pated redundancy in the face of technological or other risks.

33. Other interrelationships that have been mentioned in previous re-search, e.g.. Bacon et al. (1994). and used at several case study sites in-dude: the need for strategic alignment between product developmentefforts atid overall business strategy-, the direct links between productdefinition and project planning, the close associarion of project plan-ning ;md stafUng policies, and the need to modify the roles and re-sponsibilities of key organizational members as a Rinaion of projectcomplexity and size.

Sl-OAN MANAGEMUNT REVIhW/WlNTtR 1997 KHURANA & ROSENTHAl. 119

34. P. Lawrence and J. l.orsch, Organizations and E/ivironments(Honiewood, Illinois: Irwin, l%9);and

•Clark and Fujimoro (1991).

35. D. Dougherty and E.H. Bowman, "The Eficcrs of OrtjanizarionalDownsizing on Product Innovation." California Mamigenient Review,volume 37, Summer 1995, pp. 28-44.

36. Ward ecal. (1995); andM. Iansiti, "Shooting the Rapids," California Management Revieto,volume 38, Fall 199S,pp. 1-22.

37. This notion of balance also rcHeas our agreement with an aniclcon balancing instinctive and Rilly analytical decision making. See:

A. Langlcy, "Between 'Paralysis by Ajialysis' and 'Extinction by Iastina'."Sloan Management Review, volume ^6, Spring 1995, pp. 63-76.

38. In the "prc-emcrgent" stage, a company has no formal front end,nor does it perceive the need for one; none of the companies we stud-ied fell into this cat^ory. This situation is common either in start-upcompanies in which a few principals make produa development deci-sions informally, or in business units where structured product inno-vation is not yet the hasis for competition. NPD activities for such or-ganizations arc tightly integrated, but often a few senior managers dothis tacitly.

39. See, fot example:

S.L. Goldman, R.N. Nagel, and K. PreLss, Agile Competitors atidVirtual Organizations: Stimcgies for Etniching the Customer (New Yotk:

Van Nostrand Reiiihold, 1995).

40. See Meyer etal.{l995);McGraih (1995); andSanderson-Walsh and Uzumcri (1995).

For a pnsposed new model of the stage-gate system, see:Cooper (1994).

41. A full description of why a company should adopt more than one

front-end solution, and what these solutions might look like, is be-

yond GUI scope. While we do not yet have a Rill map of "compatible

contexts," some of the contingencies we have discovered are; radical-

ness of product, maturity of industry, experience of the business unit

with formal (ronr-eiid processes, small or large firm, and entrepreneur-

ial or conservative firm. We are currently writing a paper that more

ftilly develops this perspecdve.

Reprint 3828

120 KHURANA & ROSENTHALSLOAN MANAGLMLNT REVILW/WIN'IHR 1997