Optimizing the Product Development Process

Product development is similar to an expedition through an uncharted wilderness. An expedition requires a well-explained description of the destination, a clearly articulated plan for how to get there and an understanding of the roles and responsibilities of each team member. Once an expedition is underway, there must be a leadership system that allows the various team experts to work together to evaluate risks and make decisions about the best course of action, possibly modifying the original plan based upon new information. Although Lewis and Clark may have eventually reached the Pacific if they had simply grabbed their guns and headed westward, their odds of success were greatly improved by approaching their challenge in a calculated manner. The chances of successfully developing a new product that meets the needs and desires of the marketplace are similarly improved if a methodical development plan is followed.

Figure 1 shows a typical, real world development process for some companies. There may be no clear process and key decisions about product features may be made based on poor or insufficient information. Information between the technical, marketing and manufacturing groups may not be shared effectively. Technical resources may be expended working on problems that are not particularly relevant to the business objective, and important technical challenges are not recognized until late in the development cycle.

The Real World Product Development “Process” for Some Companies

Most established companies with a proven track record of introducing successful products into the market have a formal product development process that project teams are required to follow. These can vary in format from a highly structured process with thoroughly documented procedures and formal sign-off sheets, to an informal but disciplined process that is adapted to the needs of an individual project. Either approach can be effective depending upon the nature of the project and the temperament and experience of the development team members. A highly experienced development team may naturally incorporate the key principles of a successful product development process into their project whereas a less experienced team may benefit from a more formalized approach.

Regardless of the degree of formalization, there are certain characteristics that are central to an effective product development process. The classic representation of a methodical product development process is typically represented by a “development funnel” similar to that shown in Figure 2.

Figure 2
The Development Funnel

The development funnel illustrates how product concepts and market data flow into the wide end of funnel and how these are successively processed, refined, combined or eliminated as they pass through. The central principle is that of the “stage gate” process, which has clearly defined phases. Before a particular project proceeds from one phase to the next, it must pass through a gate that includes a design review between the engineering, manufacturing, marketing and management functions of the team. During the design reviews, participants will review the design solution(s) that have been generated by the engineering and manufacturing team members in light of the product requirements. The purpose of each design review is to identify discrepancies between the specified product requirements and the technical solutions proposed to address them. In some cases, it may be necessary to modify the product requirements in order to adapt to the available technical capability or to reduce the projected product cost or the time and resources needed to bring the product to market. In other cases, the design review may suggest that the technical approach needs to be further refined before proceeding with the project.

Product development always entails a level of uncertainty. In reality the path forward for the typical development project will not be as organized and methodical as Figure 1 suggests. As the technical team learns what does and does not work, and as more information becomes available about the market requirements, there may be dead ends and iterations. However, an organized stage-gate development process will help insure that these “iteration loops” are as small, fast and inexpensive as possible.

In extreme cases there may be no way to resolve the discrepancy between a critical product requirement and the available technical solutions at an acceptable cost. The best alternative in this situation may be to cancel the project. This is obviously an undesirable outcome; however, an effective product development process will discover and stop work on an unfeasible project as soon as possible so that resources can quickly be redirected to a more productive purpose. In the more usual and desirable case that the product concept is valid the product development process can help insure that the objective is reached more quickly and at lower cost than if a more haphazard approach is taken.

Product development is primarily a process of making decisions. A relatively simple product may still involve dozens, hundreds or thousands of interrelated decisions about product features, marketing strategy, technology, design details, manufacturing strategy, finance, human resource management and other business considerations.

The entire process requires that each decision is made quickly and, more importantly, made correctly for the product to be successful. The key decision points are identified and researched early in the project to obtain the information needed to draw the right conclusions and plan the best path. The development team assigns actions to its members that have the expertise in each of the required fields, and it relies on their feedback to determine the appropriate course of action.

For some projects certain development phases and steps may be combined together or eliminated if not relevant to a particular project. A company may give the phases of their product development process different names, or combine or separate phases in different ways depending upon the simplicity or complexity of a project. The important point is that every project should follow a methodical, pre-defined process that will insure that the most important challenges are addressed early and that critical communication between the technical, business and manufacturing functions is occurring.

I. Definition and Feasibility

A. Describe the product requirements. The motivation to develop a new product originates with the recognition of a need or desire in the marketplace. The information may be presented in an informal way and it may take various forms, but the important point is that the basic product requirements are communicated in a way that all members the team can understand. The product features must be described and the relative importance of each should be explained. The critical “must have” features should be distinguished from those that are “nice to have”.

