2001 New Product Development Quick Tips

How can our cross-functional team make decisions that stick?

Many product development teams waste both time and labor repeatedly revisiting their decisions. Are your team decisions determined by the loudest or most eloquent speaker? Does management overturn your decisions because they lack a solid foundation of logic or facts?

Cross-functional team decisions are at the very core of the product development process. If you dissect a project, you will find decisions - many of them cross-functional ones - in the "inner loop" of the process. You will make thousands of these decisions to complete your project. It follows that if you can accelerate or improve decision-making, you will be repaid a thousand fold.

The value of speed in making decisions is obvious, but what distinguishes a "good" decision? A good decision is tough; it is robust. It is resistant to being overturned, because it is built on solid facts that team members agree on.

Fortunately, there is a pragmatic theory of robust decision-making. It centers on the fact that each person's contribution to a decision has two dimensions, his/her certainty about how well a particular solution performs and knowledge about the performance. If a person expresses great certainly but has no knowledge, they are likely to be wrong, no matter how convincingly they argue.

Robust decisions not only save time. They also strengthen the team and improve its morale. Who wants to be on a team that the boss is always overruling? A robust decision will stand up to the boss' scrutiny, because it is the best one that can be made under the circumstances.

To explore robust decision-making further, visit https://www.davidullman.com/robust-decisions

Quick Tip list | Product development publications | Home

How can we keep from being blindsided when world priorities shift?

The tragic events on 11 September 2001 prompted changes for all of us. Beyond the enormous human toll, many businesses faced a new and different world. In many cases, the products and services they offered no longer fit the new circumstances. They needed to make changes - quickly.

To me, the prime benefit of a rapid development capability is this agility to make changes in product offerings quickly. This is not the majority view. When time to market was a hot topic nearly a decade ago, most managers believed that it was something they should apply to every one of their projects.

Instead, we advised that rapid development was a kit of tools - a capability if you will - that should be applied selectively only when the economics of the project at hand demanded it. Few managers have appreciated the latent benefit in being able to move quickly if their market demanded it. Today, many wish that they had cultivated such agility.

Many companies have pursued a Web-enabled, do-it-right-the-first-time, stages-and-gates development process that is efficient in stable times. But such processes often have baggage built into them that channels every project through the process in the same predictable way. They lack the agility to put certain projects in the fast lane.

Many of the publications on this Website will help you build agility into your process. To learn more about the limitations of gated processes, read our last Quick Tip. For more on the fallacy of do-it-right-the-first-time, see our PDBPR column.

Quick Tip list | Product development publications | Home

Should we be using a stages-and-gates product development process?

If you are using a development process with stages and gates, you are in the mainstream: the majority of companies develop their products using such processes, according to authoritative sources.

Gated processes have a couple of attractive advantages:

They allow management to monitor progress easily and ensure compliance with objectives.
They facilitate scaling up investments in the project as information becomes better, thus conserving development funds.

I believe that gated processes are popular because they save management's time and fit well with the cost-cutting directives under which many managers operate.

However, these processes are weak in other areas, which is not widely appreciated. First, the gates introduce hurdles that essentially slow the process down in several ways. Advocates of gated processes have introduced concepts such as "fuzzy gates" to deal with this, but the essential delays remain.

Second, using stages suggests that development proceeds sequentially, which is a slow way to reach market. Recent research at MIT has shown that iteration is essential to innovation, so sequential processes are fundamentally at odds with innovation.

Third, the gates suggest a primary emphasis on conserving funds. Our analyses of many projects suggests that, most often, development expense is less important than time to market, product cost, or product performance. If this holds for your project, a gated process may be focusing on your least important development objective.

Consequently, whether or not you should be using such processes depends on what you want to achieve..

Quick Tip list | Product development publications | Home

Is there anything to know about failure beyond not punishing those who fail?

Every manager, especially those leading product innovation, knows that punishing those who fail will discourage taking further innovative steps, whereupon innovation will wither. Clearly, some of us are better than others at applying this theory.

Yet, even if you respond to failure excellently, you are merely tolerating failure, not exploiting it. The key to exploiting failure is to recognize that product innovation is simply a sequence of steps for learning how to satisfy the customer. Often, we can learn more and learn it faster from a well-executed failure than from a success.

Say that you are testing a wing structure for an airplane you are developing. It can take years to determine that a wing is strong enough, but you can make it fail quickly. From this learning about the wing's failure points and modes, you can move forward much faster.

Consequently, an innovation strategy that judiciously balances success and failure is more effective than one aimed solely at success. To operate in this way, consider three things:

Think carefully about the sequence of trials that will help you learn most efficiently. Depending on the trial's nature, some should be biased toward failure, some toward success.
Communicate to all your plan and why some trials are likely to be failures. Otherwise, they will regard your failures negatively.
Question the popular mindset of doing it right the first time.

To pursue this topic, see our PDBPR column.

Quick Tip list | Product development publications | Home

