Integrating the Fuzzy Front End of New Product Development

Many companies formulate product strategies, routinely choose among new product concepts, and plan new product development projects. Yet, when asked where the greatest weakness in product innovation is, the managers at these companies indicate the fuzzy front end.1 They recite some familiar symptoms of front-end failure:

• New products are abruptly canceled in midstream because they don’t “match the company strategy.”
• “Top priority” new product projects suffer because key people are “too busy” to spend the required time on them.
• New products are frequently introduced later than announced because the product concept has become a moving target.

Times have changed since 1983 when Donald Schön described product development as a “game” in which “general managers distance themselves from the uncertainties inherent in product development and . . . technical personnel protect themselves against the loss of corporate commitment.”2 Since then, new product development has become a core business activity that needs to be closely tied to the business strategy and a process that must be managed through analysis and decision making.3 Now, general managers cannot distance themselves from the uncertainties of product development, nor can technical personnel protect themselves against corporate commitment.

As enhanced capabilities for concurrent engineering, rapid prototyping, and smoothly functioning supplier partnerships have helped reduce product design and development times, management attention has begun to shift to the cross-functional front-end strategic, conceptual, and planning activities that typically precede the detailed design and development of a new product.4 Here, new product ideas gain the shape, justification, plans, and support leading to their approval and subsequent execution. Yet, despite widespread recognition of the front end’s importance, there has been limited systematic examination directed at improving its effectiveness.

Our exploratory study of front-end activity in eleven companies highlights best practice based on our assessment of seven critical activities. We begin by taking a systems view of the front-end process based on existing academic and practitioner literature. After discussing how companies should manage the front end as part of a normative model of the process, we use data from case studies to identify challenges and solutions.5 Next, we describe an approach for creating a successful process and present a checklist and diagnostic for front-end practice.

What Is the “Front End”?

Prior research has focused on the success factors for new product development (NPD). While many of these factors relate to design execution and project management issues, some pertain to the front end.6 Consistent with Roberts’s model, we classified the front-end-related success factors identified in prior research into foundation and project-specific elements.7 The distinction is important because the two require different skills and levels of effort. Also, without adequate foundation elements, product and project success becomes a matter of luck. Project-specific activities focus on the individual project and require the project team’s effort to ensure a useful product definition and project plan. These include a product concept statement and evaluation, product definition, and project planning. Foundation elements, on the other hand, cut across projects and form the basis for project-specific activities. Thus they typically require enterprisewide support, senior management participation, and a cross-functional effort.

Foundation Elements

Without a clear product strategy, a well-planned portfolio of new products, and an organization structure that facilitates product development via ongoing communications and cross-functional sharing of responsibilities, front-end decisions become ineffective.8 Achieving these preconditions provides a foundation for streams of successful new products.

Key product strategy elements include the formulation and communication of a strategic vision, a product-platform strategy, and a product-line strategy to support the go/no-go decision for a new product.9 Previous research suggests that familiarity with the product strategy enables appropriate decisions on NPD timing and target markets and also an assessment of the fit between the product and the core competence of the business unit.10

In addition to a product vision, business units need to plan their portfolio of new product development activities, which goes beyond the traditional marketing view of having a product for every segment, market, and price point. Portfolio planning should map all new product initiatives across the business to balance risk and potential return, short and long time horizons, or mature and emerging markets. At the same time, the portfolio plan should ensure consistency with the product and business strategy.11 If well done, it facilitates the allocation of scarce resources to new product development projects.

An essential precondition is establishing the organization structure for new product development. Decisions on structure, communication networks, and roles are made at a business-unit level. Research has highlighted several requirements for the product development organization and its functioning,12 such as using a matrix or project form, organizing NPD around core business/product teams rather than traditional functions, using design and communication tools including information systems, and establishing controls and incentives as rewards.13

Project-Specific Elements

Product-specific front-end activities help clarify the product concept, define product and market requirements, and develop plans, schedules, and estimates of the project’s resource requirements. However, they stop far short of creating detailed designs and specifications for the product and its components.