B. Identify the primary technical challenges. The members of the design team must identify the most significant technical challenges that need to be overcome to achieve the project objectives. They may relate to the size, weight and cost of the product or certain functional or performance features. The project team will eventually need to create a plan for satisfying all of the product requirements; however, during the definition and feasibility phase of the project, it is necessary to identify only those that represent a significant challenge or risk to the success of the project.

Example 1: One of the critical product requirements is that it must have a size envelope that is smaller than 0.5” x 1” x 2”. If the project design team has a reasonable doubt about whether all of the necessary internal components can fit into this envelope, then this should be identified as a primary technical challenge.

Example 2: If the preliminary product requirements indicate that the product must have a color touch screen display, but also that the product must have a total manufacturing cost of $5.00, the design team may identify this as a primary technical challenge. They may be uncertain about whether a suitable display and the associated control components needed to provide the desired features can be purchased or developed at a cost that is consistent with product’s projected cost.

A primary technical challenge may be conceptual in nature. If the design team is lacking a clear concept for how to implement a critical product requirement, this may be identified as a primary technical challenge that must be addressed during this phase of the project.

Example 3: A key product requirement may be that an internal battery must be replaceable by the product user, but that the product must also be water tight. The design team may be uncertain about how to accomplish these contradictory requirements since the first presumes that the product enclosure can be opened by the product user and the second implies that it must be sealed tightly when closed. The sealed battery compartment may therefore be identified as a primary design challenge to be addressed during this feasibility phase of the project.

The primary technical challenges should be identified, listed and described to the wider project team. The next important project milestone is to identify solutions for how each of the primary technical challenges can be addressed.

C. Identify one or more solutions for the primary technical challenges.

After the primary technical challenges have been identified, the technical team members must investigate each of them in enough detail to determine whether viable solutions for each challenge exist or can be conceived. During this first phase of the project it is not necessary to determine the best solution to each of the primary technical challenges (this will come later). Rather, the goal is to confirm that there exists at least one viable solution for each challenge. Obviously it would be unwise to spend a large amount of time and resources developing an elegant solution for one particular design challenge only to find out later that no solution can be found for another and that the product requirements therefore must be significantly altered. The technical team members may be chomping at the bit to start the “fun” design work, or management may be anxious to “put something in the hands” of the executives as a sign of progress. However, the purpose of this project phase is to ensure that there are no insurmountable obstacles that will prevent the product, as described in the product requirements, from being realized.

Earlier an example was provided where product size was identified by the technical team as a primary technical challenge. Now is the time to determine whether the desired size can be achieved. This may require a preliminary CAD layout of the larger components, circuit board, connectors and other components, housing, etc. to see if all of these can be arranged to fit within the specified size envelope. The goal for now is not to determine the optimal placement of the internal components, although they should be placed in a realistic and practical location. The goal is to determine whether all of the things that must fit into the required space are going to fit. If the layout shows that this is feasible, then the team can move on to addressing the next primary technical challenge. Otherwise, it will be necessary to identify options for satisfying the size requirement perhaps by eliminating internal components (and features), finding smaller components or increasing the product size requirement.

The second hypothetical technical challenge described above related to the cost of the display feature for the product. In this case the display options should be researched and preliminary pricing obtained or estimated for this and other product components so that an estimate of the manufactured product cost can be made. If the estimated cost for the full-featured product exceeds the maximum allowable product cost defined by marketing then a decision must be made. Either marketing must accept the increased product cost or else the engineering and marketing functions of the team will have to negotiate an acceptable compromise between product features and cost. For example, perhaps the display can be bi-color rather than multicolor or maybe the display function should be eliminated altogether.

The third hypothetical technical challenge regarded the water-tight battery compartment feature. The technical team must determine whether there is at least one viable concept for accomplishing this function. One obvious approach is to examine other products on the market that have this feature to determine whether the concepts employed there can be adapted to this new product while still satisfying the other product cost, reliability and size requirements, etc. If none of those approaches are appropriate to this new application then the technical members of the team will need to do some preliminary brain storming to develop a concept. It is not necessary to select the best concept at this time; rather, it is to demonstrate that that there is at least one viable concept to this technical challenge that will satisfy the performance and other product requirements.

