How To Fix Product Development
November 16th, 2011
The new product development process creates more value than any other process. And because of this it’s a logical target for improvement. But it’s also the most complicated business process. No other process cuts across an organization like new product development. Improvement is difficult.
The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together. Don’t know the problem. Stepping back, who will lead the charge? Whose problem is it?
The goal of all projects is to solve problems. And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem. And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products. Yikes.
Problems are informed by outcomes. Make a short list of desired outcomes and show the CEO. Your list won’t be right, but it will facilitate a meaningful discussion. Listen to the input, go back and refine the list, and meet again with the CEO. There will be immense pressure to start the improvement work, but resist. Any improvement work done now will be wrong and will create momentum in the wrong direction. Don’t move until outcomes are defined.
With outcomes in hand, get the band back together. You know who they are. You’ve worked with them over the years. They’re influential and seasoned. You trust them and so does the organization. In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.) If they’re the right folks, they’ll say they don’t know. Then, they’ll craft the work to figure it out – to collect and analyze the data. (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist. Any work done now will be wrong. Don’t move until problems are defined.
With outcomes and problems in hand, meet with the CEO. Listen. If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO. Review outcomes and problems. Listen. If there’s agreement, it’s time to put a plan together. If there’s disagreement, stop. Don’t move until there’s agreement. This is where it gets sticky. It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge. No words of wisdom on than – don’t move until outcomes and problems are defined.
There’s a lot of emotion around the product development process. We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument. Analyze your process and define outcomes and problems. The result will be a well informed improvement plan and alignment across the company.
Posted in CEO, Constraints, Fear, How To, Product Development, Seeing Things As They Are, Top Line Growth | 
Tags: Product Development Engine, Trust-based approach
5 Responses to “How To Fix Product Development”
Leave a Reply
Mike Shipulski
I propose to use experience from previous product developments. Identify and document problems encountered such as:
– Inadequate functionality according to customer surveys
– Development schedule delays
– Development cycle too long
– Too many engineering changes during production/ pre-production
– Development cost over budget
– Product cost above target, etc.
From this data, the top Management Team could identify what is the first improvement priority and define a Six Sigma project with a very specific target.
“The first part of problem definition is problem definition.”. Well said.
I fully agree…and live with these frustrations on a daily basis. My history is in manufacturing operations. Conversely, my current position has me working and living with Current and New Product engineering for the past couple of years. I have now seen the world of product development from all sides and the dysfunction is enormous, ingrained and emotional. There have been efforts in the past to “improve” the process, but significant results have been short lived or stove-piped to a particular function. The situation is frustrating as I am fully aware of opportunities for improvement on all sides. Yet sadly, everyone points the finger and blames the other group (e.g. the design sucks, mfrg engineers have no clue, the plants cost too much, etc, etc.). It is akin to a split screen of a married couple complaining about their spouse to a group of their friends….and they are both saying the exact same thing. The problem with previous improvement attempts is that the issue of “problem definition” was never nailed down. Agreement on goals (TTM improvement, cross-functional team creation, etc.) is easy. But true agreement on “how” and “what” to change is the hard parts and never seems to be effectively addressed. Again, I fully agree with the article. But am afraid that if “Don’t move until there’s agreement”, we may never move again!
I think the problem is that it’s not really a problem. It’s parts. Some power and responsibility and doings over here. Some other there. A bunch up there. All eventually clunking the diverse parts together, without a clutch, and the gears grind. One approach to the situation, not a problem, is solutions focused (or Toyota’s kata). Go look and see. No desktop expert problem pounding. Make things a bit better by forming a kind of community with tacit learning here. Add more improvements on the improvement kernel. Start another improving kernel of community working together. Step by step with lots of tacit learning – people have to be in the same room, learning habits by doing, instead of throwing things over the wall. People working in the improving kernels can start forming maps of ‘could be’, akin to scenarios. Generate Nonaka’s Ba, edge past the fiefdoms, and grow solutions. Problems are blackholes, so leave them in the fiefdoms, and grow around them.
As you said, the process is complicated so the real question is what is really broken with the process? The organization has to have expectations or vision for what the process should be doing and then look at where it is falling short. My guess, based on 30+ years of developing products, is that two main issues will rise to the top: cycle time and cost (i.e., it takes too long and costs too much to develop new products).
There may be many reasons or root causes for these and that really needs to be the focus of the improvement effort. Development time and cost are the results (aka symptoms) of other aspects of the process, such as defining and freezing product requirements. Once the organization determines what those root causes are and then addresses them, real improvement can occur.