2003 New Product Development Quick Tips

How should we incorporate technology tools into our development process?

Modern computer technologies can accomplish wondrous things. I recently accepted a volunteer position that required keeping track of many disparate pieces of information, coordinating them, and making commitments based on them. Database technologies, unavailable just a few years ago, were the perfect match to my needs.

However, many managers who apply computerized tools to their development processes, be they computer-aided engineering tools or a complete Web-based development process, do not obtain the benefits they seek.

To obtain real business benefit, you must do two things - neither of them involving technology. First, you must analyze your current business situation and objectives before you chose a technology. Otherwise, you will be solving the problems that the technology's developer had in mind, not necessarily your own needs. In short, analyze your needs first, then go shopping for technologies that resolve your need.

Second, once you install the technology, recognize that the hard work lies ahead. Now you must change behaviors, and perhaps even your culture, to reap the benefits of your new technology. For example, for my new database technology, whose objective was to track disparate bits of information and commitments I had made, I had to adopt a new habit of stopping whenever new information arrived to enter it into the database so that the database remained up to date. Without this change in behavior, the new technology was useless.

Most companies are willing to invest lavishly on new technology, but they greatly underestimate the labor, time, and money needed to make the associated behavioral changes. For more on this, see our recent column, "It's Not About the Technology."

Quick Tip list | Product development publications | Home

How can I tell if we did well at developing our last product?

The last person you should ask regarding this question, according to Harvard Business School professor Alan MacCormack, is your boss. MacCormack's research paired a "good" and a "bad" project from the same company, as chosen by executives of that company. Quite surprisingly, he found that the "bad" project was a marketplace success, while the "good" one wasn't.

Further investigation showed that managers rated a project highly when it had a product specification up front that remained stable, and they delivered a product that satisfied the original spec. In a "bad" one, the final product looked completely different than the original spec.

The strongest indicator of the marketplace successes (the "bad" projects) was that the team placed a working version of the product in customer's hands very early and used customer feedback to revise product direction and features accordingly. These folks knew they didn't have all the answers, so they used early releases and customer reactions to set the direction, in contrast to setting an inflexible direction at the outset.

MacCormack also discovered some other elements of flexibility. The teams that designed the marketplace successes found ways to react quickly to market feedback, and they chose product architectures that allowed changes to be made easily rather than using the lowest-cost architecture.

MacCormack's research focused on Internet software projects, where market uncertainty is high, so his findings may not be as applicable to established products. However, he provides a sobering reminder that it isn't so bad to listen to customers and redirect your project accordingly.

Announcement: this Quick Tip completes five years of publication (40 issues) of this series.

Quick Tip list | Product development publications | Home

Do "rapid" prototypes really speed up product development?

They can, but few product developers use them in a way that yields any real speed advantage. Consider that an ordinary prototype might take a month (20 workdays) to make, and a rapid prototype takes a day. Assuming that this prototype is on your critical path, you save 19 days, which is 4% of a two-year project -- not impressive!

However, developers who apply prototypes wisely often see timesavings of 50%. They do this by viewing each prototype as an opportunity to answer a question. They ask their question clearly, build a simple prototype to answer only this question, get their answer quickly, and move on to another round of prototypes to answer the next set of questions.

That is, they view product development as a series of questions to be resolved, and they use prototypes to resolve these questions early, quickly, and precisely. Compared to normal prototyping, they "front-load" their prototyping by building many more prototypes earlier and focusing each one on a specific question. (Traditional prototypes are too infrequent and appear too late to provide effective feedback.)

Surprisingly, those who front-load their prototyping usually pay less in total for their simple prototypes than those who build a few elaborate prototypes late in development for verification.

To learn more, read some of the prototyping publications on this website, or see Stefan Thomke's new book on contemporary experimentation.

Quick Tip list | Product development publications | Home

Our team doesn't get much done as a team. What can we do?

First, ensure that you have a strong, well-understood project objective. Strange as it may seem, many teams don't. Morgan Swink, in an excellent article in the July-August 2002 issue of Research-Technology Management found that of 18 factors, lack of explicit project goals caused greater lateness (70% longer than planned) than any other factor.

Then make sure that you know the project's priority and that all of your projects aren't first priority. Chapter 11 of our book, Developing Products in Half the Time is devoted to this pervasive problem.

Next, consider who is on your team. Are they really working toward the team's goals or just hanging around for other reasons? It is helpful to use a breakfast analogy here. Consider a skillet of ham and eggs. The pig is committed to the breakfast, but the chicken is only involved. If you also have a glass of milk for breakfast, the cow is even less involved, contributing some nourishment, while the chicken contributes another's life. On your team, you want as many pigs as possible and to rid yourself of the cows and maybe even the chickens.

