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.

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page.  But when they can, you understand.

Unfortunately for DFA, the savings are a problem – they’re too big to be believed. That’s right, I said too big. Here’s how it goes. An engineer (usually an older one who doesn’t mind getting fired, or a young one who doesn’t know any better) brings up DFA in a meeting and says something like, “There’s this crazy guy on the web writing about DFA who says we can design out 20-50% of our material cost. That’s just what we need.” A pained silence floods the room. One of the leaders says something like, “Listen, kid, the only part you got right is calling that guy crazy. We’re the world leaders in our field. Don’t you think we would have done that already if it was possible? We struggle to take out 2-3% material cost per year. Don’t talk about 20-50% because is not possible.” DFA is down for the count.

Also unfortunate is the name – DFA. You’ve got to admit DFA doesn’t roll off the tongue like six sigma which also happens to sound like sex sigma, where DFA does not. I think we should follow the lean sigma trend and glom some letters onto DFA so it can ride the coat tails of the better known methodologies. Here are some letters that could help:

Lean DFA; DFA Lean; Six Sigma DFA; Six DFA Sigma (this one doesn’t work for me); Lean DFA Sigma

Its pedigree is also a problem – it’s not from Toyota, so it can’t be worth a damn. Maybe we should make up a story that Deming brought it to Japan because no one in the west would listen to him, and it’s the real secret behind Toyota’s success. Or, we can call it Toyota DFA. That may work.

Though there is some truth to the previous paragraphs, the main reason no one is doing DFA is simple:

No one is asking the design community to do DFA.

Here is the rationalization: The design community is busy and behind schedule (late product launches). If we bother them with DFA, they may rebel and the product will never launch. If we leave them alone and cross our fingers, maybe things will be all right. That is a decision made in fear, which, by definition, is a mistake.

The design community needs greatness thrust upon them. It’s the only way.

Just as the manufacturing community was given no choice about doing six sigma and lean, so should the design community be given no choice about doing DFA.

No way around it, the first DFA effort is a leap of faith. The only way to get it off the ground is for a leader in the organization to stand up and say “I want to do DFA.” and then rally the troops to make it happen.

I urge you to think about DFA in the same light as six sigma or lean: If your company had a lean or six sigma project that would save you 20-50% on your product cost, would you do it? I think so.

Who in your organization is going to stand up and make it happen?

A customer walks up to your product, turns it on, and it works without breaking or getting in its own way.

Bad product robustness is bad for your brand. Very bad. Customers do not like when they pay money for a product and it doesn’t work, especially when they rely on those products to make money for themselves. And they remember the experience in a visceral way.

You can’t fix bad product robustness with great marketing; you can’t fix it with spin selling; you can’t tell customers you fixed it when you didn’t (since they use your product, they know the truth); and you can’t hide it because customers talk (so do competitors). There is no quick fix – it takes tools, time, training, and new thinking to improve product robustness. And when you do manage to fix it, customers won’t believe you until the see it for themselves. They don’t want to get burned again.

No product is infinitely robust, nor should it be. It doesn’t make financial sense. The product would be infinitely expensive and would take an infinite amount time to develop. But how much robustness is enough? An easier, and possibly more important, question to answer is – how much is too little? Or, stated another way, what is the minimum level of product robustness?

The specialists won’t agree with my assertion that there is a minimum threshold for product robustness, but I don’t care. I think there is one. I call this minimum value the brand-damaging threshold. Here’s an operational definition of product robustness that’s below the brand-damaging threshold:

Customers don’t buy your product because they know it breaks or gets in its own way and they go out of their way to tell others about it.

It is difficult to know when customers don’t buy, never mind know why they don’t. But there are some tell-tale signs that product robustness is below the brand-damaging threshold. Here are a few.

The CEO takes enough direct calls about products that don’t work to feel obligated to send you a thoughtfully-crafted, four word email saying something like “Fix that @#&% thing!” Customers have to be really pissed off to call the CEO directly, so the situation is bad. It’s also bad for a reason that’s closer to home – the CEO sent the email to you.

