Hard-pressed to improve competitiveness, managers often implore us to “do it right the first time.” Although this objective is laudable, it reveals that the manager pronouncing it does not understand the fundamentals of product innovation. Worse, it sets the organization up for surprises later.
An essential characteristic of innovation – and thus of product development – is that we don’t have all of the information we need when we start. We can’t even obtain this information in an orderly way, because, no matter how diligent we are in arranging activities sequentially, some of the information we need now will not be available until later.
Recall your high school algebra. We all learned how to solve systems of equations such as the following ones for the unknowns x, y, and z:
4x + 2y – 48z = -14
15x – 6y + 2z = 41
8x + 3y + 5z = 81
There are various straightforward ways to unravel these equations to obtain x, y, and z from them sequentially. Product development is like this: we have a few relationships (the equations here), and we would like to solve for the unknowns, hopefully using a sequential process.
Now recall how many times since you entered industry that you have actually set up a problem in this way and solved it as you learned in high school. Never? That’s right! It’s right because real problems in innovation are not this simple. The equations aren’t so simple, and many product development relationships cannot even be expressed with a device as clear as an equation.
But the basic issue remains in innovation: we have many relationships and we must unravel them to discover the unknowns. Unfortunately, there are usually no straightforward, sequential ways to do the unraveling. This means that we have to guess at one of the unknowns, work through the others, and then loop back to see how close we came to our original guess. We keep guessing until we get through the loop with our original assumption holding up pretty well. Consequently, in innovation, we cannot do it right the first time.
Unfortunately, virtually all of the tools we have for managing innovation deny this essential characteristic of the process. We employ stages-and-gates processes that deny the reality of looping. We depend on project management’s Gantt charts, network diagrams, or critical chain methods, which disallow looping.
Of course looping complicates innovation, because it makes it messy and essentially unpredictable. However, the worst consequence of looping isn’t the unpredictability it causes. The bigger problem for management is the denial of its existence. When we really believe in do-it-right-the-first-time and then the looping inevitably occurs, it catches us by surprise. This is regrettable, because the looping could have been anticipated and planned into the process.
Fortunately, there are some management tools – relatively obscure ones today – that allow us to identify looping patterns, anticipate the guesses that will be needed and will have to be revisited, and then revise our development process so that reviews naturally come at the end of the loops. These tools generally go by the name of Design Structure Matrix. You might benefit from checking them out – if you would like to know where your next loop is going to occur: https://web.mit.edu/dsm/.
Most of us have been bred from an early age to relish success. Our parents enrolled us in Little League, piano lessons, and college so that we would succeed. Now, as adults, the thought of failure is repulsive, even though our managers pay lip service to risk taking and the likely failure that it entails. In fact, in many cases, our CEOs are the presidents of our local Success Clubs. After all, they probably got where they are due to a long string of successes.
When it comes to developing products, there is a problem with success — we don’t learn much from it. When we dissect product development, which we also call innovation, we find that it is simply a series of trials that can either fail or succeed. These trials go by various names: experiments, analyses, sketches, prototypes, and tests. In other words, we try something out and see if it works. Based on the outcome of the trial, we try something else.
Progress occurs when we learn from the trial. To make faster or more effective progress in product development, we need to arrange our trials so that we learn from them faster or better. The interesting thing about trials is that we learn the most when we cannot anticipate the outcome. If we arrange an experiment so that we expect it to succeed and it does succeed, we haven’t learned anything. Similarly, if we expect failure and the outcome is failure, there is no learning. We learn the most when we don’t know beforehand what the outcome will be (see figure).
“Optimal” product development is a sequence of carefully arranged trials in which the outcome of each trial is uncertain beforehand. But we can dig deeper and do even better than this. For example, sometimes success and failure behave quite differently for the various objectives of product development, such as cost, time, etc. As a result, it is better to bias our sequence of trials to take advantage of this behavior.
Consider a common case in which success is simply the lack of a failure. To determine success, we have to prove beyond a reasonable doubt that our item won’t fail. This can take a long time, so it may be much faster and cheaper to run our trials biased toward failure. We run quick failure tests and inch up toward the success threshold, rather than running long tests on the success side.
These strategies depend very much on the nature of the trials. In some cases, failure is cheap and fast, and then the approach just described makes for rapid progress. But other trials are very different. If you are flight-testing helicopters, you probably want to bias your trials toward success.
We could take this further, but there are two basic take-ways:
Two loggers headed into the woods. From one you could hear a chop-chop-chop continuously all day. From the other, it was more of a chop-chop-pause, chop-chop-pause rhythm. At the end of the day the corporate metrics team went into the forest to collect their numbers and, to their amazement, found that the second logger had felled twice as many trees as the first one. Why? He took time periodically to sharpen his axe.
Did you have a New Year’s resolution to “sharpen your axe” relative to how you were going to develop your new products in 2001? How is your resolution faring so far this year? Lost in the rat race?
Of the articles available for download on our Website, one of the three most popular ones relates to axe-sharpening: “Your Product Development Process Demands Ongoing Improvement” . From its popularity, I conclude that there is no lack of interest in the principle of ongoing improvement. The problem – just as with other New Year’s resolutions – is in the implementation.
I believe that there are two reasons why our well-intentioned resolutions don’t quite happen. The first is that we don’t budget for them. Say that you want to reduce delays and improve decision quality of your development team that is dispersed in New England, France, and Thailand. You need time to understand just where the time is going and where the roots of the poor decisions are. You will need more time to implement fixes and train people once you understand the root issues.
Where will this time come from (given that you are already badly overloaded)? The answer is really quite simple. It will have to come out of effort you are putting into developing new products. Yes, this means that you will not develop quite as many products this year as you do this initial “sharpening.” This is the crux of the matter. I liken it to paying taxes. None of us likes taxes, but if we don’t pay our taxes now, we will pay dearly in the future for poorly educated children; bumpy, congested roads, and pollution. This is why taxes don’t come out of discretionary income.
If you are ever to improve your development process so that you do not keep suffering the same difficulties, you will have to make your “taxes” mandatory, coming right off of the top of your resources.
This brings us to the second point – and to a breakdown in the tax metaphor. The beauty of development process improvement is that you can decide just how much tax you want to pay. You can pay no tax, but we have just considered that option. Conversely, the mistake that most of us make is to initially tax ourselves too heavily. Then, when the tax becomes too onerous, we quit altogether. This is just what happens to most New Year’s resolutions about this time of year. They were too ambitious to be sustainable by ordinary mortals.
The trick is to pick a (non-zero) tax level that you can sustain, and then commit yourself to maintaining it right off of the top of your resources. In business terms, think of it as an investment in future competitive strength. You are building a corporate asset that has value. In fact, every development project contains the raw material (bits of learning) needed to improve your process. You must decide what portion of your corporate resources you will devote to mining and polishing these gems before they slip away.
Whether you are the CEO or a lowly designer, this is a perfect point in the year to reassess any resolutions you made to improve product development this year. Do you have plans? Are they being followed? Do they depend on individuals over whom you have limited control? Do your plans need to be scaled back to be sustainable? Does the whole program need to be restarted?
Once you have a sustainable plan, the article mentioned in the third paragraph above may help you, as may ” Learning from Your Development Projects,” which appeared in the September 1997 issue of this newsletter.
(c) Copyright 2013 Preston G. Smith. All Rights Reserved.