The product concept is a preliminary identification of customer needs, market segments, competitive situations, business prospects, and alignment with existing business and technology plans. Research suggests that the product concept should be clear so that managers can sense whether the newly defined opportunity seems worth exploring.14 Managers need to understand customer needs and identify the potential technologies and applications to satisfy them.15 For tangible products, the product concept is usually illustrated with a sketch or three-dimensional model. Because such concepts are relatively inexpensive to produce, managers often create several before selecting one to fully design and develop. Early targets —measured in product cost, product performance, project cost, and time to market — set the stage for generating various product concepts.

The product definition, an elaboration of the product concept,16 incorporates judgments about the target market, competitive offerings, and the time and resources for bringing the new product to market. The definition activity includes identification of customer and user needs, technologies, and regulatory requirements. These lead to a choice of product features and functions, target market segments, and design priorities. Research on the implementation of the front end indicates that an explicit, stable product definition and an understanding of the trade-offs among customer requirements, technology, and resource/cost constraints are important factors for success.17

Project planning includes project priorities and tasks, a master schedule, projected resource requirements, and other supporting information. Here, it is critical to communicate the project priorities, provide adequate resources, and anticipate contingencies. And, despite progress in new product development practices, typical systems do not adequately address these critical issues.18

The Front-End Process

We take a process view of the front end because earlier studies and our preliminary research suggested that the individual activities, while logically interrelated, often are treated independently.19 Accordingly, we present a systems view of the front end (see Figure 1). This process description is consistent with growing empirical evidence of the need to simultaneously consider overall product strategy (foundation elements) with project-relevant input such as product ideas, market analysis, and technology options.20 Thus understanding the interrelationships between the activities is as important as the activities themselves.

Product strategy and portfolio plans should drive the complete new product development effort, in conjunction with the capabilities and competencies of the product development organization, with its inherent assumptions about roles, communications, and culture. These elements are thus preconditions or foundations for the explicit activities in new product development. Many companies implement a formal phase-review management system to define and guide the explicit project-specific activities; this review process involves the process itself, roles that make it work, and primary deliverables.21

· Phases of the Front-End Process.

Companies generally begin work on new product opportunities (often called “pre-phase zero”) when they first recognize, in a semiformal way, an opportunity.22 If the newly defined opportunity is worth exploring, the company assigns a small group, sometimes including suppliers, to work together on the product concept and definition (phase zero).

In phase one, the company assesses the business and technical feasibility of the new product, confirms the product definition, and plans the NPD project. Thus the development team identifies the new product, its development, and the business rationale for proceeding. The front end is complete at the end of this phase when the team presents the business case and the business unit either commits to funding, staffing, and launch of the project or kills the project.

• Front-End Roles. A core team (including the project leader) and an executive review committee of senior functional managers responsible for making the go/no-go decision typically conducts the process we’ve described. During phase one, if not sooner, companies assign individuals from all functional areas as members of the core team for the product development project. Normally, if a company approves the project at the end of phase one, a full complement of people to design, develop, test, manufacture, and launch the new product supplements the core team. Previous studies have indicated that team structure varies in composition, size, and leadership.23 Often, the core team includes selected suppliers as partners; their knowledge of technology, costs, and design and manufacturing lead times can contribute to product definition and project planning.
• Primary Front-End Deliverables. The front-end activities result in the product concept (clear and aligned with customer needs), the product definition (explicit and stable), and the project plan (priorities, resource plans, and project schedules).24

Front-End Challenges and Solutions

To understand the front-end processes and practices at fifteen business units in eleven U.S., Japanese, and European companies, we interviewed more than seventy-five managers (for our research approach, see the Appendix). Our study focused on incremental innovations — the majority of NPD efforts. Accordingly, our findings deal with improving the performance of existing products or extending them to new applications, rather than with developing radically new products.

We have grouped the typical practices that characterize the foundation elements and project-specific activities into three implementation clusters — high, medium, and low (see Table 1). This analysis of our data also supports our earlier literature-based classification of the three foundation elements and the three project-specific activities. Our analysis does recognize an additional activity: adding value-chain considerations to the front-end process.

