The Product Development System

Abstract

This chapter shows the particularities of the Product Development System, with special emphasis to the Product Development Process (PDP). PDP itself is people-based, complex, and non-linear, with high ambiguity and uncertainty. Consequently, a wide spectrum of variables can affect its success, and, not surprisingly, over time, over budget and low quality are commonplaces on PD projects. By discussing the PDP characteristics and its consequences, we aim to show that having a high performance PDP is not an easy task to any company; therefore competitive advantage comes from accepting these particularities and understanding how they affect your particular PDP. Far from neglecting these particularities, the lean company deeply understands them, how they affect its particular reality, and shape its PDP to exploit its strengths and avoid its weaknesses.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

This chapter shows the particularities of the Product Development System, with special emphasis to the Product Development Process (PDP). PDP itself is people-based, complex, and non-linear, with high ambiguity and uncertainty . Consequently, a wide spectrum of variables can affect its success, and, not surprisingly, over time, over budget and low quality are commonplaces on PD projects. By discussing the PDP characteristics and its consequences, we aim to show that having a high performance PDP is not an easy task to any company; therefore competitive advantage comes from accepting these particularities and understanding how they affect your particular PDP. Far from neglecting these particularities, the lean company deeply understands them, how they affect its particular reality, and shape its PDP to exploit its strengths and avoid its weaknesses.

1 Introduction

The Product Development System (PDS) is an organizational system that manages both the product portfolio and each individual product development. A high performance PDS, therefore, is capable of consistently articulating market opportunities that match the enterprise’s competencies and executing the Product Development Process (PDP), thereby guaranteeing that progress is made and value is added by creating timely results [1].

The PDS, thus, is the interface between the enterprise and the market, being responsible for the identification, and even the anticipation, of the market’s needs in order to propose solutions to fulfill those needs [2, 3].

According to the General Systems Theory [4, 5], the PDS falls in the category of open systems, since it has the characteristic of influencing and being influenced by the environment (as opposed to closed systems, which do not allow feedback). As any system, the PDS is composed of (Fig. 1.1): (1) inputs—the material, energy, or information that enters through the boundaries of the system; (2) outputs—the material, energy, or information that passes through the boundaries of the system; (3) process or throughput—the process of conversion or transformation of inputs into outputs; and (4) the environment that is outside the boundaries of the system.

Fig. 1.1

Generic system’s elements

Every system performs a purposeful action, which is the function, and each element of the system interacts at least with another one: the PDS purpose is performing the Product Development Process (PDP). Through the PDP, the information is turned into specifications, or some sort of “product recipe,” to be produced. Ulrich and Eppinger [3] define Product Development (Process) as the set of activities from the market opportunity perception to the production, sale, and delivery of a product.

To illustrate, Fig. 1.2 presents some PDP models found in the literature, and how their scopes relate to the market life cycle of a product [6]. This cycle includes all stages from the product conception until its discontinuity, while the enterprise works to make and keep the product competitive.

Fig. 1.2

Product development process models

Development Stage—Comprises the PDP activities, from the identification of the market’s needs, concept development and product and process engineering that end with a product, a process, and any mix of products and processes that can be delivered, sold or produced. During this stage Integrated Product Development (IPD) , Systems Engineering (SE), and Project Management (PM) play important roles.

Introduction Stage—This stage of the cycle is normally the most expensive for a company launching a new product. The size of the market for the product is small, which means sales are low, until you increase the market. On the other hand, the cost of research and development, consumer testing, and the marketing needed to launch the product can be very high, particularly considering a competitive sector. Successful products are the ones that capture the aspects valued by early adopters, and that give strong support to marketing communications seeking to build awareness and to educate potential consumers about the product.

