2005 New Product Development Quick Tips

What is lean product development?

This term confuses me. Fortunately, lean development consultant Katherine Radeka of Rapid Learning Cycles has brought us some clarity. She interviewed 42 experts in the lean product development community and discovered that there are five basic varieties of lean development:

Lean design, design for six sigma, and design for lean manufacturing, which ensure that new products are designed to fit with lean manufacturing.
Direct applications of lean manufacturing tools to product development, especially value stream mapping to eliminate waste and improve flow, 5S, and kaizen events.
Direct applications of Toyota's product development practices, which differ fundamentally both from lean manufacturing and from conventional product development practices, especially in using A3 reports, set-based design, knowledge reuse, and chief engineers.
A principles-based approach, which abstracts ideas from the spectrum of lean literature and integrates them with "best" practices in product development to create a system of lean product development. This system differs radically from the product development practices of most companies today.
Those who re-label "best" practices in product development as "lean" because they appear to eliminate waste, thus exploiting the lean label as a marketing tool. They use the label without a deep understanding of lean principles or a systemic approach.

Radeka observed that few of those she interviewed fit completely into one category (none in the last one). The differences usually stem from differing backgrounds and experiences in manufacturing, design, or product development.

Consequently, if you suspected that "lean" hadn't jelled in product development as it has in manufacturing, now you know why.

Quick Tip list | Product development publications | Home

How can we take advantage of globalization's product development opportunities?

The world is undergoing some enormous changes, and you are likely to be either a victim or a beneficiary of them. For example, some people in the United States worry about job losses due to outsourcing (for example, see the book, Outsourcing America). However, job losses are a far larger threat to some developing countries, which can ill afford them.

But, being product developers, these displacements also create great opportunities for those who watch trends and think creatively—and globally! For example, Paul Laudicina, in his recent book, World Out of Balance, illustrates how General Electric spotted trends in world water shortages and air pollution and turned them into profitable, growing new businesses.

Laudicina describes three areas that will affect product developers: global market shifts, closing some markets and opening others; changes in how consumers evaluate, use, and dispose of products; and demographic, environmental, and regulatory changes in how we will be able to develop products. These changes stem from five broad factors: globalization, demographics, consumers, natural resources and the environment, and regulation and the environment.

What to do? I suggest that we start thinking out of the box—or, in this case, way beyond the 12-mile limit from our shores. I was amazed today at how insular my thinking was when I looked at the list of product developers to whom I'm sending this Quick Tip—from a nominally American firm. The ten most numerous names on the list are, in order: Chan, Wong, Lee, Smith, Wang, Tan, Johnson, Zhang, Cheung, and Li!

Quick Tip list | Product development publications | Home

How can we improve the flexibility of our product development process?

Recall that the last Quick Tip explained the benefits of flexible product development. Now I mention some techniques you can apply to make your product development more flexible.

One, making decisions at the last responsible moment, was covered in an earlier Quick Tip.

Another is timeboxing. Because the plan is in flux in a flexible project, measuring progress relative to an overall plan doesn't work. Instead, carve out small, measurable chunks of work and put each one in a "timebox" of time and resources. Then measure each of these tasks relative to its timebox—it counts only when it is finished. This technique is also valuable for controlling scope creep.

One more approach to planning a flexible project is rolling-wave project planning. Recognize that the long-range plan will change, so complete it only at a general level. At the start of each facet of the project, do your detailed planning only for that facet, and then plan the next facet or two moderately, leaving everything after this at the general level. When you start on the next facet, plan it in detail, and perhaps do another step of moderate planning. Thus, the wave rolls on and you haven't wasted time planning something that will change anyway.

For an outline of many more flexibility techniques, see the brochure for the premiere of our flexible product development workshop. Better yet, attend the workshop and gain hands-on experience in applying the tools to an actual development project.

Quick Tip list | Product development publications | Home

How is flexibility beneficial in developing new products?

Product developers are being squeezed from many directions: lower-cost products, lower headcount, higher quality, more product features, and faster to market. With all this pressure, another important factor has gone relatively unnoticed—except in software development: flexibility. Flexibility is the ability to make changes in the product's design, marketing, sourcing, or other factors relatively late in development without being too disruptive.

Flexibility is becoming important for the same root reason that the other factors—time, cost, etc.—are important: the world in which we live is becoming more competitive and chaotic. Changes are occurring faster than they did formerly. With quick changes, there is greater value in being able to react quickly but smoothly. Research shows that the companies that can react to customer requirement changes, evolving technologies, market shifts, political and regulatory turbulence, and management shuffles are the ones that win in the end.

However, this isn't easy. Management techniques generally place value in stability, for instance in finalizing product requirements before starting design. Resource planning systems, six sigma programs, and most metrics approaches emphasize a plan-your-work then work-your-plan style. Consequently, managers unwittingly work toward stability at the expense of flexibility.

You can enhance flexibility in several ways: teamwork, product architecture, decision-making strategies, and prototyping approaches. I will discuss these in our next Quick Tip.