I know that innovation is naturally chaotic, but can't we anticipate problems better?

Yes, you can. But first, you must know what kind of chaos you have. Perhaps you aren't anticipating or managing project risks well, so proactive risk management would help. If customer requirements keep shifting, focus on better ways of keeping in touch with the marketplace, such as incremental innovation or creating personas.

But often the chaos is inadvertently built into our development processes. We rely on sequential stage-and-gate processes, which presume that all information is available when a task starts. However, in reality, late-stage learnings often necessitate redoing earlier steps. We also use project management tools, such as Gantt and PERT charts, which are predicated on successor tasks following predecessors with no allowance for looping back.

MIT professor Steven Eppinger has found that development processes are often routinely (but unknowingly) arranged so that an activity requires information from a subsequent task. When this happens, iteration is assured. Although some of this iteration is essential to innovation, much of it can be eliminated by judiciously rearranging activities, combining activities, or by adding bridging activities. Moreover, analysis of a development process will identify the essential iteration so that the loops that remain are known and can be managed.

Eppinger discovers, eliminates, and manages iterative loops by portraying activities in a Design Structure Matrix that clearly shows the tasks that require information from subsequent tasks. You can read about this tool for managing iteration in his article, "Innovation at the Speed of Information," in the January 2001 issue of Harvard Business Review.

Citation information for this Quick Tip: ISSN 1529-1928, 10 June 2001.

Quick Tip list | Product development publications | Home

What resources on the Internet do other product developers use?

You may recall that a few months ago a Quick Tip suggested where you could read about the latest product development advances in print media.

As part of that research, we discovered that many developers were instead getting their information straight from the Internet, so we partnered with Management Roundtable, http://www.roundtable.com, to discover how product developers use the Internet. Ironically, one discovery from the 6112 developers polled was that the Internet doesn't seem to be as popular as the hype would suggest: the response rate for this survey was only 3.2%, compared with 21% for the print media survey!

We thank those of you who responded to this survey.

We found that online sources differ, depending on the objective. When seeking answers to a specific question, the three top tools, in order of popularity, are search engines, specific Websites, and corporate libraries/intranets. But if they instead want to keep up to date regularly, developers turn to e-mail newsletters, online publications, and corporate libraries/intranets.

The top search engine by far is the Google/Yahoo pair; followed by AltaVista; then, at a distance, Excite, Northern Light, and Dogpile.

Corporate online libraries and intranets are especially popular among large, well-established companies, but we found that they (probably unknowingly) discourage developer's access to challenging, alternative means for developing new products or understanding competitors.

Quick Tip list | Product development publications | Home

How can I capture the voice of the customer?

Our 20 October 2000 Quick Tip dealt with "hearing" the voice of the customer. Having "heard" this voice, the next question is how we can capture it in a way that continues to guide us as we develop our new product.

The conventional wisdom here is to use a technique called QFD (quality function deployment). However, our experience has been that QFD can easily consume inordinate amounts of time and resources.

Alan Cooper suggests an alternative: personas. A persona is a carefully crafted composite description of a certain class of a user. You may have several personas for your product, but each comes directly from your detailed customer research, and together, they encompass most of your anticipated user base.

To render a persona real, its description includes a photo of the individual and a description of his or her idiosyncrasies. For specific examples of personas, see our review of Cooper's book.

Once you have captured your principal users in a persona, you simply design your product to satisfy this persona. If you have done a good job of building your personas, your product will satisfy the needs of your principal persona and not alienate any of your other personas.

Note that this is a far different approach than the more common one of designing a product to provide all of the features that competitors provide -- which doesn't assure that any users will be happy. Furthermore, copying competitive features is a prescription for being a follower!

Quick Tip list | Product development publications | Home

How can I make our plans to improve product development "stick?"

Each year product developers often plan (or hope) to do a better job of developing new products in the next year. It is much like New Year's resolutions, which we make on a personal level.

However, at about this time of the year -- toward the end of January -- these people realize that other priorities have overtaken their plans for making process improvements. Later, looking back at the end of the year, they see that they never got around to implementing their well-intentioned plans.

Since this is the perfect time of year to recognize this phenomenon and correct it, let's consider two things you can do now to make headway on your plans to develop products faster, better, or cheaper.

First, recognize that process improvements are an investment in a more effective -- thus more valuable -- organization. "Investment" is the key word here. These improvements are not free; if they were free, you would already be incorporating them. Consequently, in order for them to happen, you will have to allocate specific time and money to them, just as you would for a corporate investment in additional office space or new computer system. For instance, your personal time to implement the change must be budgeted into the investment plan. If it isn't, you will never be in position to "take" time from activities that generate revenue more directly.

Second, think small. Make your plans and investments in small but sure steps. Resolving to do too much is precisely where most New Year's resolutions fail.

To learn more, see our article, "Your Product Development Process Demands Ongoing Improvement."

Quick Tip list | Product development publications | Home