Growth Stage—The growth stage is typically characterized by a strong growth in sales and profits. The company can start to benefit from economies of scale in production, increasing the profit margins, and the total profit. As a result, more money is invested in promotional activities, maximizing the potential of this growth stage. Competition also begins to increase which in turn leads to price decreasing. As a strategy to maintain product quality, additional features and support services may be added. Therefore, a product designed considering the whole value chain is more flexible to these adaptations.

Maturity Stage—During the maturity stage, the product is established and the company’s objective is maintaining the market share it has built up. This is probably the most competitive time for most products and the company must invest wisely in any marketing they undertake. Product modifications or improvements to the production process, which might give some competitive advantage, shall also be considered. Modular, design for manufacturing , and assembly products give the company advantage at this stage.

Decline Stage—Eventually, the market for a product will start to shrink, and this is what’s known as the decline stage. This shrinkage could be due to the market becoming saturated (i.e. all the customers who will buy the product have already purchased it), or because the consumers are switching to a different type of product. While this decline may be inevitable, it may still be possible for companies to make some profit by switching to less-expensive production methods and cheaper markets, or finding new uses for the product.

In order to allow for comparative analysis, the PDP models in Fig. 1.2 were represented: (1) as sequential processes, even though they might have several cycles, parallel tracks, and fuzzy frontiers; and (2) on the initial life cycle stages, although additional development can be made later as a way to evolve the product or fix problems, adapting it to new requirements and postponing the end of its life. Analysis of the processes’ phases presented on Fig. 1.2 highlights:

• (1) Clark and Fujimoto’s [7] proposal is focused on execution (engineering), and only partially (in gray) considers the interface with manufacturing and ramp-up;

• (2) Wheelright and Clark [8], though keeping the execution focus, consider a higher participation on the ramp-up;

• (3) Ulrich and Eppinger [3], on the other hand, explicitly consider the planning (and not implicitly on the conceptual phase);

• (4) Anderson [9] includes the product follow-up after the market introduction;

• (5) Cooper [10] describes in detail the financial and market concerns;

• (6) Rozenfeld et al. [2] broaden the PDP scope to encompass the whole product life-cycle, including the developments that will evolve and keep the product competitive in the market until its discontinuity; and

• (7) The value creation framework proposed by Murman et al. [1], though not a development process, resembles the PDP models very much, making a link to the lean philosophy .

• (8) This book’s PDP, which is defined in sequence and further described in Chap. 9.

Product Development Process (PDP)

: The set of activities beginning with the perception of a market opportunity aligned to the company’s competitive strategy and technical capacity, and ending in the production, sale, and delivery of a product, while considering all aspects that will evolve and keep the product competitive in the market until its discontinuity.

Product: All the results from the PDP, not limited to physical products, but also encompassing services, product-as-service, and even complete value chains, which are aimed to fulfil the customer and user needs.

By considering the results from the PDP as “product”, whatever is the shape they take, the PDP becomes more aligned to the lean philosophy. As presented in Chap. 4 and further detailed in Chap. 10, a Lean Product Development Process aims to fulfill the value pulled by the stakeholders . Depending of the chosen value delivery architecture (see Chap. 11), this value is delivered through physical products, services, or any mix of product and services. Sometimes the defining of a completely new value chain and/or business model is necessary to deliver the pulled value.

By considering the complete product lifecycle the PDP takes into account all aspects the product is going to face through the lifecycle stages. This approach is aligned to reducing the total cost of ownership and increasing the total revenue of servitization, in the case of product-service systems, where a product-service system is a marketable set of products and services capable of jointly fulfilling a user’s needs.

This view of the PDP also embeds a product management mindset, where the further evolution of the product after the sale or market launch is part of the PDP. This is also aligned with the lean philosophy , once the value pulled by the stakeholders might change through the time (due to market changes, technology evolution, etc.) and the offered “product” should evolve accordingly.

The icon of a funnel (Fig. 1.3) has also been used as a visual depiction of the PDP. It works well because it implies that product development is, in fact, a refinement process that takes us from the earliest stages of a project—with a lot of fuzzy ideas and fuzzy thinking—to the final stage of new product launch.