We found significant gaps in how the case study companies implemented the seven front-end elements, even for those companies that claimed to have the front-end product generation processes we described earlier (see Table 1). Even the companies that prepared their own detailed process descriptions generally didn’t avoid problems that they could have resolved at the front end. In fact, only companies F and, possibly, G and J could claim to have most of the capabilities for an effective front end.

Foundation Elements at the Case Study Companies

Next we discuss in detail how the case study sites managed the foundation elements in order to provide insights for companies trying to improve their NPD efforts.

· Product Strategy.

Our research suggests that despite their intentions, very few companies have clear product strategies to guide their decisions on new product opportunities. In our sample of eleven companies, we rated only two as outstanding (F and G) and two as satisfactory (D and J), while the remaining seven were seriously lacking. We identified several deficiencies in formulating and articulating a product strategy and the connections between product strategy and the core NPD activities (see Figure 1):

• There were product development teams and product managers, but no one was in charge of formulating a product strategy, even at the senior management level.
• Several of the companies made new product development decisions based on project-specific criteria rather than considerations of strategic fit.
• Business strategy was not specific to markets and products.
• R&D, largely insulated from the product development group, funded projects based on superior technology rather than on their potential to satisfy particular product requirements.

The outstanding companies in our sample had countered these deficiencies. The power of a clear product strategy was evident at company F, where we studied the fourth in a series of eight planned sequential product launches based on a common platform.25 The company had designed this platform to meet explicit customer, market, and technology guidelines, with which each successive release was consistent. The vision of the business, product, project, and technology enabled successive product development teams for this platform to consistently deliver a product that met every target.

· Product Portfolio Planning.

More than a third of the companies studied did not plan a product development portfolio. Even when they did, planning at all but two of the research sites, F and J, was sporadic and incomplete. This neglect can be traced to a combination of vague product strategy, measurement difficulties in establishing risk/return profiles, and ambiguous overall responsibility.

While company H traditionally lacked a clear product strategy, senior managers had begun to realize that they were in a mature, threatened business. In response, they made their functional managers aware of basic portfolio planning, with encouraging results. Their portfolio now includes a combination of different products with both established and new technologies, instead of traditional projects with incremental improvements to the familiar product line. The company also enhanced the role of the executive review committee, known as the product approval committee, to include assessment of the match between a new product concept and the existing product portfolio in risk, time horizons, and markets.

In contrast, company F — which is very successful in its business — constantly monitored the parameters of its product development portfolio, such as time horizon, risk, expected returns, required investments, and needed capabilities. Senior managers and project and product managers continually discussed the nature of the development portfolio and additions to make.

Regardless of the methods a company uses for new product portfolio planning, it needs to be part of an integrated front-end process. Our research suggests that there is often a discontinuity between portfolio planning and the front end of the traditional process. For example, if a project is killed at the front end because of technological infeasibility, the resulting gap in the development portfolio will become apparent only if front-end activities and portfolio planning are linked.

· Product Development Organization Structure.

We focus here on three roles at the front end — the project leader, the core team, and the executive review group — and on related communication structures.26 At the companies that measured best along this dimension (F, G, and J), the project leader was responsible for promoting the interests of the project and the core team right from the start. This role included lobbying for support and resources (being an “ambassador”) and coordinating technical or design issues.27 These project leaders initiated such communication early during the product/project definition and planning stages. At company F, project managers established communication channels, role definitions, and cross-functional mechanisms for the development team, as part of the product and project definition.

All the companies in our sample, except for companies B and E, had a cross-functional core team do the analytic work of product definition and project planning. However, the role of the team varied among the companies and development projects. Company A’s first autonomous product development team was successful because four ambitious, creative team members communicated well. However, subsequent teams were not as successful because the core team members were unclear about their responsibility in creating the product concept and definition. In contrast, teams at company F operated more systematically and successfully. A small core team including the idea champion, a senior manager, and a potential project leader met early on and negotiated key roles and responsibilities. This nucleus group then recruited the full team and ensured that all members agreed on the definition of roles and responsibilities. This structure of team roles and responsibilities was part of the product concept statement and was formally acknowledged in the product definition and project planning documents. Establishing the core team early, clearly defining roles and responsibilities for the team, and facilitating supporting communications played a major role in company F’s success both in new product development process and the market itself.

