Preston Smith's Corner

Quick Tips

Preston Smith Quick Tips

June 2002 Quick Tip

Our emphasis over the years has been on reducing product development cycle time (time to market). Many companies have worked vigorously on time to market and have gotten better at it; for example, many have cut their cycle times in half.

However, managers in these companies are still not pleased with their time to market performance. Some of them are striving to reduce cycle time even more in order to meet or beat the competition; there can be great value in this.

Other managers are recognizing that — in their environment — raw cycle time is not the issue. What hurts them more is variation in cycle time. When they start a project, they know from their history how long it will take, on average, but they also know that they are plagued with substantial variation from this average. In many cases, for example, for seasonal products or ones launched at trade shows, it is this unpredictability that is the killer in their development schedules.

This is precisely where project risk management helps. Its objective is to reduce the uncertainty in the outcome of your project. You can use it to control schedule uncertainty — the variation in time to market for a particular project, as discussed above. You can also apply it to reduce variation in development expense, cost of goods sold, or product performance or quality.

For details, see the article “The Risk in Time to Market.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

June 2001 Quick Tip

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.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2007 Quick Tip

You may have noticed several recent Quick Tip messages on flexibility, which is because I am writing a book on flexible development, to be released by Jossey-Bass in September of this year. Each Quick Tip has been a mini-summary of one chapter. There are two more to go, but let’s take a break and consider, in general, how one enhances flexibility.

Flexibility is the ability to react to change effectively during development.

One technique is anticipation. This is different from forecasting. Rather than trying to predict the future, anticipation is being sensitive to trends, patterns, and things that seem unusual, which are the harbingers of change. Then, when change happens, you are waiting for it.

Another is responsiveness, so that the organization can act quickly when change occurs. Beyond the mindset needed that change is often beneficial, this requires that people and systems are not overloaded so that queues are short to provide quick reaction.

Skill in delaying decisions (see an earlier Quick Tip “How can I develop products more flexibly by changing our decision making?“), while simultaneously collecting information to make a better decision when its last responsible moment arrives, is critical for enhancing flexibility.

In general, the approach is to keep the cost of change low for as long as possible and to recognize areas that have high costs of change so that change can be avoided in them. This implies actively building and maintaining options.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

April 2002 Quick Tip

As we interact with managers about our forthcoming book, Proactive Risk Management, we receive questions about the apparently methodical process of risk management, especially in contrast with the tools covered in our established book, Developing Products in Half the Time. Some managers are comforted that we are offering a more definite process, while others are concerned that a formula is too mechanistic. I believe that both groups are correct, and I hope that we have provided an appropriate balance.

There is a definite process underlying project risk management, and all effective practitioners of whom I am aware follow variations of it. We provide a core process and encourage readers to adapt the process to their organization’s needs and culture, as well as its markets and technologies.

However, there is much more to successful implementation than the process, just as there is much more to effective product development than its process. Our new book provides a chapter devoted to implementation issues, such as integrating risk management into project management and team structures, training, executive involvement, dealing with counterproductive firefighting and “kill the messenger” behaviors, and continuous improvement. Another chapter addresses risk management strategies and approaches, including addressing the risky items first, viewing failure advantageously, and customer involvement. Without an understanding of these topics, the corporate immune system will reject any new process.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2007 Quick Tip

A recent research report “Managing the Future: CEO Attention and Innovation Outcomes” finds that “forward-thinking CEOs are the main drivers of successful innovation” in their companies. So, specifically, how do CEOs figure in flexible development? One key ingredient of adopting flexibility is the significant changes in organizational values and behavior required. Thus, the question becomes: is the CEO a key factor in organizational change?

When writing my forthcoming book, Flexible Product Development, several months ago, I polled 35 product development experts regarding their experiences with organizational change. The one consistent response was that the CEO had to lead the transition for it to be successful. While desirable, this creates two problems. First, the person wishing to initiate change is unlikely to be the CEO, and second, my discussions with CEOs clarify for me that they, working alone, lack the time, connections, credibility, and skills needed to implement change. As Mary Lynn Manns and Linda Rising explain, “It is not top-down or bottom-up, but participative at all levels.”