Fig. 1.3

Product development funnel

The funnel metaphor is also very aligned to the lean PDP, which uses the Set-based Concurrent Engineering (SBCE) to maintain product design options through the PDP, instead of choosing a particular option to pursue from the beginning. Although this option is carefully chosen from the other possible alternatives through cost-benefit and risk analysis, the point-based approach often implies in rework cycles, which might disrupt the whole development portfolio (see Chaps. 9 and 11 for more details about SBCE).

2 The Product Development Process Particularities

The PDP itself is a creative, innovative, interdisciplinary, dynamic, highly coupled, massively parallel, iterative, communication-based, uncertain, and risky process of intensive planning and activity [11]. Consequently, a wide spectrum of variables can affect its success, and, not surprisingly, over time, over budget and low quality are commonplaces on PD projects.

Defining or improving a PDP should be proceeded by a reflection on how these particularities affect your own company. Different markets, business models, culture , etc. might lead to distinct impact from these particularities. This is also true with different development centers in the same company, since the organizational culture from each center might be different (i.e. globally distributed development). As a consequence, these variations should be taken into account when defining a company-wide and global PDP.

2.1 Uncertainty

Uncertainty is the knowledge gap between the supposed and the verified characteristics, and lasts while the development is in progress. The uncertainty is directly related to risk [12]:

• Performance risk: Uncertainty in the ability of a design to meet desired quality criteria (along any one or more dimensions of merit, including price and timing), and the consequences thereof.

• Schedule risk: Uncertainty in the ability of a project to develop an acceptable design (i.e., to sufficiently reduce performance risk) within a span of time, and the consequences thereof.

• Development cost risk: Uncertainty in the ability of a project to develop an acceptable design (i.e., to sufficiently reduce performance risk) within a given budget, and the consequences thereof.

• Resources/Technology risk: Uncertainty in capability of the resources (including people) and technology to provide performance benefits (within cost and/or schedule expectations), and the consequences thereof.

• Market risk: Uncertainty in the anticipated utility or value to the market of the chosen “design to” specifications (including price and timing), and the consequences thereof.

• Business risk: Uncertainty in political, economic, labor, societal, or other factors in the business environment and the consequences thereof.

This gap might lead the whole development into wrong assumptions, causing frequent estimate failures and rework cycles. The earlier in the product development process, the higher the uncertainty, thus making important decisions is based on assumptions.

2.2 People-Based

PD is a people-based activity, where each person has his/her own culture , values , personality, etc., and may present unpredictable behaviors, i.e., a “box of surprises.”

As a consequence, the time it takes to perform an activity will not likely be the same whether it is done by different people or if the same person does the same activity on different occasions. Product development processes will always embody statistical fluctuation during their execution. Higher deviations from the average execution time are expected when dealing with new processes, innovative products, and unmastered technologies.

2.3 Ambiguity

Ambiguity means the existence of multiple conflicting interpretations of the information held and required which leads to a lack of consistent information. While uncertainty leads to the acquisition of objective information and answer specific questions, ambiguity leads to the search for the meaning of things. The customer needs or project goals might not be clear, and the information that flows during the development often carries a level of ambiguity and uncertainty.

2.4 Non-linearity

Product development is not a sequential and linear activity. The more innovative the product, the more complex it is to find a suitable architecture in the solution space. Therefore, the PDP is an iterative process comprised of:

• Iteration: Iteration is the procedure by which repetition of a sequence of operations yields results successively closer to a desired result. Iteration can be planned (iterative process) and unplanned (rework). Too complex/poor interface design may lead to more iteration. The higher the number of unplanned iteration cycles the worse the overtime becomes.

• Interruption: Critical design issues, trivial questions, unplanned communication, multitasking, etc. always arise during the development. Though natural, the higher the interruption level on the development projects the worse.