Product success appears to be strongly associated with establishment of a cross-functional executive review committee. Only companies F and J had such a review. Company A’s review committee focused on technical issues, with the result that executives failed to have a holistic perspective. In contrast, the committee at company F used each phase review to develop strategic and operational skills and establish norms for communication and consensus building. It also guided the core team while making critical choices and trade-offs or making decisions that might have an impact on the business unit’s strategy beyond that particular product. At both companies F and J, the executive group worked like a business team rather than functional representatives, consistently developed product strategy and engaged in new product portfolio planning, and formulated explicit project priorities (time, cost, and quality).

For an effective front-end process, the roles of the project leader, the core team, and the executive review committee must complement each other. Explicitly defining these roles by answering the following questions will make the front end less “fuzzy”:

• Should the core team resolve product definition and project planning issues or refer them to an executive committee?
• Who is responsible for ensuring that product definition and concept testing are balanced between thoroughness and speed?
• Who should ensure that resources are allocated to a project, as specified in the project plan?
• Who should identify emerging technologies for inclusion in future product platforms?
• Who has the authority to ensure that products developed by several business units or a unit and one or more “partners” are aligned along product/component interfaces, development schedules, market focus, and technology commitments?

Project-Specific Activities at Case Study Companies

Now we concentrate on project-specific activities at the front end: clarifying the product concept, stabilizing the product definition, considering the value chain in the product definition, and defining and planning the front-end project.

· Product Concept.

Our research revealed that clarifying the product concept at the front end was surprisingly difficult. Only four companies (C, D, F, and G) had succeeded in consistently developing clear, explicit, and precise descriptions of the product concept. At several companies, the concept was unclear because senior managers did not communicate their expectation of the product’s core benefits, choice of market segments, and pricing to the development team.

One company resolved this gap between management’s vision of the product concept and the team’s understanding of it by setting specific criteria for the features appropriate to the product. It created a database for new product features — based on various inputs from field service, special customers, R&D, marketing, and customer feedback. It then assessed these inputs in phases zero and one, based on senior management’s vision of the product, engineering feasibility, market needs, resource requirements, price targets, and schedule — and classified them into “red,” “green,” and “yellow” items. The company would never pursue red items in the current program (but could consider them for the next-generation product). Green items were necessary for the current product; the company chose them based on need, feasibility, and other constraints. Yellow items needed more evaluation, so the company postponed them for subsequent release.

At several case study sites, the product concept was unclear because the companies did not clearly understand customer needs. When such problems recur, as we found at companies H and K, products lack what Clark and Fujimoto call “external integrity.”28 To make customer expectations and product features more consistent, sophisticated companies (such as companies C and F) try to look beyond the customer’s “voice” to “action,” by using techniques such as videotapes of customers’ use of existing products.

· Product Definition.

All the companies in our study realized the pivotal importance of the early product definition. Yet most had failed to generate clear, stable definitions. While rapid shifts in technology and markets make it impossible for some companies to freeze the product definition, most of the companies studied acknowledged the difficulties this caused in the execution stages of product development projects and the high associated costs. In fact, only managers at companies C and F felt that they had developed approaches for dealing with instability and change.

For technology-driven companies (especially company H), delays in product definition entailed the risk of an unstable, expanding definition in which design engineers continued to add unneeded complexity. Managers at companies C and F made a concerted effort to freeze the product definition early on. For them, the challenge was to balance the requisite flexibility with the avoidable uncertainty.

Company F discovered a creative solution for keeping up with and capturing market information while minimizing changes in the product definition —what we call the “missed elevator” approach. The program manager realized that technological or feature enhancements for any product would never end. He required the product definition to include new features and feasible solutions to customer needs, as long as they could definitely be achieved by the planned milestone for that product release. If a customer need or technology-driven feature “missed the elevator,” it would go into the next product release or “elevator.” This approach to managing product development by having multirelease platform planning may become the next form of product development and management. Not only does it help achieve a balance between stability and flexibility, but it also leverages technological strengths and organizational resources.29 Thus more companies now include, in their front-end deliberations, the definition of multiple-release products, in which each release intentionally involves only a moderate level of new technology development.

