Managing NPD Project Tradeoffs

Eric P. Rose

Originally published: 2013 (PDMA Visions Magazine • Issue 4, 2013 • Vol 37 • No 4)
Read time: 7 minutes

We go about our daily business as new product development (NPD) professionals and, for the most part, intuitively know how to manage NPD projects to optimize objectives. We have historically thought that it is only necessary to manage the triad of tradeoffs: cost, quality and schedule. Over the years, I found this thinking naïve and often laden with misunderstandings. Instead, I offer five clarified and expanded tradeoffs that I developed and found more helpful.

The NPD Project Pentagon^TM Framework

Figure 1 shows the NPD Project Pentagon^TM with its five tradeoffs that I discuss in detail below. While most NDP tradeoffs are multivariate, I have illustrated examples as binary for simplicity of this discussion. Furthermore, this discussion has been written with the development of physical products in mind although software and service NPD professionals will likely find value in this framework as well.

5 Tradeoffs Summary

To set the stage, I offer you a few high-level thoughts about the five tradeoffs:

1. Features: Straightforward, but it is best if you have a written, prioritized list of features customers are most willing to pay for. When tradeoffs inevitably need to be made, you’ll want this written and vetted list ready to help you make the tough decisions.
2. Schedule: What’s driving your schedule? Do you have a trade show date that is do or die? From my days at Mattel, the adage we lived by was “Christmas never moves.” The staff knew you just can’t be late to Christmas. Maybe schedule is king, and you’ll need to plan ahead, get more resources or perhaps even cut lower priority product features that may be driving long development cycles.
3. Product cost: Margins are critical, but perhaps they can improve post-launch as your R&D and operations staff has time to address how to drive product costs down. Consider establishing declining product cost targets spread over time post-launch to drive margins up in order to accommodate another project requirement in the near term.
4. Development cost: Development resources can be some of the most highly compensated staff. If schedule is not king, perhaps you can look at spreading out their workload to do more with fewer human resources. On the other hand, if schedule is king, perhaps you can add resources or even incentivize your development team with clear measurable objectives in order to hit critical schedules like your annual trade show.
5. Capital equipment cost: If your NPD plans require capital equipment, this is a tradeoff to be thoroughly looked at as well. Can you outsource some or all of the manufacturing and leverage a supplier’s existing capital equipment? You may have higher product costs but your bottom line may be better off without the equipment amortization on your balance sheet. This is particularly true for products that may have short in-market lifespans that also require unique capital equipment, such as toys.

Selected Tradeoff Discussions and Examples

To best illustrate possible tradeoffs during an NPD project, I share below a series of binary tradeoffs, commentary and examples.

Features vs. product cost: This is likely the most common tradeoff we deal with in an NPD project. Often as we move out of the Fuzzy Front End, we will tradeoff features for what we believe the product cost will be in order to address our target product cost. I suggest the most helpful way to deal with this inevitable tradeoff is to use a stakeholder’s voice approach where product attributes are force ranked in terms of their value to the stakeholders. Rather than the more classic term, Voice of Customer (VoC), I often choose to use the term Voice of Stakeholder (VoS) input. This allows for broader inputs into the impact of tradeoffs. Such stakeholders could include end users, distribution channel partners, key opinion leaders, internal functional area managers and suppliers. Table 1 (page 7) is an example of such a forced ranking review of a fictitious, simple product.

Features vs. capital equipment cost: This tradeoff is a less clear, less dealt-with constraint but it does come up periodically. When features are reviewed for their project impact, the issue of capital equipment cost (CapEx) requires some digging to understand the impact. Key questions to be asked are: Are there certain product features that can be directly tied to the need for your company or a contract manufacturing company to invest in CapEx because the equipment to make that product element does not currently exist? This does not necessarily mean a new dedicated piece of machinery may be needed. Rather this could mean a new dedicated piece of tooling. Can the design of the product be revised to eliminate this piece of tooling or to significantly simplify the design and fabrication of that piece of tooling? While this may not be possible, some research here may be warranted and therefore CapEx savings potentially significant. Your chief financial officer will be a good resource here and will certainly appreciate your forethought.

Features vs. development cost: When this tradeoff comes up, it’s usually R&D management that raises the flag here. They are usually the ones being held to a development budget on specific projects as well as for the fiscal year. They also should be the ones to help with the understanding of which features have what development cost impact and what can be done to reduce this cost. The earlier discussed VoS forced ranking of the features is a good place to return to in dealing with this tradeoff. An additional tradeoff option includes looking at the specific cost of the resources to execute the development of any given feature. If overtime cost is the culprit in preventing you from keeping your development costs on budget, these costs may be reduced by shifting work to lull times in the R&D department’s schedule, although nowadays it seems as if such lulls are rare. These costs may also be reduced by using outside contractors who have smaller boutique development skills and even potentially moonlighting contractors, which can be assigned low-risk tasks. Lastly, low VoS-valued features may be eliminated if budgets must be held. Another approach to resolve a potential features vs. development cost conflict may be to look to your suppliers. They may be willing to participate in the development of a given feature at little or no development cost in exchange for a commitment from you for production orders.

