The front end of innovation (FEI), where researchers explore innovative new product concepts, is crucial to feeding a company’s entire product development effort with profitable new opportunities. Yet despite its importance, researchers working in the FEI often encounter situations where their effort is wasted. Contrary to common wisdom, the waste is caused by the same processes (such as Stage-Gate(r)) that reduce waste later in the product development.
In a recent paper published in Food Technology, Dr. Carla Kuesten and I look at typical examples of waste in consumer product research and explain an exploratory process designed to avoid such waste. In stark contrast to sequential processes, the exploratory process is based on loose planning, iterations and loop-backs. Although the paper deals specifically with examples from consumer products, the ideas can be applied to any discipline.

An exploratory Process
Sequential development processes seek to eliminate waste by thoroughly planning a project before spending serious money on it. That may work when the project doesn’t involve innovation, but it creates waste in the FEI because researchers can’t anticipate where they will make critical discoveries. A critical discovery in a later stage will force researchers to re-do previous work and delay the schedule.
Rather than carefully planning the research project in sequential stages, an exploratory process works in short iterations, intentionally looping back through activities. At each iteration, researchers adapt to previous discoveries, speculate about remaining uncertainties, and plan the next iteration to reduce the most critical ones. The process closes in one of two ways: by launching a development project if no major uncertainties remain, or by abandoning the project if the value hypothesis becomes untenable.
As an example, a team researching a formulation for a functional snack product (one that keeps you feeling full longer) set a 3-hour satiety goal early in the project. They invested significant effort to reach that goal, only to find that three hours of satiety was incompatible with a superior sensory experienc
The waste was caused by prematurely specifying the 3-hour satiety goal. An iterative process with a broader goal of “good taste with superior satiety” would have allowed the team to iterate through different taste/satiety combinations to arrive more quickly at a successful formulation.e (taste and texture). In the end, they discovered that only two hours of satiety would be competitive as long as the product tasted good.
Are “best” planning practices keeping you in the slow lane?
Thursday, December 29th, 2011Agile product development— already proven for software products— promises significant advantages for fast delivery of innovative products, but hardware developers have been slow to adopt agile principles. In a recent article in
PDMA’s Visions magazine, I explain that managers and developers may be clinging to outdated beliefs about project planning and development waste.
Agile software practices can’t be translated verbatim into hardware product development, but two schools of thought—Flexible Product Development and Lean Product Development—offer ways to adapt agile principles to hardware development.
Agile hardware development calls for a new planning approach, one that conflicts with traditional beliefs about “best practices,” frozen plans and the cost of change. These beliefs can be so deeply ingrained that companies are reluctant to adopt more agile practices.
Back in the day, markets were stable and incremental innovation was enough to get by, so freezing plans before starting development seemed like a good way to eliminate product development waste. But for rapid innovation in emerging markets, rigid, frozen plans can create waste, rather than eliminating it.
For example, a team developing a product for a new application environment may freeze the plan around a certain type of enclosure, only to discover late in the project that the enclosure they chose is not acceptable in the new environment. At that point, the team must delay the schedule to design a new enclosure and rework other parts of the design to fit.
Freezing the enclosure decision too soon actually created waste in this situation, because not enough was known about the new application. A more agile approach would have been to postpone the enclosure decision until better information was available, keeping design options open to prevent rework when the enclosure decision was finalized.
Both Flexible and Lean product development practices are based on keeping some decisions open until better or more current information is available. The idea that making decisions too soon creates waste is such a departure from traditional planning practices that organizations must learn to question “best practices” before they can adopt more agile development methods.
For more details and some references about agile hardware development, take a look at the full article.
Posted in Commentary, Execution, Governance | Comments Closed