2000 New Product Development Quick Tips

 

Where can I read about new product development techniques?

This is more difficult than it sounds, as product development spans several disciplines and many industries. But I wanted to know the answer to this question too, so I asked the 1000+ readers of these Quick Tips what they read that helps them to improve their product development practices. Thanks to all who responded, here is the top ten list of what you read (with the number of mentions of each):

Harvard Business Review (52)
Journal of Product Innovation Management (27)
Machine Design (24)
Design News (22)
Wall Street Journal (19)
Project Management Journal (17)
Fast Company (16)
Business Week (14)
Mechanical Engineering (14)
Research-Technology Management (13)

Just as interesting, many readers responded by saying that when they want to learn about product development practices, they don't turn to magazines or journals at all. Instead, they would conduct an online search. Some sources of online product development help are available on this website. Perhaps we should conduct a survey of Quick Tip readers to discover other such sites.

For greater detail, see our periodicals survey.

The keystone to fast, effective product development is high-performance teams. To keep current on this subject, you can benefit from TeamWisdom Tips, a weekly tip sheet for technical professionals who share responsibility with others to get things done but don't have authority over them. Written by a noted expert on technology collaboration, each of the TeamWisdom Tips provides one thinking skill or communication tool that contributes to highly responsible and productive relationships at work. Get it online at http://www.christopheravery.com.

Quick Tip list  |  Product development publications  |  Home

 

How do I hear the voice of the customer as I develop a new product?

Product developers have learned over the past decade that they should listen to the "voice of the customer" as they design their products. But this just begs the more difficult question: "How do I 'hear' this 'voice'?"

The good news is that we all have the voice of a customer inside of us, based on our life experiences over the years. In computer lingo, we come with a "default" voice "installed" inside of us.

The not-so-good news is that this default customer can be highly untypical, so it is a dangerous design reference. Alan Cooper, in his book, The Inmates Are Running the Asylum, explains why so many computer products are maddening to use. (See our column, "Are your Inmates Out of Touch?") Many computer and software products are designed by engineers living in Silicon Valley, which is a highly atypical place. Everywhere you turn in Silicon Valley, you run into engineers, so the engineers who work there soon think that all customers are as capable of using their product as the people they encounter every day.

To design products for typical users and customers, take some time and effort to get out into their world. The best ways of doing this are creative and highly industry specific. For instance, Black & Decker sends their designers out with service technicians in vans that visit construction sites and do-it-yourself stores. Hewlett-Packard stations them in shopping malls to watch customers fumble with HP products. This isn't hard to do, but you have to make the effort to identify typical customers and then take the time to "hear" them regularly.

Quick Tip list  |  Product development publications  |  Home

 

Doesn't rapid product development mean that quality will suffer?

In our increasingly internetted world, information propagates faster and markets shift more rapidly. Consequently, many of our clients continue to shorten their product development cycles.

But speed has its dark side. Most of us have seen a development project go awry because it was rushed and important activities were skipped. More deeply, we have heard since childhood that "haste makes waste" and that "quick" leads to "dirty." No wonder that we are suspicious about accelerating product development.

Fortunately, there is a bright side to speed: done well, speed is complementary to quality. When we dig into a specific project to see where its cycle time went, we discover that it vanished while waiting for resources, decisions, and information. When this happens, both speed and quality suffer. More time was wasted when work had to be redone due to poor communication or weak plans -- again, a quality problem too.

It is no accident that many athletic events are races against time. A runner is able to win only when everything is in perfect condition: the training, the field, the equipment, and the runner's health and diet. Runners who skip a few training sessions or skimp on coaching don't win races.

Product development is the same: winning speeds are possible only when all conditions are carefully set up for the highest quality performance.

In fact, even if you do not need speed in every development project, speed is perhaps your best comprehensive measure that everything influencing your development process is operating at its highest quality level.

To pursue this topic, see our paper, "Reaping Benefit . . . ."

Quick Tip list  |  Product development publications  |  Home

 

How can we avoid "technology push" without avoiding technology?

Too many engineers have been warned by their marketing counterparts to avoid "technology push." Consequently, they are reluctant to mention using new technology at all. This is dangerous today, because many new technologies can greatly improve products or their associated processes, such as manufacturing or field service. Failing to apply technology appropriately can leave your firm open to fast, young competitors.

On the other hand, new technology does get applied before it is ready, it appears in applications for which customers have indicated no interest, and it can add cost, development cycle time, and complications without adding commensurate value.

Two popular books, Crossing the Chasm and The Innovator's Dilemma, address such difficulties in dealing with technology. However, to me, they are rather theoretical and lack practical how-to information. A book that is more useful for managing technology on a daily basis is F. Michael Hruby's TechnoLeverage.

TechnoLeverage shows through examples how to apply technology to new products in both mature and brand new markets. In fact, the book's strength is in showing how competition differs in mature and new markets, and how technology must be managed differently as a market evolves from exotic to commodity.

To pursue this topic, see our review of TechnoLeverage.

The Quick Tip series exists to keep you up to date in the product development field. Please let us know about the issues you are dealing with today so that we might address them as a future topic. How could Quick Tips serve you better?