Consequently, I created a multifaceted approach to organizational change. It includes the top-down approach of John Kotter as a framework, the bottom-up tools of Manns and Rising to execute the details, and the transitions perspective of William Bridges to knit the pieces together effectively. See the bottom of our Resources page for more on their books.

Better yet, order Flexible Product Development and read Chapter 10.

In short, the CEO must be on board (eventually), but don’t depend on this executive to lead the effort.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

pril 2008 Quick Tip

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 “What drives – or should drive – our product development?“). 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 “Remember: Agility is Lack of Rigidity.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2001 Quick Tip

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 “Cherishing Failure.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

June 2008 Quick Tip

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.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

October 2004 Quick Tip

As counterintuitive as it seems, this may be a faster way to market, and it may result in a better or cheaper product or in labor savings also.

Product development is essentially a chain of decisions, and we make decisions based on currently available information. The longer we wait, the better this information can be, so the better our decision might be.

The wisest decision makers explicitly think about the information needed to make a good decision, and they proceed proactively to obtain this information before they have to decide.

Often, the decision is a choice between two alternatives. In this case, you can defer the choice by keeping both options alive and developing them further, what we call parallel development. This is essentially a matter of developing more information to make a better decision.

However, this strategy can clearly delay progress too. If you are going to use it, you must understand your project’s critical path and how it relates to your decision, and you must decide before the decision falls on the critical path. You should also know the cost of obtaining the additional information relative to the benefit of delaying the decision.

Most importantly, this is not an excuse to procrastinate. Even before you reach the point of procrastination, you should recognize that if you delay too many decisions, you will be juggling too many balls, and your cumulative project risk will rise.

For more on this subject, see Chapter 3, “Decide as Late as Possible” in Poppendieck’s book, Lean Software Development

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2003 Quick Tip

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 (Product Development – Faster, On-time), 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. See a Quick Tip on this topic “We call ourselves a team, but we don’t act like one. What can we do?” provides the details.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

December 1999 Quick Tip

A few years ago, managers were concerned about having their design engineers visiting customers. They feared that either the engineers would be too honest, ruining a sale, or they would over-generalize from the few visits they were able to make. Nowadays, these concerns have abated, so the remaining concern is simply: Can I afford to pull a busy engineer off design work to visit a customer?

In fact, your design engineers are your front-line troops, making the countless daily decisions that will accumulate to determine whether or not your product is customer-friendly. Without having “walked in the customers’ shoes,” these decisions are likely to be made both poorly and slowly.

Consider an airline, where the flight captain is making these front-line decisions. Most captains, who are isolated from their customers by a bulkhead, will announce at the beginning of a flight when it will touch down. But customers don’t care about touchdown; they only care about when the plane gets to the gate so they can leave. The captains who pay more attention to what their navigation computers are telling them than about the customers behind the bulkhead will announce the impertinent information every time.

Even a company as admired as Hewlett-Packard and a product line as successful as their DeskJet printers has had problems with unfriendly products. HP has implemented a program of customer visits, including training for their engineers, to make their DeskJets more customer-friendly.

Remember that there are two keys to effective customer contact:
– Design engineers must be in DIRECT contact with customers.
– This contact must occur before they start designing.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

September 2001 Quick Tip

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 suggest 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. See our article about focusing on profit for more on project objectives. Also, see the additional information on the pros and cons of gated processes.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2005 Quick Tip

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).

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

October 2002 Quick Tip

You are not alone. “Team” is a much-abused word. Take the so-called customer service team at your local telephone company, for instance. These hundreds of people probably work in different locations, and few of them know each other. Their objective is to close a customer request by themselves — without involving anyone else on the “team,” if possible.

Product development projects can benefit from a far stronger form of team, but it takes considerable work to set up and maintain such a team. In some cases, the effort required outweighs the benefit obtained, especially in some corporate cultures and management environments.

Katzenbach and Smith (no relationship) in their recent book, “The Discipline of Teams,” suggest that in many cases a single-leader discipline is good enough and much easier to apply than a team discipline. They are careful to pick the type of organization (discipline in their terminology) that fits the project’s needs, rather than automatically assuming that a team is best.

Each of your product development projects has different objectives, and each will operate in a different managerial environment. Rather than always assuming that a team is best and then often being disappointed with the results, consider explicitly picking a form that suits your needs and resources for that project.