If no viable solution for a particular technical challenge can be found, the project team must adjust the project requirements in a way that viable solutions can be found if possible. Otherwise, if the feasibility analysis indicates that one or more of critical product requirements can neither be met nor relaxed then this indicates that the product is not feasible and the project should be cancelled. As stated earlier, this clearly was not the hoped-for outcome at the outset. However, the properly executed feasibility analysis has at least provided the information to make this necessary business decision with a far lower expenditure of time and money than would have been expended if the project had been allowed to continue only to come to this same conclusion later.

II. Concept Development

During the previous phase the critical technical challenges were identified and it was determined that at least one viable technical solution existed to address each of them. During this phase, additional concepts are identified for addressing these primary technical challenges, if possible. These are weighed against each other in light of the product requirements and the cost constraints and the best concepts are selected.

Similarly, concepts are developed and evaluated for all of the secondary technical challenges. These secondary concepts should be explicitly identified, listed and addressed in order of priority. Alternative circuit schematics, various ways of locating components and options for partitioning the enclosure are considered, for example. It is important that all possible, practical alternatives are conceived and communicated to a “sketch” level and carefully evaluated for each of the technical challenges before proceeding with the next phase of development.

There are many forces that encourage the development team to rush through the concept development phase of the project. Often the investors and/or management team are anxious to see “a sign of progress”. CAD models, a busy machine shop or rapid prototype parts may psychologically convey “progress” in a way that hand sketches, concept matrix’s or hand calculations do not. Also, development engineers and designers are often not as comfortable communicating with other people as they are with designing and building. They may be more in their comfort zone while sitting quietly in front of a CAD station or tinkering in the lab than meeting with their peers to generate and evaluate multiple design concepts for multiple technical challenges. These conversations may require a considerable amount of discussion of pros and cons involving the various functions within the development organization (business, marketing, manufacturing) and may become tedious or contentious as different members of the team have different points of view or egos get in the way. These pressures may combine to motivate the team to stop the concept phase and design something.

The concept phase is the most important part of the project. It is where the battle is won and lost. Companies with a reputation for excellence in product development will “front load” their projects, meaning that they will spend proportionally more time generating and evaluating concepts during this phase of the project than will less successful companies. This is because they know that the product concepts are like the foundation of a building. They are critical to its integrity and success, and like a foundation they are difficult and expensive to correct later if they are faulty. There is a well know product development rule of thumb known as “the rules of tens” that states that the cost in dollars and time of correcting a design problem/bad decision increases by a factor of ten for each succeeding stage of the project. For example, modifying a flawed design concept may cost “X” dollars and “Y” hours during the concept phase of a project. However, if this flaw is realized during the detailed design phase it will cost 10X dollars and require 10Y hours to correct. If discovered during the prototype build and evaluation phase it will cost 100X and 100Y, and so on. This is why industry leaders frontload their development projects because they know that the time and energy invested in the early stage of the project will pay handsome dividends by avoiding later problems.

Many companies believe that creativity is the most important ingredient of product success. While there is no denying that creativity is a valuable resource, it is of limited value without the discipline, persistence and communication that should take place during the concept phase of a project. A project team of modest creativity that possesses these virtues will generally outperform a team of highly creative members who jackrabbit forward without careful consideration of their alternatives and related implications.

Often it will be necessary to make decisions between concept alternatives on the basis of the expected technical performance of one alternative versus another. For example, it may be necessary to determine whether a particular alternative will be strong enough or if it will have enough torque or enough speed for its intended purpose as compared to another alternative. Positive answers to these types of questions constitute “proof of concept”. There may be dozens of such questions that arise during the concept phase. One way to answer these questions is to simply take an intuitive guess and then design and build a product prototype to see what happens. This “cut and try” method is often an expensive and time-consuming way of comparing technical alternatives and proving concepts. It is often faster and cheaper to answer conceptual questions using calculations, physical reasoning or by performing targeted experiments with “engineering models”. It may take months to design, build and evaluate product prototypes. It may take a week or two to design, build and test an engineering model to answer a specific technical question. In some cases an engineer may be able to answer the same question with a calculation in a few hours!

