2004 New Product Development Quick Tips

How can we complete our design work if marketing keeps changing the requirements?

This frequent complaint is a symptom of weak cross-functional team interaction.

Several years ago, product development managers recognized this weakness and instituted new organizational forms, such as a vice president of product development or core teams, and team training to improve interaction between departments. Unfortunately, these improvements often have reverted to the former silos, and globalization has exacerbated the deterioration.

Although development managers have put effective teams behind them as "conquered land," when I lead training sessions in time-to-market, the item that consistently comes to the top of participants lists as an opportunity for improvement is better cross-functional teamwork. That is, the product developers see an opportunity here that is not apparent to their bosses.

What can you do? I've found that different opportunities exist for each organization, and thus the best solution works out differently in each case. There are no universal answers.

Consequently, I suggest that you look at some of the current team literature and search for approaches that will help you overcome your current obstructions.../Chapters.htm#CPD_Teams Here are some leads:
- Our recent handbook chapter on Concurrent Product-Development Teams
- A book and some articles by Christopher Avery, who emphasizes the individual skills required for good teamwork: http://www.christopheravery.com
- If you are especially interested in the disruption that marketing initiates with product requirements changes, consider how some of the agile software development methodologies, such as Scrum and Extreme Programming, overcome this: agilealliance.org

Quick Tip list  |  Product development publications  |  Home

 

My boss frequently stalls on decisions. Is this fast time to market?

As counterintuitive as it seems, this may be a faster way to market, and it may result in a better or cheaper product or in labor savings also.

Product development is essentially a chain of decisions, and we make decisions based on currently available information. The longer we wait, the better this information can be, so the better our decision might be.

The wisest decision makers explicitly think about the information needed to make a good decision, and they proceed proactively to obtain this information before they have to decide.

Often, the decision is a choice between two alternatives. In this case, you can defer the choice by keeping both options alive and developing them further, what we call parallel development. This is essentially a matter of developing more information to make a better decision.

However, this strategy can clearly delay progress too. If you are going to use it, you must understand your project's critical path and how it relates to your decision, and you must decide before the decision falls on the critical path. You should also know the cost of obtaining the additional information relative to the benefit of delaying the decision.

Most importantly, this is not an excuse to procrastinate. Even before you reach the point of procrastination, you should recognize that if you delay too many decisions, you will be juggling too many balls, and your cumulative project risk will rise.

For more on this subject, see Chapter 3, "Decide as Late as Possible" in Poppendieck's book, Lean Software Development

Quick Tip list  |  Product development publications  |  Home

 

What is lean product development and should we be using it?

Lean product development stems from lean manufacturing, which in turn, is largely a repackaging of the Toyota Production System (TPS). As many companies have adopted lean manufacturing, they have sought to make similar transformations upstream in their new products entering the factory.

Although some of lean manufacturing translates to product development, much of it can cause problems in translation. The classic in making the translation is Don Reinertsen's Managing the Design Factory. Don succeeds by carefully selecting the techniques that do translate well and by translating them at a high level. For instance, pull systems, small batches, and queuing theory lend valuable insight to effective product development.

Other techniques can get you into trouble. The core practice of lean manufacturing, for instance, is eliminating waste. Sometimes you have to look carefully, even in the factory, to identify waste. Shingo, one of the leaders of the TPS, identified seven types of waste, such as correction, inventory, and waiting. Correction includes rework, which is undesirable in the factory.

In product development, rework also would seem to be waste. Our mantra is "do it right the first time." However, the essence of innovation is re-trying things until they work. If you drive out rework, you will have no innovation. Consequently, the key in re-trying things is to do it efficiently and learn as much from each failure as possible, not to eliminate the failures.

Probably the most useful recent book on lean development is Poppendieck's Lean Software Development, although you may have to translate some from software to hardware.

Quick Tip list  |  Product development publications  |  Home

 

Where do we start in reducing time to market?

Your first step should be to determine what flavor of time to market you need. Faster product development seems to be a straightforward concept, but there are some important distinctions to make. Here are some of the possibilities:

1. Launch the product as soon as possible
2. Minimize variations in launch time
3. Minimize rework and wasted effort
4. Minimize development expense
5. Agility (ability to make late changes easily)

Raw speed (number 1) is important in some fast-moving industries, such as fashions and consumer electronics. Minimizing variation (number 2) is more critical for seasonal products or those launched through trade shows. Minimizing waste seems to be the unspoken objective behind some approaches to accelerated development, such as stages-and-gates. Due to increasing uncertainty in markets, supply chains, and technologies, agility is increasingly important for many companies.

Understanding your objective is the first step because the tools you use to reduce "time to market"—as well as the results you obtain—will depend on your objective. For instance, high-performance project teams are effective for objective number 1, project risk management aims at objective number 2, strong phase reviews fit with number 3, functional and matrix organizations align with number 4, and front-loaded experimentation matches number 5.

Unless you select tools that fit your objective, you will not achieve the results you desire.

For help in making these choices, calculate your project economics (see Chapter 2 of Developing Products in Half the Time) or read our article, "Developing Your Products in Half the Time."