· Value Chain Considerations.

While NPD research has highlighted the suppliers’ role in new product development, we found that some companies have a broader value chain perspective at the product concept and definition stages.30 This becomes necessary as product designs and market delivery systems are more competitive and complex. And customers do not buy only the tangible product but a package that includes the product itself, the company, the brand image, the sales interaction, the delivery process, the after-sales service, and the follow-up relationship. The development team should envision and plan for this package at the front end; otherwise it may ignore downstream requirements and not design products for ease of distribution, installation, or repairs.

We found that these practices, while familiar at the execution stage, are less aggressively and creatively pursued at the front end. Of the eleven companies in the study, only four (A, D, F, and J) were adequate along this dimension. We observed several failures and some creative solutions. Company A, a special industrial products manufacturer, faced new maintenance problems and poor telecommunications support in providing field service. As a result, field service engineers became regular members of the core development team at the front end. At company D, the new product development team consulted with so-called “customer supply specialists.”

As another example, Hewlett-Packard’s printer division had thousands of stock-keeping units (SKUs) for its products being shipped to different parts of the world. HP resolved this problem of excess variety with “design for postponement”; it redesigned the product so that only the core printer SKU was stocked in regional distribution warehouses. It stocked attachments such as power packs, power cables, connectors, and even instruction manuals in different languages at the distribution points and assembled the final package for shipment only after it received a firm shipment order. In fact, it designed the packaging itself so that it could easily insert and assemble all the attachments. The result was enhanced flexibility and reduced inventory costs, along with the needed product variety.31 For all subsequent product development efforts, HP has routinely included downstream considerations at the front end.

· Front-End Project Definition and Planning.

At this part of the front end, we observed confusion about project priorities, incomplete resource planning, and inadequate contingency planning. Our discussions with core team members and project leaders led us to believe that fuzzy project priorities were the single most important reason for NPD delays, product overengineering, and product-strategy mismatches. For example, company A initiated its mid-range product as a cheap-technology, low-performance version of its high-end product. Yet management had always visualized a cheap-technology, high-performance product. Finally, when the product came on the market several months behind schedule, it exceeded its performance targets but no longer met its unit-cost goals. At another company, managers solved this common problem by comparing — at the front end —three kinds of project priorities for any new product development project: scope (product functionality), schedule (timing), and resources (cost). Senior management, the core team, and the (as yet unappointed) project leader at the pre-phase zero stage decided the relative ranking of the three priorities for the project’s duration and communicated it to all project participants.

Companies must anticipate resource requirements, train people to acquire the necessary capabilities, and then ensure needs-availability matching based on project priorities. Executives repeatedly told us that they had too few people to staff their many NPD projects. At company J, managers used a capacity matrix to assess and assign staff. Senior managers selected the best projects, set goals, and reserved resources. Company 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 irreplaceable people who were in great demand for every project. When planning a next-generation product, the managers realized that the team member they wanted was heading a current project. To avoid such problems in the future, management resolved to both train more people for such assignments and also plan early for staffing and skills requirements.

Companies can manage the risks of new product development with thorough contingency planning — generating multiple product concepts, developing alternative technologies in parallel and, in some instances, even creating competing designs for products or subsystems.32 Yet, surprisingly, we found that most companies (including company F) focused contingency plans mostly on regulatory issues such as safety or environmental requirements. Apparently, project planners assumed that they would find technology solutions without considering cost and quality. When the timing of a new product introduction is important, reasonable back-up plans are needed to avoid delayed market launch. One approach is to build in contingent product features in case the planned ones do not work. Taking risk management seriously and linking product definition activities with project planning can lead to appropriate contingency plans.

Recognizing Interrelationships

Next we discuss several critical interrelationships among individual success factors and approaches for managing them.33 Our examples are from company F, which had the most effective front end of the cases studied.