Quick Tip list  |  Product development publications  |  Home

 

How can we really benefit from rapid prototyping?

Rapid prototyping has arisen over the past fifteen years. It allows product developers to make physical parts from designs in hours, in contrast to the weeks required by traditional machining methods. Most of those doing rapid prototyping focus on making parts still faster or on making better parts. For instance, they strive to make parts that are stronger, cheaper, or more environmentally friendly.

Amazingly, few companies are taking full advantage of the latent timesavings in rapid prototyping. Yes, they do make models faster, and this saves them some time overall. But they have not redesigned their development processes to reap major gains. To use an analogy, they now use cellular phones -- but only from their offices -- as this is where they have always done their phoning.

This topic is timely, because the newest generation of rapid prototypers, variously called desktop modelers, conceptual modelers, or 3D printers, offer great potential for overcoming major development delays. These rapid prototyping systems are especially valuable in the fuzzy front end of development (for details on the fuzzy front end, see Chapter 3 of Developing Products in Half the Time.

For example, large fuzzy-front-end delays often stem from obtaining approval from marketing or sales for a concept that engineering has developed. Lots of quick models are perfect for "forcing" a decision at this point, which often saves weeks or months from normal corporate decision-making cycles. Few companies recognize this opportunity; still fewer are doing anything about it.

To pursue this topic, see our article "Rapid Prototyping Accelerates the Design Process.

Quick Tip list  |  Product development publications  |  Home

 

What are some day-to-day tools for dealing with project risk?

Several months ago we suggested a technique for the overall management of risk in a development project. Within that broad framework, here are some tactical measures that you can apply daily.

First, simply avoid risk whenever possible, for example, by reusing proven designs and components. Although this seems too simple to mention, many projects incur unnecessary risk due to redesigns making something slightly better.

Stay flexible on a major unresolved issue. This is generally an expensive option, so you can't use it often. But it can allow you to move ahead in a major area of uncertainty.

Keep in touch with customers throughout the project to ensure that you are still meeting their needs. Their needs will undoubtedly change as your project proceeds!

Identify the showstoppers initially and work on them first. This is not natural human tendency, but your whole project depends on resolving these critical risks.

Place your risk where you can keep an eye on it. Too often, we disperse risk throughout the product. Then we lose track of where the high-risk areas are.

Resolve risk at the lowest level possible. Don't wait until you have a prototype product to test. Instead, run earlier tests of subassemblies, or better yet, components.

Plan to fail. Think of risk management as a process of learning. Interestingly, we don't learn very fast if we always succeed!

For a fuller explanation of these tools, see our paper on risk management.

Quick Tip list  |  Product development publications  |  Home

 

Haven't virtual development teams superseded co-located ones?

We are moving toward virtual product development teams, due to globalization, the fragmentation caused by corporate acquisitions, and greater reliance on supplier chains.

However, many managers cave in too easily to this "progress." They fail to appreciate that dispersed teams -- especially virtual ones -- always lose some of the effectiveness that co-located ones enjoy. In their book, Virtual Teams, Lipnack and Stamps, who have been promoting virtual teams for twenty years, state, "On the whole, a virtual team must be smarter than a conventional collocated team -- just to survive." (page 189) Likewise, Duarte and Snyder's Mastering Virtual Teams emphasizes, "The complexity of communicating over time, distance, and organizations causes unique problems that are not easy to solve." (page 77)

Basically, a co-located team brings higher performance at a certain cost of implementation. When time to market is vital, the speed of a co-located team can easily outweigh its cost. If you cannot completely co-locate, then partial co-location can bring much of the benefit at a fraction of the cost. For example, both sets of authors quoted above advocate bringing the team together face-to-face at the beginning of the project to build trust, establish their working processes, and resolve the fuzzy definitional issues that occur at a project's outset.

You can also analyze your teams' communication patterns to see just which individuals would benefit most from co-location.

Duarte and Snyder's book provides much guidance in choosing virtual technologies appropriate to the task at hand. This book also guides you in building and managing virtual teams.

Quick Tip list  |  Product development publications  |  Home

 

What should my boss do to speed up product development?

No better topic for starting a new year. Several years ago, I gave the following answer to a Silicon Valley CFO who asked this question, and my response remains the same:
    - Calculate and apply the Cost of Delay (for more on this, see an earlier Quick Tip.
    - Prohibit project overload.
    - Set up an environment enabling teams to run themselves (see two handbook chapters).

This last point is the essence of leadership -- as contrasted with management. Leaders recognize that the individuals and teams doing the work have better, more timely information to make decisions than they do, so they view their role as enabling rather than controlling progress.

Thus, under a true leadership environment, responsibility for success shifts back from the boss to the individual. In seminars I lead, participants often say, "I wish my manager were here to hear this." There is certainly some truth here, but the most powerful thing most managers can do is to lead their organizations out of the Dilbert mentality.

For more on management's role in general, see our article or Robert Cooper's book on the subject.

(I purposely keep these Quick Tips short -- 250-300 words -- and provide links to the details for those who have a deeper interest. This Quick Tip leans even more in this direction. Please let me know what makes the best use of your time.)

Quick Tip list  |  Product development publications  |  Home