You get a little sick to your stomach when sales increase. You know you should be happy, but you’re not. Deep down you know you’ll see many of those products again because they’ll be sent back by angry customers, in pieces.

The volume of returns is so significant you create a refurbishment department. Or you create a new group to scavenge the reusable stuff off the piles of returned product. Not good signs.

Your product’s lack of robustness is the headline message in your customers’ marketing literature.

Now that the brand-damaging threshold is defined, the next logical topic is how to improve product robustness so it’s above the threshold. But that’s for another post.

In a previous post on innovation, I talked about the tight linkage between problems and innovation.  In the pre-innovation state there is a problem; in the post-innovation state there is no problem.  The work in the middle is a good description of the thing we call innovation.  It could also be called problem solving.

Behind every successful product launch is a collection of solved problems.  The engineering team defines the problems, understands the physics, changed the design, and makes problems go away.  Behind every unsuccessful product launch is at least one unsolved problem.  These unsolved problems disrupt product launches – limiting product function, delaying launches, and cancelling others altogether.  All this can be caused by a single unsolved problem.

The best engineering teams can solve the toughest problems, and the worst ones, well, you know about those.  So, what level of problems can your engineering teams solve?  That’s a difficult question to answer.  What truly matters in the trenches is how the problems of the day stack up against the engineering teams’ capabilities.  And you must not kid yourselves and overestimate your teams’ capabilities.  You have to solve problems with the engineering teams you have, not the engineering teams you want.  Don’t get them in over their heads.  They’ll drown and then so will you.

It takes a good eye to tell when engineering teams are in over their heads – when the problems are too big for their capabilities.  Here are some signs of trouble.

The project team cancels the review meeting.  There is nothing worse that cancelling a review meeting, except being called out at a review meeting for not knowing what the hell is going on.  This is the proverbial dog-at-my-homework scenario – the stranger the reason for cancellation, the bigger the problem.  It’s actually a good sign if the project manager sends out a message saying “We have a big %$#@! problem and we’re cancelling the @*&$#! meeting.”  A confident project manager will send out a message like that.  A scared one won’t.

The project team holds the review meeting, but it’s long, highly technical with complex arguments.  The length and technical content is intentional.  It’s a technique used to distract, to hide behind complexity.  If the review meeting is an endless barrage of formulas, complex graphs, and 3D plots, watch out.  They’re trying to hide something.

The project is behind schedule and the team holds a review meeting.  During the meeting no one uses the words “I don’t know”.  Remember, a confident team will say “I don’t know”.  Here are some phrases to watch out for: “After a review of the literature we believe it could be…”, “We’re running analyses on some new software….”, “I bet my career that it will work.”

At the review meeting a junior engineer is given an “opportunity” to present the key results (the problem).  All the senior engineers know better than to stand up and read slides like those.  And, the project team knows you’ll go easier on the junior engineer because you know she is not responsible for the problem.

Senior engineers slowly and quietly migrate to another project.  No one is quite sure why.

Engineers volunteer for sustaining engineering work (crap work) just to get off the project.

The project team refuses to accept help even when offered the best engineering talent.  This circling-the-wagons technique is intended to keep the real problem within the team.

There is hope.  There are things that can be done to improve the situation.  First, company leaders must recognize the importance of problems and decide they want to solve problems better.  That’s the hardest part.  Now, on to the easier stuff – creating a problem solving process. 

There are several aspects of a good problem solving process.  Most processes underwhelm the problem definition work.  Yours should not.  It’s easy for your doctor to make your problem go away once the diagnosis is made.   Nick Siler sent me this quote by Larry Burns, outgoing Chief of R&D at General Motors, who is credited with GM’s massive leap forward in the area of fuel cell hybrid powertrains and vehicle communications:

…focus as hard on defining the questions as you do on trying to answer them. I have found that once you really understand the question, you are 90 percent of the way home. In addition, you need to recognize that in the real world, the questions are often ill-defined, data are often messy and methods frequently do not apply exactly as they have been taught. You will need to learn to deal with this ambiguity. Finally, great opportunities lie at the interface between disciplines, so be sure to take a systems approach in your work.

