2008 New Product Development Quick Tips

What is the most important factor in improving product development?

As realtors are fond of saying about buying houses, there are three important factors to consider in improving how you develop new products: people, people, and people. But how quickly we forget this and put our energy instead into processes, approaches, and tools. Chapter 6 (page 126) of Flexible Product Development has a chart showing that people are about ten times more important than processes (see this chart).

One reason that people are paramount is that experienced, motivated people tend to fix anything else that gets in their way, such as a process bottleneck or an organizational reporting problem.

People includes connections between people, that is, teams. You can do plenty to improve teams, but in fact, we have mostly moved backwards on teams over the past couple of decades. One area we have weakened is in failing to dedicate a person to one project. Dedication provides a host of benefits, one of which is accountability (if you are assigned to multiple projects, you can always claim that you were working on another one when asked what you accomplished on a certain one).

Another powerful team characteristic that we have slipped away from as we globalize is co-location. In the Flexible Product Development book (pages 141-150) I provide three types of 21st century support for co-location and show how you can derive great benefit from co-locating partially when complete co-location is impractical.

For more on this topic, see our recent article, "Effective Development Begins and Ends with People" in Cutter Consortium's Agile Product & Project Management Advisory Service.

Quick Tip list | Product development publications | Home

How do I manage risk on a project that keeps changing?

Let's start with the easier (and often more common) situation where there is little change during a project. This is the situation tacitly assumed in the project management literature, and it is the one covered by our book, Proactive Risk Management. In this case, you have a project plan that is relatively stable, and from it you can build, in a methodical way, a risk management plan. Proactive Risk Management shows you how to do this, as do other books on project risk management.

When your project is subject to constant change, you lack a stable project plan for building your risk management plan. However, managing risk becomes even more important in this volatile environment. This calls for a radical change in risk management strategy.

I call the more stable situation integrated risk management: risk management is integrated into the project planning, and each significant risk becomes just one more task in the project. When change is the norm, you must shift to intrinsic risk management, which means that everything you do to manage the project is done with the aim of managing its risk. You keep in touch with customers to manage customer-initiated changes, you use modular architectures to encapsulate design changes, and you conduct lots of experiments to understand the ramifications of changes. These topics happen to be chapters 2-4 of my book, Flexible Product Development, and, in fact, the whole book is about intrinsically managing risk in a changing environment.

For more on this, see a recent article, "Managing Project Risks When Change is the Norm."

Quick Tip list | Product development publications | Home

Why is listening to the customer so difficult?

In the last Quick Tip (below) I emphasized the power of iterating: placing a "first try" of your product into customers' hands quickly and adjusting from there. As usual, there were some astute observations to this advice. One respondent said, "You need to be very smart in order to realize when you have done something wrong."

Such feedback usually is not obvious. It is subtle, so you must be open to it and watching for it. There is a great tendency among product developers to believe that they are the world experts on their products (in a certain sense they are!), and this blinds them to conflicting information. They say, "The customer wouldn't possibly want to do this. I never do it." Being the expert often gets in the way of listening. "Amateur" customers don't use products in the same way that experts do.

In short, if you are going to use the powerful technique of iterating with customers to develop products that will truly appeal to them, you must also develop ways of being open to what they are telling you.

New subject: I receive many questions about flexible product development: what is it and where does it apply? A recent article, "Change: Embrace It, Don't Deny It," explaining flexibility concisely, is now available for download.

Quick Tip list | Product development publications | Home

Isn't the iteration that accompanies flexible product development wasteful?

It is true that a core ingredient of flexibility is iteration, which means starting off with a first guess at what the customer wants and improving your design as you learn more from the customer.

A concern about this, especially in today's economic climate, is that iteration inevitably becomes connected with wastefulness. Most of us learned, before we ever started to school, that haste makes waste, to "do it right the first time." Iteration essentially contradicts this by saying, "do it wrong the first time"!