For more on team versus single-leader disciplines, see our book review.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

April 2000 Quick Tip

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 “Managing Risk as Product Development Cycles Shrink.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

September 2002 Quick Tip

This rather negative viewpoint is actually an effective one for quickly appreciating what you must do to manage the risks in your projects effectively. Here are a couple of things you should be careful to avoid as you implement a project risk management program:

Turn risk management over to your engineers In a typical product development project, perhaps three fourths of the labor comes from engineers or other technical professionals, such as chemists. Thus, it would seem logical to turn risk management over to your engineers. Engineers already have means of managing technical risk, called failure mode and effect analysis (FMEA). Unfortunately, about 90 percent of project risks are non-technical, so if you assign risk management to your technical staff, you will miss about 90 percent of your risks. Instead, make sure risk management is executed cross-functionally.

Allow risk to become subservient to budget and schedule If you attend a team or review meeting in an organization that is serious about project risk management, you will hear more about risks than about schedule or budget items. Of course, in most organizations, it is the reverse: all concerns focus on schedule and budget, and risk is hardly mentioned. This is a reactive style of management. Instead, effective risk management is proactive; it recognizes that today’s risks become tomorrow’s budget and schedule problems.

For more of these risk management tips, see our article, “Thirteen Ways to Mismanage Development Project Risk.”

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

July 2005 Quick Tip

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?

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

April 1999 Quick Tip

In the last Quick Tip we described the waste associated with splitting a person between product development projects. This time we promised you help in achieving dedicated staffing.

Starting with the difficulties arising from not dedicating people, concentrate on your next opportunity to dedicate a developer. Many companies are now dedicating their design engineers. If so for you, then where is your next project role that could benefit from full-time attention? A manufacturing engineer? Marketing? A tester?

Clarify your concern about not dedicating this individual. A common concern is that you just can’t spare the person. But maybe you could do it just once on an especially critical project.

Maybe you fear that the person won’t be kept busy. Here the trick is to expect this person to operate as a generalist when needed. Also recognize that some of the value of dedication is in allowing the individual to occasionally have a break so that she looks ahead to anticipate problems, rather than always reacting.

Perhaps your people seem too specialized or highly paid to dedicate to just one project. My response is that the benefits in efficiency and accountability are so great as to probably overcome these disadvantages.

To get started, think of doing this once as an experiment. Pick the person who is most able to succeed, both in being a generalist and in working proactively in critical areas whenever he would otherwise be idle. Because this is an experiment, record the results — metrics of what you can measure and anecdotes for softer observations. Then decide what you learned and how you want to extend the concept and institutionalize it.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

March 2004 Quick Tip

The wish of every product designer is to start a development project with a complete set of product specifications and avoid specification changes during design. This makes life easier and more predictable.

Unfortunately, “frozen” specifications are mostly a dream perpetuated by consultants and educators. They don’t fit with realty. Colleague Don Reinertsen has surveyed hundreds of product designers from all industries over several years. He found that fewer than five percent of them had complete specifications before they started designing, and in no case did the specification remain stable throughout design!

Furthermore, Harvard Business School professor Alan MacCormack’s research shows that the most successful projects commercially were those that started with only a rough idea of the product but built prototypes and obtained customer feedback early in the project.

Together, Reinertsen and MacCormack suggest that frozen specs are neither realistic nor wise, and others are also reaching this conclusion.

Does this sound like chaos? Well, this is the way the world is headed, so rather than fighting it, you might be wise to build a development system that tolerates change and chaos well – that is, an agile process.

There are several things you can do to improve your agility:

  • Employ modular architectures to isolate changes
  • Make decisions progressively rather than massively
  • Exploit flexible technologies, such as rapid manufacturing and programmable logic devices
  • Arrange to make certain critical decisions late in the process

To learn more, see our column on frozen specifications,  read the article by Thomke and Reinertsen in the Fall 1998 California Management Review, or consult the extensive agile software development literature.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

January 2008 Quick Tip

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.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.

Learn about our other services

For more information, contact:

Mary Drotar, Partner

Strategy 2 Market, Inc.


or complete this contact form

Note: As this is an archive of Preston’s New Products Dynamics Website, some off-site links may no longer exist.

Scroll to Top