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.