Features vs. capital equipment cost: This tradeoff is a less clear, less dealt-with constraint but it does come up periodically. When features are reviewed for their project impact, the issue of capital equipment cost (CapEx) requires some digging to understand the impact. Key questions to be asked are: Are there certain product features that can be directly tied to the need for your company or a contract manufacturing company to invest in CapEx because the equipment to make that product element does not currently exist? This does not necessarily mean a new dedicated piece of machinery may be needed. Rather this could mean a new dedicated piece of tooling. Can the design of the product be revised to eliminate this piece of tooling or to significantly simplify the design and fabrication of that piece of tooling? While this may not be possible, some research here may be warranted and therefore CapEx savings potentially significant. Your chief financial officer will be a good resource here and will certainly appreciate your forethought.

Features vs. development cost: When this tradeoff comes up, it’s usually R&D management that raises the flag here. They are usually the ones being held to a development budget on specific projects as well as for the fiscal year. They also should be the ones to help with the understanding of which features have what development cost impact and what can be done to reduce this cost. The earlier discussed VoS forced ranking of the features is a good place to return to in dealing with this tradeoff. An additional tradeoff option includes looking at the specific cost of the resources to execute the development of any given feature. If overtime cost is the culprit in preventing you from keeping your development costs on budget, these costs may be reduced by shifting work to lull times in the R&D department’s schedule, although nowadays it seems as if such lulls are rare. These costs may also be reduced by using outside contractors who have smaller boutique development skills and even potentially moonlighting contractors, which can be assigned low-risk tasks. Lastly, low VoS-valued features may be eliminated if budgets must be held. Another approach to resolve a potential features vs. development cost conflict may be to look to your suppliers. They may be willing to participate in the development of a given feature at little or no development cost in exchange for a commitment from you for production orders.

Features vs. schedule: This tradeoff is often the point of contention between the technical development staff and marketing. There is the opportunity to have meaningful dialogue about the tradeoffs of these two key project deliverables. The technical development staff should clearly, and dispassionately, share with marketing the net impact on schedule of the features desired. Ideally these schedule impacts should be shared in a “grocery list” format. However, because some product features go hand in hand, some feature “bundles” may be estimated as well. Marketing should use evidence-based decision making to determine which, if any, features that have significant schedule impact can be eliminated, simplified or simply delayed for a rolling follow-on introduction in the future. This review should include the VoS input. Some key influencers may include trade show dates, key customer feature must-haves and scheduled revenue commitments to shareholders.

Product cost vs. capital equipment cost: Trading off a product’s cost for the capital equipment cost is another area worthy of bringing in the chief financial officer for consultation. A typical example of this tradeoff can be found in the plastic consumer goods industry in the building and running of plastic injection molds. Multicavity molds will yield part costs lower than single-cavity molds, although the relationship is not linear. Multicavity molds will be more expensive to produce, but their cost does not increase linearly in relation to the number of cavities. Looking closely at multicavity molds is an option to seriously consider when trying to reduce product costs. During the development of a new product, it would be wise to have a range of mold cavity and their corresponding part costs quoted. Additional inputs in the management of this tradeoff may include:

• Number of components used in the prod-uct that can be included into one mold;
• Life of the product in the market;
• Competitive product pricing;
• Ability of the company to adjust the sell price in order to maintain profit margin;
• Time available to run a season’s worth of product; and
• Sales demand plan vs. mold capacity.

Product cost vs. development cost: Although the frequency may not be often, there may come a point in an NPD project where you are faced with trading off the product cost for the development cost. An example of this would be where the lowest product cost would come through a well-designed plastic part including a carefully selected plastic material well suited to the specific application. The NPD of this part likely would require a significant effort in design and prototyping. Computer-Aided Design (CAD) models would be created, perhaps virtual prototypes would be tested through Finite Element Analysis (FEA), rapid prototypes (RP) built and pos-sibly even a prototype mold would be made to test parts in the actual materials proposed.

In contrast, a lower development cost approach would be to acknowledge the development cost budget constraints and simply design the part out of machined metal. While this may be overkill in the design, assuming the product margin can absorb the hit, the design of a metal part may require less development effort and therefore less cost.

My team faced this exact scenario in the development of the caster wheel socket for a geriatric walker. In this case, an upcoming tradeshow made the schedule a priority factor. By using a metal machined component, we were able to reduce development time and launch on schedule and within our development cost target. Eventually, my team was able to justify the expense of the development cost for the plastic part development due to better than expected sales of the new walker accessory. The carefully engineered plastic part was rolled out seamlessly without fanfare into the market at a reduced product cost. The savings paid back the follow-on development cost in less than one year’s time.

Summary

The NPD Project Pentagon^TM offers those involved in bringing new products to market who face numerous tradeoffs a way to frame their decisions. While this is a binary view, and often reality is highly multivariate, it still offers a useful tool in managing the inevitable NPD project tradeoffs. On your next NPD project, consider how the NPD Project Pen-tagon^TM would help in better managing your projects’ tradeoffs.

About the Author

Eric P. Rose, NPDP, MBA, is a product innovation and management consultant who provides entrepreneurs and established companies with the expertise to move new product ideas from market opportunity into marketplace reality. Rose has more than 30 years of experience in product innovation, product development, commercialization and project management. He also is an adjunct MBA professor of Product Innovation and Management at Pepperdine University.

Related Content