To paraphrase the Mr. Burns – there is nothing worse than solving the wrong problem. 

The problem process should require the team to define the underlying physics, the fundamentals of the problem.  No kidding, the team should be able to make the problem come and go at will.  This is hard work and feels too slow, but it’s actually faster.

The process must drive out complexity, complexity created by technical language and long presentations.  The problem must be defined on one page.  Not two pages, one page.  Technical language is replaced by symbolic language of blocks and arrows.  Each block represents part of the system and is labeled with a simple noun.  Each arrow represents an action and is labeled with a simple verb.  Together, the blocks and arrows define the problem in an unambiguous way.

Lastly, the process should be reinforced at every opportunity, especially project review meetings.  The engineering teams must be held accountable for following the process.

To close this one  out, we all have problems; they are real.  But that’s okay.  We should learn to embrace them, rally around them, define them, and get rid of them.

CEOs have a strong desire to do what it takes to deliver shareholder value, but that’s coupled with a deep concern that tough decisions may dismantle the company in the process.

Here is the state-of-affairs:

Sales are down and money is tight.  There is severe pressure to cut costs including those that are linked to sales – marketing budgets, sales budgets, travel – and things that directly impact customers – technical service, product manuals, translations, and warranty.

Pricing pressure is staggering.  Customers are exerting their buying power – since so few are buying they want to name their price (and can).  Suppliers, especially the big ones, are using their muscle to raise prices.

Capacity utilization is ultra-low, so the bounce-back of new equipment sales is a long way off.

Everyone wants to expand into new markets to increase sales, but this is a particularly daunting task with competitors hunkering down to retain market share, cuts in sales and marketing budgets, and hobbled product development engines.

There is a desire to improve factory efficiency to cut costs (rather than to increase throughput like in 2008), but no one wants to spend money to make money – payback must be measured in milliseconds.

So what’s a CEO to do? 

Focus on product.  Selling into new markets requires new products; even with full marketing and sales budgets, new products are required.  But, hobbled product development engines aren’t going to get it done – they can’t even do what they used to, never mind do more with high levels of innovation.  Here are some steps that can get things on track.

First, some investment must be made to understand the new markets.  They’re called new markets because they’re new – previous experience is not valid and new experience must be created.  So get some experience by watching customers use the leading products and talking directly with them about what they like and what they don’t.  A list of new functions and features is the desired outcome, along with a sale price and target cost.

The new features, functions, and cost target are the input to the product development engine.  The existing product with the strongest overlap with the new features and functions is used as the platform for the new design.  To make a splash, functionality and cost must be improved at the same time (remember, customers are naming their price).  Hopefully the engineering team has the chops to do the new work.  If not, some investment must be made to bolster their capability in the new areas.  Don’t skimp here or the new product will come out wrong (if at all) falling short of functionality and cost goals.

There is another deliverable from the product development engine.  The engine must create A/B performance data from which data-driven sales tools are created.  The best product in the new market is chosen as the baseline product (A) and tested to define the performance specification (maybe 20% better than the baseline product).  The new product (B) is tested under the same test protocol and its performance is plotted relative to the performance specification (20% better than the baseline product [product A]).  If the product development engine does its job, the new produce will have a competitive advantage over the best product in the market, with more function and less cost.

Some investment is needed to develop (and translate?) the data-driven sales tools and some spending is needed to get the sales force (and their new tools) in front of customers.  Don’t forget the sales tracking systems.

Improving the product development engine is vital.  Designing higher functioning products with low cost signatures is not natural for engineers, so care must be taken when defining the challenge.  And the morale of the engineering teams is likely low due to the recent cost cutting.  They may not be in the right frame of mind to accept their challenge, so a thoughtful delivery makes a difference.  A modest training plan to develop their capability goes a long way to putting them in the right frame of mind.

There is no free lunch here, and little new thinking.  Solid blocking-and-tackling is needed from marketing, sales, engineering, and manufacturing along with improved capability in engineering.  Even in a recession, this approach can grow sales in new markets, especially when coupled with strong focus.

Next time you see your CEO, give a smile, a hand shake, and a thank you.