Quick Tip list  |  Product development publications  |  Home

 

What major trends do your see in product development?

I see two trends—and they are on a collision course.

The first one stems from the relentless pressure to cut costs and from management's inherent desire for predictability. It leads to our award-winning risk management technique and to popular phased-development processes, such as stages-and-gates or product lifecycle management, that control investments carefully.

The opposing trend recognizes that innovation is essentially unpredictable and that excessive control is an unlikely route to breakthrough products. Add to this the fact that our world is becoming more chaotic: lead engineers quit, management changes, suppliers go bankrupt, new technologies exhibit unexpected side effects, customers change their minds, and a competitors launch products that exceed the ones we have under development.

Rather than an emphasis on controlling development, managers following this trend instead find ways to deal with change more cheaply and less disruptively. They enhance their organization's agility by

• Obtaining direct customer input early and often—and use it to guide their designing
• Applying technology to automate design and testing (automating change, so to speak)
• Carefully deferring, staggering, and avoiding decisions that close doors
• Employing small, empowered teams
• Failing early—and learning from these failures

To learn more about leading the flexible organization, read Stefan Thomke's book, Experimentation Matters

Quick Tip list  |  Product development publications  |  Home

 

How can we come up with more/better new-product ideas?

Creativity is a highly admired trait. Most organizations wish they had more or higher-quality ideas for truly new products. Although you can learn and manage creativity, few managers are willing to invest what it takes to raise their level of creativity.

Unfortunately, there are many obstacles to creativity in today's workplace. The biggest is perhaps simply the time available to create. High-quality ideas take time to ferment; the best ones are seldom the first that come to mind, and pushing beyond the initial outflow is not natural.

Motivation for high-quality ideas must be intrinsic. Paying bonuses for ideas fosters me-too excursions, not risky, breakthrough concepts.

The performance and metrics orientation of "best-in-class" companies encourages sticking to one's knitting rather than venturing into the unmeasured. I have seen several small, entrepreneurial organizations acquired by larger command-and-control organizations that then squelched the very creativity they purchased.

Luckily, you can overcome most of these obstacles with attention once you recognize them, and there are ways to stimulate organizational creativity. See our review of the book, Creativity, Inc for details.

If you plan to apply your creativity to new-product ideas, keep one other point in mind. Most organizations already have more new-product ideas than they can squeeze through their funnel. If you stimulate creativity without making other changes, this problem will become worse. You want higher-quality ideas, not more ideas. Along with enhanced ideation, develop more efficient front-end filtering mechanisms so that you can eliminate the weaker ideas earlier and faster.

Quick Tip list  |  Product development publications  |  Home

 

What can we do to "freeze" our product's specifications?

The wish of every product designer is to start a development project with a complete set of product specifications and avoid specification changes during design. This makes life easier and more predictable.

Unfortunately, "frozen" specifications are mostly a dream perpetuated by consultants and educators. They don't fit with realty. Colleague Don Reinertsen has surveyed hundreds of product designers from all industries over several years. He found that fewer than five percent of them had complete specifications before they started designing, and in no case did the specification remain stable throughout design!

Furthermore, Harvard Business School professor Alan MacCormack's research shows that the most successful projects commercially were those that started with only a rough idea of the product but built prototypes and obtained customer feedback early in the project.

Together, Reinertsen and MacCormack suggest that frozen specs are neither realistic nor wise, and others are also reaching this conclusion.

Does this sound like chaos? Well, this is the way the world is headed, so rather than fighting it, you might be wise to build a development system that tolerates change and chaos well - that is, an agile process.

There are several things you can do to improve your agility:

• Employ modular architectures to isolate changes
• Make decisions progressively rather than massively
• Exploit flexible technologies, such as rapid manufacturing and programmable logic devices
• Arrange to make certain critical decisions late in the process

To learn more, see our column on frozen specifications,  read the article by Thomke and Reinertsen in the Fall 1998 California Management Review, or consult the extensive agile software development literature.

Quick Tip list  |  Product development publications  |  Home

 

How are other companies doing at managing project risk?

Not too well, and this is one reason why we decided to publish our book, Proactive Risk Management.

Typically today, a company has a stages-and-gates development process, and the first stage requires that the team identify and document the project's risks. Because this is a required deliverable, it happens, and the risks are discussed at the first project review.

However, this is as far as it goes, and the risks wait like a time bomb in the project file. The development process doesn't call for analyzing the risks, prioritizing them, or taking action against them. All of the benefit of project risk management stems from these later steps, which seldom occur.

Worse, when the identified but unmanaged risks start happening later in the project, it is embarrassing to the team and management to see that they had identified this risk but then done nothing to prevent or prepare for it. It would have been better to not have even identified the risks initially than to set themselves up for this embarrassment.

So, don't get caught in this middle ground. Either ignore project risk management altogether or complete the risk management process, even if only for a few of your largest risks.

Of course, our book or our project risk management services will help you put a beneficial project risk management process in place, but you can get started easily by reading some of our articles on the subject, such as, "A Portrait of Risk" or "Dealing with Project Risks Successfully."

Quick Tip list  |  Product development publications  |  Home