• Changes: Nothing ever happens exactly the way it was planned (changing requirements, resources unavailability, etc.). High change rates compromise the development progress.

2.5 Complexity

The PDP also has to face complexity at multiple levels: the product itself, the development process, and the performing organization (development teams included) [13]:

• Product complexity: Customers request products that are more and more complex themselves. The product development scope includes not only the final product itself, but also its life-cycle processes and the performing organizations of these processes.

• Processes/tools complexity: The increasing number of processes and tools and the challenge to keep them integrated at some level creates issues for effective and unambiguous communication.

• Structure complexity: The performing organization’s structure is becoming more and more complex to be able to deal with increasing product and process complexity, as well as to adapt to global markets and distributed development. The bigger, more distributed, and more multidisciplinary the development team is, the more intensive the need is for communication and coordination to keep the work aligned.

As the complexity of the product increases, the number of different expertise needed to design it also increases. A cooperative environment with mutual help and knowledge sharing is paramount to the development success. This poses great management and product integration challenges.

These particularities help us understanding why consistently succeeding in product development projects is challenging. Any high performance product development process should tackle these aspects in an integrated way. The process we describe in Chaps. 9–13 act in this way.

3 Product Development Performance Drivers

Product development is indeed a complex endeavor. The PDS can be understood as a network with multiple dimensional and highly interconnected processes where feedback-loops cross these multiple hierarchical levels. As a result, there are several drivers that impact the performance of development projects [14]. We divided these drivers into four groups (Fig. 1.4) which are detailed as follows. A complete description of each group’s performance drivers categories and subcategories is presented in Appendix A.

Fig. 1.4

Groups of drivers

The importance of understanding these drivers is to identify their presence in any particular development project and/or Development Organization. They explain the current product development performance, and are a good start to any process improvement effort, as we are going to present in Chaps. 5 and 6.

3.1 External Environment

The external environment group includes all the issues that originated outside the PDS and the parent organization. Though the company has little or no power to influence the environment, some particularities of this environment can directly affect the shape of the enterprise’s PDS and its success. The external environment is divided into two categories:

• 1. Market: Even though the company can perform research and prepare its products for the market, the market itself is outside the company’s boundaries, and consumer decision, globalization, and product lifecycles are some aspects that might influence the product success.

• 2. Business: The category of business includes all the external factors except the market itself. Instabilities on the business include change on the political, economic, and labor scenarios.

The external environment influence in the PD explains the great uncertainty that any PD project faces. The longer the development project takes, the bigger are the chances that the market or the business might change in a way that impact the development; therefore causing rework cycles or even turning the complete project obsolete.

3.2 Internal Environment

The internal environment includes everything that is outside of the PDS but is still within the boundaries of the parent organization. In most of the companies the PD department (if any) or the PD team are part of a greater organization. As a consequence the PD structure is influenced by this larger body. Dealing with the internal environment requires from the PD team leader good knowledge of the organization culture and policies, and good communication and negotiation skills.

The internal environment is divided into five categories of aspects that can have an impact on the PDP performance by not giving the necessary support to its management and execution:

• 1. Organizational culture: The company’s values, beliefs, assumptions, perceptions, behavioral norms, artifacts, and patterns of behavior create the organizational culture . Therefore, it plays a critical role in how the PDS is really structured and executed, sometimes in ways different than the company’s standards.

• 2. Corporate strategy: Objectives, purposes or goals, main policies and plans for achieving those goals, the range of business the company is to pursue, the kind of economic and human organization it is or intends to be, and the nature of the economic and non-economic contribution it intends to make to its shareholders, employees, customers, and communities. Unclear strategies or the misalignment between the corporate strategy and the development needs and goals is a factor that can reduce the development performance.

• 3. Organizational structure: Responsibilities, authorities, and relations organized in order to enable the performing of organization functions, including the product development.

• 4. Business functions: This category considers the issues between the product development and the other business functions in the company such as human resources, sales and marketing, research and development, production/operations, customer service, finance and accounts, and administration and information technology.