• Companies should consider product strategy and the product development portfolio at the start of the project-specific front end. Company F held a kickoff meeting even before it had refined the concept and assembled the full core team. Attendees included senior managers, the idea champion, and some core team members. While much discussion focused on the basic product concept, it also included how the concept filled a gap in the business strategy and how it related to and compared with other products and ongoing projects. As a result, subsequent problems of mismatches between the product and the product strategy or shortage of project staffing were rare.
• Companies should have a clear product strategy to enable a stable product definition. Everyone at company F accepted the notion that product strategy should guide technology choices and selected product features. Thus the company used its multirelease product strategy to simplify the definition: its adoption of the “missed elevator” approach simultaneously encouraged stable technology and feature choices that were governed by a long-term vision over several product releases, while facilitating new releases on time.
• Companies should integrate portfolio planning and NPD project planning. Company F had established two distinct but formally linked planning processes. The strategic planning process involved managers from various functions and considered product strategy, product development portfolios, and overall resources. Thus portfolio planning yielded long-term commitments that the managers could invoke when planning staff requirements and project priorities for a specific new product concept. They implemented two important practices when planning individual projects: establishment of schedules and allocation of staff and budgets, and specification of inputs such as technology from other business groups. First, they made the strategic business plan available to all core team members and considered the product definition in the context of the strategic business plan. Second, senior managers oversaw the core team’s decisions and actions. For example, the project manager may be a part of the strategic business planning process or may report to someone who is.

A Well-Engineered Front-End Process

How can a company improve its front-end practices to achieve success in new product development? Is it enough to improve the activities we have described? We suggest that best practice in new product development goes beyond simply adopting these activities. Success depends on how companies integrate dimensions and elements of product development.34

Our research highlighted certain challenges in integration of the front end beyond the obvious need for cross-functional effort. First, because project-specific activities build on foundation activities, companies should ensure that the foundation elements are aligned with the product development process and project-specific activities. Second, they should ensure consistency between strategic and operational activities. The challenge is to make strategy explicit enough to guide day-to-day choices for new product development. We found the integration of these two factors was rare but extremely potent. At the companies studied, we observed several kinds of integration problems:

• Senior managers sometimes delegated the formulation of a product strategy to product and R&D managers.
• The product development staff often made decisions that affected other products and business unit strategy. (While the core team faces technical uncertainty about the product and manufacturing and distribution processes, resolving cross-project issues or providing guidelines should be senior management responsibilities.)
• Managers in various functions and organizational levels rarely ensured consistency and links among R&D activities, product strategy, and current product development. (Huge R&D investments can be wasted by pursuing superior technology capability unnecessary to the organization’s espoused business strategy.)
• Managers frequently took on product development projects without committing adequate resources. (Often there is a misconception that product development staff working on multiple projects improves efficiency. The result is long delays in product launch and lost revenues. With ongoing downsizing in many companies, this kind of neglect is becoming chronic.35 Senior managers need to help product and R&D managers understand a project’s relative importance.)
• Senior managers did little to measure and reward cross-functional teamwork. (Front-end participants need to know that management values their contributions.)

Balancing Front-End Explicitness and Flexibility

Management of the front end also requires a balance between getting things right and being flexible during NPD execution. Other front-end elements and activities should also be balanced. There is a natural tension between planning to reduce risk and responding to inherent uncertainties. For example, we suggest that product strategy and portfolio planning be explicit, yet we recognize that some subsequent shifts in the product definition are inevitable, forcing contingent actions. Furthermore, postponing the final decisions at the front end by continuing the development of parallel concepts or solutions may reduce uncertainty.36 While our research did not focus on this issue, we believe that there must be a balance between front-end planned activities and ongoing iteration during the NPD project, between making “final” decisions early and intentionally keeping open parallel alternatives, and between establishing product development targets through analysis and working by instinct alone.37

Diagnosing Front-End Activities

Based on our study findings, we propose that companies evaluate their front end on degree of formality and the integration of activities. The dimensions —formality and process integration — can be measured on a checklist (see Table 2). The items are derived from previous research and our case study findings on the need for formality and integration at the front end. The diagnostic statements evaluate the explicitness and formality of front-end practices. The statements on integration document how well these and other front-end activities are integrated.

A senior business unit manager such as the vice president of R&D, chief technology officer, or director of new product development should assess business practices and then calculate the score of the business unit, counting a check for any item as one point. The sum of the scores on the formality statements gives the formality score; the sum of the integration statements, the integration score. The manager can then map the score on each dimension on the front-end capability map (see Figure 2).