For more, see our 5 March 2004 Quick Tip list | Product development publications | Home

What are the keys to installing a new product development process?

Parts of the answer are obvious. You must provide easy-to-use documentation, which is usually in an online format today, and you must train the workers and ensure that management receives an executive version of the training so that they know how to guide the new system toward success.

But the most critical task is to understand how the new process aligns with or contradicts individuals' motivations. Many processes that look good on paper simply do not fit the culture of the organization and thus are doomed to failure. This isn't to say that you should make sure everyone is comfortable with the new process. Your objective may be to change the status quo, and this is quite legitimate. But if you are going to make such radical changes, you need to be especially careful in understanding alignment between the process and individuals' motivations.

The most productive development processes are seldom comfortable for developers or for management. If you wish to implement such a process, you must be especially careful in knowing where the friction is likely to occur so that you can take steps to lubricate these specific areas. You can find these friction spots by involving a variety of developers and managers as you create your process, both to obtain their feedback and build their ownership of the final solution.

For an example of the friction areas in one type of high-powered development process—agile software development—see our article, "Why Is Agile Development So Scary?"

Quick Tip list | Product development publications | Home

How can we accelerate the risk management process for accelerated projects?

Conventional project risk management, as described in our book, Proactive Risk Management, can be time-consuming, especially for fast-moving projects. We recently faced this problem in an agile software development project, which had to produce a new, working version of the software every month. With 30 days to deliver a product, you can't afford to take days to pass through the conventional risk management process—it must be done in an hour or two.

You can accelerate the process by greatly simplifying the risk analysis and prioritization steps. Rather than filling in the complete risk model and prioritizing your risks quantitatively, as the conventional process requires, simply have the team prioritize the risks using their perception of which risks are most serious. Then you can plan actions against your most serious risks.

Although such a radical shortcut would be dangerous for most projects, it works for an agile project because it exploits three characteristics of such projects:

Short (one month) iteration cycles, which makes forecasting risks much easier over such short periods
Frequent (monthly) opportunities for reassessment, which minimizes the effect of any errors in perception
A close-knit, co-located team, which has intimate knowledge of the project and thus is in a strong position to appreciate its risks

You can learn more about this technique by reading our recent article, "Agile Risks/Agile Rewards."

Can you find similar characteristics of your projects that you can exploit to accelerate managing their risks?

Quick Tip list | Product development publications | Home

What if time-to-market doesn't completely satisfy our objectives?

Many clients place great emphasis on rapid development, both for its direct market payoff and for its beneficial side effects. For instance, speed often ties to efficiency. Consider the efficient movements of a speed skater or the clean tack of a racing yacht.

But often you have other important objectives in developing a new product, such as high reliability in a life-critical device, or tight cost constraints on a mass-market consumer item. How can you blend such objectives with speed?

Barry Boehm, in his recent book, Balancing Agility and Discipline, shows how to do this for software development, and you can adapt the technique to non-software products. See a review of this book . Boehm assesses a project's objectives on five relatively independent axes. For instance, one axis is dynamism, which measures flux in product requirements.

Associated with this, you can ask, "How much requirements planning is best?" If you spend lots of time in detailed requirements planning when the requirements are likely to change anyway, you risk much wasted planning effort. On the other hand, if you do not plan requirements enough, you risk missing an important requirement or not understanding one well enough. Between these two extremes is a "sweet spot" where the opposing risks are acceptable. The sweet spot's location varies by project but depends on several factors that become apparent as you assess the opposing risks.

Furthermore, exploration of the opposing risks may suggest effective management techniques that control both risks at low cost. For instance, rapid prototyping may allow robust assessment of requirements without extensive requirements planning.

Quick Tip list | Product development publications | Home

Should we depend on Sales to keep our customers happy?

The "standard solution" to product development is to have sales or marketing people work with customers in the field while highly paid design engineers work in the laboratory without distraction so they can develop new products quickly. This solution has its strengths. It does allow developers to concentrate, it keeps them from "confusing" customers with "strange" ideas, and it exploits the broad field exposure that sales and marketing people receive.

The biggest problem with this is that the developers are making thousands of small design decisions daily that accumulate toward a product that either delights or frustrates customers. For instance, have you ever tried to use a strange DVD remote control with 50+ buttons to simply pause and restart a film? Do you think that its designers ever studied novices like us trying to use their remote?

Thus, it is essential to find some way for your product designers to experience regular, direct contract with the customers using your product. I find that each company doing this well finds a unique, clever way to connect with its customers. For example, Boeing invites customers (airlines) to move in and sit with the design team throughout development. A small company developing building security alarms sent the team out to watch their product being installed. A maker of construction equipment schedules design engineers to answer customer support calls for a full day each quarter.

Suggestion: look at the nature of your products and customers—and their proximity to you—and create some way for your designers to maintain regular contact with them (rather than copying another company's method).

Quick Tip list | Product development publications | Home