• 5. Supporting processes: These are processes that permeate several business functions, such as process improvement, training and knowledge management.

3.3 Project Environment

Project environment encompasses all the product development management and execution activities and is divided into six categories: initiation, development planning, execution management, development control, communication, and development execution. Issues on these aspects will directly impact the PDP performance.

• 1. Initiation: Defines and authorizes the development; guarantees the alignment between the development and the corporate strategy through clear and feasible objectives.

• 2. Planning: Defines and refines objectives and plans the course of action required to attain the objectives and scope that the project was undertaken to address.

• 3. Execution management: Integrates people and other resources to carry out the planned project for the project.

• 4. Development control: Regularly measures and monitors progress to identify variances from the project management plan so that corrective actions can be taken when necessary to meet project objectives.

• 5. Communication: Includes all the issues that could interfere with an effective exchange of information.

• 6. Development execution: Includes all the issues of effective engineering, its subcategories are: requirements development, technical solution and integration, and verification and validation.

3.4 Resources

This group considers the issues related to people, tools, and standards involved during development.

• 1. People: People execute the development itself; they must have the proper knowledge, experience, and skills to positively contribute to the product development success.

• 2. Tools: Tools are used by the people to perform their development tasks; they not only must be adequate to each task individually, but they also must be at some level integrated between themselves, allowing a smooth development flow.

• 3. Standards: Standards guide the work. Good standards, on the one hand, help reduce the variability of the development process, increasing the quality of each task outcome and the development success as a whole. Bad standards, on the other hand, provide misguidance and confusion by either requesting the wrong deliverables (do the wrong work), or by suggesting a non-coherent or badly defined set of processes (do the work incorrectly).

4 Product Development Metrics

Once the drivers to product development low performance are understood, it is important to define how to measure this system and determine how the environment influences the results of this measurement. There are seven categories of indicators to the Product Development System:

Product quality: Product quality has several interpretations ranging from design quality; enterprise capacity to produce the product according to the design; conformance (reliability in use); delivery of the scope; fulfillment of the company’s strategy (not only bounded by the initial project scope); and simply the satisfaction of all stakeholders’ needs, or rather, delivering all the expected value .

Product business case: One important aspect about product quality is that the quality needs perceived at the beginning of the development and the actual needs when the final product is delivered might differ. The customers, the market, the laws, etc. might change and impact the product acceptance. Therefore, keeping track of how strong your business case is through the development project is paramount.

Development time: The development project must deliver the product scope on time. Development (lead) time measures how quickly the company can move from concept to market, and the enterprise responsiveness to the competitive forces and the technological evolution. Short development lead times increase the frequency of new products introduction.

Product cost and Development cost: The development project must also deliver the product scope within the budget. Both product cost and development cost are of importance; the former constrains the enterprise profit according to the volume and selling price, the later constrains the return on investment and the enterprise capacity to do several developments at the same time. The product cost includes material, labor, and the needed production tooling, as well the incremental costs to produce additional units. The development cost includes all the development expenditures.

Development productivity: The aspects related to the product to be developed, as well as to the development must be followed in order to guarantee that “what” we are developing, its cost, and its delivery date, will always sustain a viable business case. A product that does not fulfill the market needs, at the right cost, and at the correct market window should not have been developed.

Productivity determines the level of resources required to take the project from concept to commercial product. This includes hours worked (engineering hours), materials used for prototype construction, and any equipment and services the company may use. Productivity has a direct though relatively small effect on unit production cost, but it also affects the number of projects a firm can complete for a given level of resources.

Development capability: The accumulated knowledge/experience from previous projects that increase the productivity of future projects is included in development capability.

Some of these categories are related to product indicators, while others are related to process indicators. The product indicators measure if the right product is being developed; the process indicators help understanding it the product is being developed in the most effective way. Product quality, product business case, and product cost are product indicators categories. Development time, development cot, development productivity, and development capability are process indicator categories.