The mapping indicates how well (or poorly) a business unit is doing along the two dimensions of formality and integration. Our research indicates that world-class companies score eight or more on both dimensions. Companies that score three or less on either dimension have a deficient front end and are likely to have major problems with their product development efforts. Senior management needs to find ways to improve these efforts; the checklist is a first step to understanding where and what to improve. What is more difficult is to understand how. In the next section, we discuss how companies and business units can plan a transition to a better-managed front end.

Managing the Transition

All the companies we studied were moving toward a more explicit, integrated front end. They were trying to build complementary capabilities to support the critical go/no-go decisions and development plans for new product concepts. Yet each was taking a different path at a different rate.

Stages of Evolution

We see three stages in the product development front end, not including the stage in which a company has no formal front end — the pre-emergent stage.38 The next stages are “awareness,” “islands of capability,”and “integrated capability” (see Figure 3). The triggers to reach the awareness stage from the pre-emergent stage are typically growth, additional product line complexity, or competitive pressures for either more product innovation or lower product development costs. In any case, at the awareness stage, companies recognize the significance of the front end but have little capability associated with it. They score poorly on both the formality and integration dimensions, as did companies B, E, and H in our sample.

· Islands of Capability (Stage Two).

Our study suggests that most leading product innovators are at the islands of capability stage, including companies A, C, D, I, J, and K. These companies realize the potential of having a well-managed front end and have some of the required capabilities, but inconsistently. Missing are many elements of front-end process integration. Companies find it easier to improve the formality of this process than to address the subtle gaps in integration.

How can companies evolve from “awareness” to “islands of capability”? That depends on what the business unit has already achieved and what capabilities it needs, given its industry and company. We identified two broad approaches to achieving stage two. First, those companies that have barely begun to understand the importance of the front end — for example, company H — should recognize that product development is a senior management responsibility. Managers should carry out several structured activities, such as the diagnostic test. Second, those companies that recognize the importance of the front end — such as companies B and E — should formally and systematically conduct various front-end activities. Those activities include having an explicit product definition, estimating technology requirements early, and planning resources.

· Integrated Capability (Stage Three).

Front-end product development integration, the hallmark of stage three, is quite rare. We believe that most companies don’t understand that this stage is significant in terms of required capabilities, and achieving it takes concerted effort. At the few companies with this degree of process integration — companies F, G, and, to some extent, J — analysis and decisions have been both explicit and rigorous, and all front-end activities are managed as a single process. Stage three companies execute NPD projects better and faster than their competitors and are more likely to introduce a winning product. One can honestly say of these companies that “well begun is more than half done.”

How can companies make a transition from “islands of capability” to “integrated capability”? Some stage two companies have much of the required formality but not necessarily the degree of integration to yield substantial benefits. Most stage two companies should focus on understanding the various dimensions of integration. Among our sample, we identified three clusters of companies that required somewhat different approaches to get to stage three. These three clusters represent generic front-end states and problems that many companies face.

While companies in the first cluster, A and K, have passed stage one, they still have a long way to go. They need to focus closely on senior management involvement in creating a product vision. Improvements in front-end formality and integration, while not easy, will be easier if the product development group can understand its purpose better.

Companies C and D make up the second cluster. These companies will realize improvements from refinements in the front-end process. They need to make their front-end activities more explicit and, in particular, understand how to better manage their technology and resource requirements. Once they progress on these dimensions, they can focus more on cross-functional and integration problems.

The third cluster of companies, I and J, were the most advanced among the stage two companies. Front-end explicitness is not their main problem. Instead, their challenge is to work on cross-project issues and technological uncertainties. By having close ties among strategic planners and project personnel, they will understand the links among projects and anticipate matches or mismatches between future market needs and current technology and product plans. They need to establish closer connections between their R&D and product development groups so that they can anticipate overall technological progress and product-specific technological uncertainty.

· Sustaining Stage Three.

Clearly, reaching stage three is not easy; even those companies that have achieved it continue to require improvements. Changes in competition, technologies, tools, and organizational structures and relationships may need changes in at least some front-end practices.39