If the situation under consideration is not practically amenable to analysis, then it may be necessary to design and build a thoughtful engineering model that realistically simulates the physical situation. For example, an engineering model may isolate a particular mechanism within the product or show how a particular user interface feature will function. An engineering model will not include all of the details and features of the entire product, and it may not look like the final product. Rather, the engineering model will isolate the subsystem of concern without regard to the other independent parts of the product. For this reason an engineering model is typically much faster to design, build and test than is a prototype of the whole product system. In fact, it will typically be much faster to design, build and test multiple engineering models of different components and subsystems and make changes to them if necessary than to design, build and test the entire product system.

A hallmark of a good engineer is their ability to take a complex problem and break it down into multiple, simpler problems that can be studied and solved independently. This approach is usually a faster and more likely successful way of addressing technical challenges than grappling with the overall complex system at once. They will also carefully consider the alternative solutions to a particular technical challenge and thoughtfully weigh the advantages and disadvantages of each before making a selection. Similarly, good engineers will carefully consider their alternatives for addressing each of the design challenges associated with a new product and devise efficient ways to independently prove the validity of each of the chosen concepts before proceeding to assemble the prototype and performing the detailed design analysis.

Typically the concept development phase of a project is concluded with a concept review meeting. Here, the project engineers present their primary concepts and their reasons for their choices to their peers and to other members of the project team. The purpose of this review is to verify that there is not an obvious flaw with the reasoning or a previously unknown important piece of information that needs to be taken into consideration before proceeding further.

III. Detailed Design

The purpose of the concept development phase was to plot a course for where the design is going to go and how it is going to get there. The purpose of the detailed design phase is to actually undertake the journey of getting to the destination. As stated earlier, it is important that before the design work begins in earnest that all of the significant technical challenges and concepts for addressing them have been identified and evaluated and the concepts representing the best overall compromise of cost and performance have been chosen and proven to some degree. This is analogous to having a general route planned for how one will drive from Raleigh to Portland before starting the engine and stepping on the accelerator.

During this phase, the CAD designs for the all of the mechanical components are created and refined. Electronic schematics are refined and circuit boards are laid out and routed. This work will consume a relatively large proportion of the project budget and time line. There will invariably be some amount of minor trial and error and rework as the design progresses, as the interrelations among different components and systems are worked out, and as unforeseen complications arise. However, if the previous concept phase was executed properly these obstacles should be relatively minor and should not have a major impact on development cost or schedule.

During this phase component suppliers and manufacturing engineers should review the design and provide guidance as it evolves. It is important that this feedback occur before design details have firmly solidified and become difficult to change. As the design nears completion the team should hold a cross-functional design review that involves the various organizational functions including the engineering, manufacturing, marketing and business functions. If significant issues or doubts are raised about the adequacy of aspects of the design then these should be addressed and resolved satisfactorily before the project is allowed to proceed to the next phase. The engineers should also perform an exhaustive technical peer review of the design to uncover any potential problems like improper fits or clearances between mating components, or insufficient structural integrity, etc. Although this chore is tedious and boring, it is far less costly and time consuming to find and correct minor design flaws now, when the corrections may take only a few minutes or hours, than during the prototype phase when they may take days or longer and may require the purchase of additional rounds of prototype parts.

IV. Prototype

Once the product design is complete, reviewed and approved, the prototypes are built and evaluated. There may be at least two rounds of prototype build. The first round of prototypes are often referred to as “engineering prototypes” or “alpha prototypes”. They may utilize rapid prototype components that do not require expensive tooling to fabricate and can be obtained quickly (a few days). Typically rapid prototype components utilize materials that are inferior to production quality materials with regard to physical properties like strength, temperature resistance or aesthetic characteristics. Nevertheless they can often be obtained relatively quickly and inexpensively to get quick verification that the assemblies will fit together and will generally perform as expected. Often small corrections may need to be made to certain parts if issues are uncovered, but these should be minor if the design was reviewed carefully.

During the first round of prototyping the first circuit board (if applicable) is fabricated and populated with components. The board is “brought up” by the hardware engineers who verify that each subsystem of the circuit board is working as intended. Often small corrections or modifications to the circuit board will be needed at this time and these may require substitution of certain components or cutting of certain traces and the addition of small “white wires”. Once the prototype boards are working properly they may be loaded with prototype version of software (if applicable) and basic functional performance is verified.