Interestingly, a recent book by Mike Moran, an IBM Distinguished Engineer, entitled Do It Wrong Quickly, shows how to make progress quickly in new markets by starting fast and making changes fast - in other words, iterating. Moran works in the Web medium, which is amenable to fast change. But the do-it-wrong technique also works well in other media. For instance, Eli Lilly has applied it to the very serious business of pharmaceutical development (see "A More Rational Approach to New-Product Development" in the March 2008 issue of Harvard Business Review, pp. 96-102.

So back to the original question: the answer depends on your product development objective. If your objective is to fulfill the original product requirements as inexpensively as possible, then iteration is indeed wasteful. But if your objective is to satisfy the customer in an environment where you don't completely understand the customer or when the customer's mind might change, then iteration is the least wasteful way to go.

Quick Tip list | Product development publications | Home

Is there a development process for flexible product development?

It seems that we feel more comfortable having a process for completing things. If I have trouble with my computer, installing a video driver, for example, when I finally resolve the problem, I write myself a memo on how to do it—a process—so that I don't have to struggle with this task again.

As flexible development and its cousin, agile software development, mature, there is great temptation to turn it into an established process so that it is repeatable and predictable. Management often encourages more process (see our last Quick Tip). Unfortunately, more process often moves us toward rigidity, which is the very thing we seek to avoid with flexible or agile development.

So how can we have a process without it becoming rigid? There are several things we can do. One is to standardize only for basic activities (for instance, installing a video driver), and leave upper layers open for change. I explain this on pages 206-207 of Flexible Product Development. Another is always to realize that the process should emerge from the needs of the market, the technology being applied, and the capabilities of the development staff.

Leaving the upper layers open and letting the process emerge from the needs of the project both imply that you have some people on the team who are experienced in tailoring processes to projects, what I call Cockburn Level 3 people in Flexible Product Development (pages 129-131).

You can read more about avoiding rigid processes as flexible ones mature in our recent article.

Quick Tip list | Product development publications | Home

What drives - or should drive - our product development?

Bob Becker nicely shows how a development project can be guided by one of three approaches:

M, where MANAGEMENT primarily makes the decisions that move the project forward,
P, where an established PROCESS provides the guidance, and
T, where TEAM members are relied on to guide progress.

Every actual project employs a blend of these, but what counts is the relative emphasis of the three. As Becker describes, each of the three has its strengths and weaknesses. Thus, our opportunity is to adjust the blend to the project's needs.

Most companies start with a predominant M style, because the P and T styles aren't developed yet. As the organization matures, management becomes overloaded, and project complexity grows, they move toward a P style. This overlooks the T style. The T style requires an investment in people, training, and sometimes management coaching if the M style has been predominant, but often there is no compelling motivation to develop the T style.

The T style isn't a magic cure, but it can have strong advantages, especially for projects experiencing a great deal of change (where prescriptive P approaches don't fit and M approaches can't provide timely guidance). Chapter 6 of our book, Flexible Product Development, covers strong teams and guides you in developing them.

In short, M and P styles tend to develop of their own accord, but often the T style needs specific nurturing to evolve. Every project needs a blend, and certain projects can benefit greatly from a T emphasis. Have you developed your T strength so that you will have it when you need it?

Quick Tip list | Product development publications | Home

What do you mean by market shifts when you speak of flexibility?

When discussing product development flexibility, I assert that flexibility is important because the environment in which we develop new products is becoming more turbulent. Change is increasing in three areas: customers, markets, and technology. People generally appreciate that customers change their minds and that technology is advancing rapidly, but how are markets changing?

A good example is what is happening in China today. Recently, Chinese manufacturers were content to manufacture products from designs supplied by the West. More recently, design has shifted to China, where Chinese designers and engineers work from specifications sent from the West. But increasingly, Chinese companies are creating the product and the business from scratch, and when they do this, often they don't follow the "rules" that those in the West follow. Chinese companies like Huawei, Haier, and Lenovo are changing the markets they operate in by applying their cost advantage to areas such as engineering, marketing, and customer service that extend beyond their traditional manufacturing cost advantage. You can read about such market changes in Dragons at Your Door.

Another example of market shift is the one described in the popular book, The Innovator's Dilemma, wherein new, disruptive technologies spawn whole new markets and ways of doing business. One more is described in the book, Blue Ocean Strategy, in which an upstart disrupts a market by recombining product features in a totally new way, thus creating an uncontested market and making incumbents look obsolete.

Each of these types of market change is becoming more common and is disruptive because it changes the fundamentals of a market.

Quick Tip list | Product development publications | Home