This division into product and process indicators influence how the continuous improvement in the PD context (see Chap. 6). Indeed the PDP is a continuous improvement process itself, once it gradually improves the developed product indicators. A low performance PDS is the consequence of issues that negatively impact the performance indicators of product quality, product business case, product cost, development time, development cost, development productivity, and production capability.

Several metrics can be used to support these indicators. Appendix B presents some commonly used Product Development Program metrics. Application of the SMART criteria is one widely used way to choose the metrics that fit your company:

Specific: Ensure that program metrics are specific and targeted to the area being measured.

Measurable: Make certain that collected data is accurate and complete.

Actionable: Make sure the program’s metrics are easy to understand and clearly chart performance over time so that decision makers know which direction is “good” and which direction is “bad.”

Relevant: Include only what is important and avoid metrics that are not.

Timely: Ensure that program metrics produce data when it is needed.

The list of commonly used program metrics presented in Appendix B shows that there is a myriad of possible metrics to choose. When choosing which metrics to use, the company should look into the ones that make sense to its particular needs and which of them they are capable to measure. A common mistake is choosing a great number of metrics (some of them even redundant) and facing the wasteful effort of measuring all of them.

Finally metrics are incremental; each level of the organization aggregates its metrics to the upper level, thus turning feasible the management. Take a complex development program where the product has several subsystems, an aircraft development for instance. The group in charge of each subsystem has its own set of metrics, and the program manager has aggregate metrics that help him managing the complete development. Only when something goes wrong with a particular subsystem, that the program manager goes deeper into its individual metrics.

5 A Practical View

As in any complex system, the PDS cannot be described by analyzing its parts separately; the final system behavior emerges from the interaction among its parts. In practice, the analysis of any working PDS must be done by checking the interfaces between the system and its environment, and among its constituent parts.

The most important (and easier) issues to be perceived are related to the PDS outputs. Costumer complaints, the need of recalls, losing market share, etc. are symptoms of a low performance PDS. It is important to “ask why” and go deep into understanding the perception of the problem (Fig. 1.5). We are not trying to find the root causes yet, but addressing and trying to define the real problem. Going deeper into the PDS and finding the issues among the system’s parts is the path to find the wastes (see Chap. 5) and the root causes.

Fig. 1.5

Finding issues in the PDS

If any issues in the PDS inputs are found, not only must its causes be understood, but also whether the PDS can be improved in order to have more robust capability to handle input variance.

A way to apply the contents of this chapter in practice is:

• 1. Look at your actual PDP, how does it compare to the processes presented in Fig. 1.2? Does it encompass the whole product lifecycle? Lean Product Development Processes take into account the whole lifecycle, if yours does not it is an opportunity to expand it by including integrated product design and development strategies and techniques as presented in the next chapter.

• 2. How do you consider the “product”? Is it the consequence of delivering the pulled value or some predefined result that you push to the market/client? It is almost impossible to have a certain solution idea when starting a new product development project. This is not bad in essence, since it gives focus about the benefits it will produce. You should detach from this particular solution though and concentrate in the value it is going to deliver. The next step is considering what other product-service architectures could the lever the same (and even more) value.

• 3. Read again the PD particularities and try to identify them in the PD projects you recently executed. Can you see some of them? Are they understood by the development team? This exercise has the potential of helping you identifying the particularities of the PDP in the market you are inserted, and improving your process.

• 4. Check the PD performance drivers (also check Appendix A). Try identifying which of the categories and subcategories are present in your company. By identifying them and understanding their root causes, you can make real improvement in your process. This work is closely related to what is presented in Chaps. 5 and 6.

Indeed, it is a great challenge to design and develop winner products. As a consequence, the PDP has constantly evolved through time in order to address the low performance drivers.

The next chapters show this evolution from serial PD, to integrated PD and, finally, to lean PD.