After both the mechanical and electronic components are verified then these are put together to create the fully functional prototype final assembly. A test plan is created that describes how the prototypes will be evaluated to determine whether they will perform as intended and whether they will satisfy the requirements of the product specification. At this stage of the project the testing and evaluation may be somewhat qualitative in nature rather than entirely quantitative. For example, it may not be possible to perform a full battery of drop testing or vibration testing with this level of prototype if it is constructed with rapid prototype components since these materials have structural properties that are not representative of production quality materials. Although the testing and evaluation of the prototypes may not necessarily prove that the final product will satisfy the product requirements in every regard they should provide some evidence that this will ultimately be the case. Good engineering judgment and common sense must be used both in developing the engineering prototype test plan and also when evaluating the results.

The engineering prototypes should also be reviewed by the manufacturing engineers. Though they should have already had involvement and input into the design of the product, they will want to review the first prototypes to verify manufacturability and to identify potential improvements that should be incorporated to improve manufacturability.

Typically the testing and evaluation of the engineering prototypes will result in a punch list of design modifications that need to be made to both the mechanical and electronic design. Depending upon the nature and level of complexity of the necessary design changes it may be prudent to build and evaluate another round of engineering prototypes. However, often the required modifications are relatively minor and the next round of prototypes can be field prototypes. One of the primary differences between the engineering prototypes and the field prototypes is that the former are typically constructed using rapid prototype parts or other techniques that are relatively fast and inexpensive but that are not suitable for use in actual manufacturing. On the other hand the field prototypes are constructed using materials and techniques that are similar or identical to those that will be used in the actual manufacture of the product. For example the plastic parts may be injection molded from the final production materials or metal parts may be die cast rather than machined. Typically the prototype tooling needed to produce the field prototype parts will require a significant capital investment and these tools may require several weeks or months to design and build. It is therefore important that before the design files are released for tooling that the development team is sufficiently confident of their design based on their evaluation of the field prototypes.

Once the first tooled prototype parts are available then these are inspected to verify that they are correct per the relevant drawings and any errors in the tooling are identified and corrected. After approved parts are available the field prototypes can be assembled and evaluated. A test plan is developed that typically includes a combination of laboratory testing and field trials. The purpose of the laboratory testing is to demonstrate and document that the prototypes meet the requirements of the product specification with regard to performance, life, environmental exposure, regulatory and safety requirements, etc. The purpose of the field or “beta” testing is to allow the prototypes to be used in real world conditions by actual product users. The results of the testing and evaluation of the field prototypes may again result in a punch list of necessary design modifications, but at this stage of the project these should be minor. This a good time for the team to hold a final design review of the design at which point the design can be released to production.

V. Production

Prior to production the part drawings, assembly drawings, circuit board design files and bills of materials (BOM) must be created and loaded into the manufacturer’s document control system. Manufacturing engineers must design and build assembly and test fixtures, specify and purchase fabrication and test equipment, create manufacturing instructions and train assembly personnel. The supply chain must order production quantities of parts from suppliers. Often the early production builds will be done using parts that have been produced using prototype tooling as these tools are often adequate for low quantity production. Production tooling may take different forms depending upon the magnitude and speed of the production ramp up and different strategies may be developed for the tooling plan depending upon the business plan and sales forecast.

Once these items are in place then there are typically a series of preproduction builds that will occur prior to actual production. There may be one or more “pre-pilot” builds of a few units to give the manufacturing engineers and the assemblers an opportunity to test out the manufacturing process and to learn where corrections need to be made to either the assembly fixtures, equipment or to the assembly process. After these have been refined then it is time for the first production build or “pilot” build. The pilot build units are built entirely using the production quality parts and process with little or no input or assistance from the product development engineers. A quantity of the pilot units are inspected and tested by the development engineers in a manner similar to the field prototypes to verify that these satisfy the design intent. There may be periodic audits of production product for some time into the future to ensure consistency of the manufacturing process.

The general product development process described above ensures that important information is shared among the members of the development team and that critical decisions are made correctly early in the project and as the design evolves. The actual product development process that is used for a particular product can vary from the one described above depending upon the complexity of the project and the nature of the development organization. The most important feature of a product development process is the inclusion of “gates” or cross-functional reviews through which the project must pass. This helps insure that each phase of the project is adequately completed before moving on to the next phase. This is critical because the work of later phases is highly dependent upon the accurate completion of earlier ones. The cost and time associated with correcting flaws in a design can be orders of magnitude greater if these are discovered later in a project than if these are rooted out early. Successful companies therefore frontload their projects by expending a relatively large amount of time and effort during the concept development and evaluation phase because they know that this will ultimately result in the best end result at the lowest cost and in the shortest time.