Finally, recognize that you receive back in performance what you put into building a team. Really effective teams require effort to set up. Our Quick Tip on this topic provides the details.

Quick Tip list | Product development publications | Home

What else can we do to facilitate talking about risk?

In the last Quick Tip, we discussed how difficult it is for many people to discuss a subjective, rather negative subject like risk. If you are going to be successful in managing project risk in your organization, you must find a way to "bring risk out of the closet." Fortunately, there is an excellent way to do this.

The solution is to paint a picture of each risk. Unlike an abstract Picasso, the picture is in a standardized format that is familiar to everyone in the organization. We call our version of the picture a risk model, but this term perhaps scares some individuals needlessly.

Regardless of what you call it, the picture should show the components of the risk in familiar locations, and the relationships between the components should be clear. There should be places to list all of the facts you know about the risk. Facts are critical, because they are the key to making a risk less threatening or subjective. Team members can discuss facts rationally, whereas they will argue about the risk itself and never reach consensus on it. Furthermore, these facts will lead you directly to effective actions that you can take to mitigate the risk.

To see how this works, including two case studies, read our article, "A Portrait of Risk."

Quick Tip list | Product development publications | Home

How can I manage my project's risk when my boss won't even discuss risk?

Let's admit it: discussing what might potentially go wrong with your project is difficult for a few reasons. First, it is an unpleasant subject about things we would rather not think about. Second, it suggests that you cannot handle these things yourself. And third, your boss probably has many actual problems to deal with now, so discussing potential ones seems like a luxury.

Risk is an unpleasant subject. But it is your job to identify what might go wrong with the product you are developing - perhaps someone might get hurt using it or a key supplier might go out of business, for example. And it is your job as a manager to do something about such problems.

By discussing risk, you aren't saying that you can't handle it. Quite the opposite, you are saying that you are very much aware of it, and you know just what you will do about it when the time comes.

As for your boss, his or her concentration on present problems is a self-fulfilling prophesy: tomorrow's potential problems will become actual problems tomorrow, and they will be much more expensive to deal with then. This is the essence of firefighting.

The key to managing project risks well is to list the facts influencing the risk and then manage these facts rather than managing the risk itself. To the extent that you keep your discussion at the facts level, it will be much easier to communicate with management.

For more on this topic, see our article on talking about risk.

Quick Tip list | Product development publications | Home

When co-locating our team isn't practical, what can we do?

If you have read our book, Developing Products in Half the Time, you will recognize that we strongly advocate physically locating cross-functional team members close together (within 10 meters of each other), which greatly improves the speed and accuracy of the voluminous cross-functional communication needed to develop a winning product.

Unfortunately, in today's fragmented world, true co-location is increasingly difficult to implement. Electronic tools, such as e-mail and Internet conferencing have attempted to fill the gap, but they fall far short of the richness of real face-to-face conversation.

The trick to dealing with this reality is to recognize that even partial co-location pays large dividends. If you can't totally co-locate your team, consider:

Co-locating your team for only part of the project (which should be the initial period - the first two hours or the first two months of the project)
Identifying the most critical communication partners, such as the lead design engineer and the marketing representative, and co-locating them
Co-locating all team members in each city in a single small room so that your team is at least clustered
Reconvening the team in a single location periodically to rebuild relationships and deal with particularly difficult, abstract, or political issues

For more help on overcoming the difficulties of "virtual" teams, see our article on dispersed teams.

Quick Tip list | Product development publications | Home

How can we accelerate decision making, particularly in the fuzzy front end?

This is an insightful question, because if you dissect the product development process, you will find that decisions are at its core, and accelerating them will speed up your whole process greatly.

Decisions in the fuzzy front end of development have major downstream ramifications, so various parties -- engineering, marketing, suppliers, and executives -- think about them carefully. These decisions often involve alternative product concepts or variations in a concept.

What better way is there to communicate a concept or its possible variations than to build a prototype of it? Prototypes bring realism to something that doesn't exist yet. Unlike engineering drawings, everyone can "read" them. Well-positioned prototypes bring closure to concept decisions.

However, to accelerate fuzzy-front-end decision-making, you must build a sequence of prototypes that parallel the decision-making sequence. This means that you must build a sequence of simple prototypes, each of which resolves only one question. The biggest mistake that prototypers make is in building prototypes that are too complex, too late in the process, and too final. Too complex means that multiple decisions become intertwined, too late means that people become wedded to a concept, and too final means that these highly refined prototypes are time-consuming and expensive to make.

Various prototyping technologies can model products that exist as software, digital circuits, analog circuits, or paper documents, but probably the most interesting prototypes model mechanical objects. Such prototypes now cost US$10-20, enabling you to afford the dozens needed for fast, precise decision-making.

Quick Tip list | Product development publications | Home