How can companies F and G improve? We found that these companies had minor deficiencies at their front ends (by using the diagnostic test in Table 2). Yet, the companies have potential for improvement. For example, knowing what to finalize and approve in product concept and definition, and what to keep flexible and open to change is important. Achieving a proper balance calls for more than just personal intuition and tacit understanding. Making explicit the connections between product requirements and internal technology development remains an elusive capability. And maintaining continuous links among business-unit vision, product strategy, technology, and new products is an ongoing challenge. Managers at stage three companies need to evaluate and apply innovations such as developing carefully planned product architectures and platforms or adapting a front-end process — such as Cooper’s — to deal with the dynamics of current technological, market, and organizational realities.40

Conclusion

Most companies have unnecessarily fuzzy front-end systems. The best way to integrate the front-end process is to use an overall systems perspective and thoroughly assess the current state of the front end. Fixing what appears to be broken requires the ability to see the interrelatedness of issues and the development of a coherent agenda.

We caution against oversimplification: not all companies should adopt the same front-end solution, and most will need to adopt more than one. For example, we found that companies used executive reviews in different ways with mixed success; some case study companies changed the role of the executive review group for different products. In general, company size, decision-making style, operating culture, and frequency of new product introduction are some factors that are critical to a preferred front-end solution. We discourage companies from importing a particular process or procedure that has worked well for others unless their contexts are clearly similar.41

Managing to become less fuzzy means integrating seemingly disparate but related strategic and operational activities, typically crossing functional boundaries. The solution must be balanced with the emerging realities of business and the environment. With proper diagnosis, consensus, and commitment, companies can enhance product development performance over the long term.

Appendix

We conducted our research between April 1994 and April 1995.a Of the sixteen companies invited to participate, eleven accepted. We chose companies based on whether they had a product-generation process and if they had NPD processes for one to eight years. Our final sample includes seven U.S. and four Japanese companies (all Fortune 500 companies or their equivalent in Japan) in various industries ranging from consumer packaged goods to electronics to industrial products (see Table A for more information on the specific industries). There are seven U.S., six Japanese, and two European business units (we interviewed managers at multiple business units at two companies). Business-unit size ranged from $300 million to $2.5 billion 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 classified the companies as “active” or “neutral”; the active sites participated very closely in the research, and we had open access to them. At the neutral sites (companies B, E, G, and K), we had only one opportunity to get the data directly, i.e., only one visit or series of interviews. Naturally, the data from these companies are less detailed, although we obtained the essential information.

We adopted an exploratory and “action-oriented” approach because we iterated among data collection, analysis, and feedback. We conducted our research at three to four company sites, analyzed data, presented partial results to a group of participants at “dissemination” workshops, wrote reports for their review, revised our knowledge base and conceptual models, and went on to the next case sites. Thus, implicitly and by design, we adopted the grounded theory approach.b

We spent more than 200 hours interviewing more than seventy-five managers. On average, for each active site, we spent between eight and forty hours interviewing from three to twenty-five managers; for each neutral site, we spent eight to fifteen hours interviewing up to eight managers. We held four days of dissemination workshops with more than twenty-five different managers from several research companies. We interviewed managers (ranging from functional managers to company president) from marketing, R&D, software development, engineering, manufacturing, field service, finance, accounting, strategic planning, product management, NPD process owners, and corporate/business-unit general management.

For most of the case sites, we used secondary data collection in an effort to understand the industry and company background. We then adapted our basic research and interview questions to match the company profile. Thus most of the interviews were largely unstructured to support our exploration of the relatively undefined nature of the front end of product development.

The basic unit of analysis for our cases was the process of the front end of new product development. However, due to access, confidentiality, time, and contrasts, we used several approaches to understand and evaluate the process. As Table A shows, our interviews took two different forms: (1) a study of individual NPD projects (multiple projects at each company) and (2) an in-depth study of business unit practices with regard to the process adopted for the front end of new product development. (We included multiple business units at two companies because these business units were in widely different markets or technologies, or because they were perceived to have distinctive front-end NPD practices.)