How do we create the Improvement Mindset, where the desire to make things better is a way of life? The traditional non-answer goes something like this: “Well, you know, a lot of diverse factors have to come together in a holistic way to make it happen.  It takes everyone pulling in the same direction.” Crap. If I had to pick the secret ingredient that truly makes a difference it’s this:

a

People with the courage to see things as they are.

a

People who can hold up the mirror and see warts as warts and problems as problems – they’re the secret ingredient. No warts, no improvement. No problems, no improvement. And I’m not talking about calling out the benign problems. I’m talking about the deepest, darkest, most fundamental problems, problems some even see as strengths, core competencies, or even as competitive advantage. Problems so fundamental, and so wrong, most don’t see them, or dare see them.

The best-of-the-best can even acknowledge warts they themselves created. Big medicine. It’s easy to see warts or problems in others’ work, but it takes level 5 courage to call out the ugliness you created. Nothing is off limits with these folks, nothing left on the table. Wide open, no-holds-barred, full frontal assault on the biggest, baddest crap your company has to offer. It’s hard to do. Like telling a mother her baby is ugly – it’s one thing to think the baby is ugly, but it’s another thing altogether to open up your mouth and acknowledge it face-to-face, especially if you’re the father. (Disclaimer: To be clear, I do not recommend telling your spouse your new baby is ugly. Needless to say, some things MUST be left unsaid.)

It’s not always easy to be around the courageous souls willing to jeopardize their careers for the sake of improvement. And it takes level 5 courage to manage them. But, if you want your company to contract a terminal case of the Improvement Mindset, it’s a price you must pay.

Click this link for information on Mike’s upcoming workshop on Systematic DFMA Deployment

When innovation happens, a new product is created that does something that no other product has done before. It provides a new function, it has a new attribute that is pleasing to the eye, it makes a customer more money, or it simply makes a customer happy. It does not matter which itch it scratches, the important part is the customer finds it valuable, and is willing to pay hard currency for it. Innovation does something amazing, it results in a product that creates value; it creates something that’s worth more than the sum of its parts. Starting with things dug from the ground or picked from it – dirt (steel, aluminum, titanium), rocks (minerals/cement/ceramics), and sticks (wood, cotton, wool), and adding new thinking, a product is created, a product that customers pay money for, money that is greater than the cost of the dirt, rocks, sticks, and new thinking. This, my friends, is value creation, and this is what makes national economies grow sustainably. Here’s how it goes.

Customers value the new product highly, so much so that they buy boatloads of them. The company makes money, so much so stock price quadruples. With its newly-stuffed war chest, the company invests with confidence, doing more innovation, selling more products, and making more money. An important magazine writes about the company’s success, which causes more companies to innovate, sell, and invest. Before you know it, the economy is flooded with money, and we’re off to the races in a sustainable way – a way based on creating value. I know this sounds too simplistic.  We’ve listened too long to the economists and their theories – spur demand, markets are efficient, and the world economy thing. This crap is worse than it sounds. Things don’t have to be so complicated. I wish economists weren’t so able to confuse themselves. Innovate, sell, and invest, that’s the ticket for me.

Innovation – straightforward, no, easy, no. Innovation is scary as hell because it’s risky as hell. The risk? A company tries to develop a highly innovative product, nothing comes out the innovation tailpipe, and the company has nothing for its investment. (I can never keep the finance stuff straight. Does zero return on a huge investment increase or decrease stock price?) It’s the tricky risk thing that gets in the way of innovation. If innovation was risk free, we’d all be doing it like voting in Chicago – early and often. But it’s not. Although there is a way to shift the risk/reward ratio in our favor.

After doing innovation wrong, learning, and doing it less wrong, I have found one thing that significantly and universally reduces the risk/reward ratio. What is it?

Know you’re working on the right problem.

Work on the right problem? Are you kidding? This is the magic advice? This is the best you’ve got? Yes.

If you think it’s easy to know you’re working on the right problem, you’ve never truly known you were working on the right problem, because this type of knowing is big medicine. Innovation is all about solving a special type of problem, problems caused by fundamental conflicts and contradictions, things that others don’t know exist, don’t know how to describe, or define, let alone know how to eliminate. I’m talking about conflicts and contradictions in the physics sense – where something must be hot and cold at the same time, something must be big while being small, black while white, hard one instant, and soft the next. Solve one of those babies, and you’ve innovated yourself a blockbuster product.

In order to know you’re working on the right problem (conflict or contradiction), the product is analyzed in the physics sense. What’s happening, why, where, when, how? It’s the rule (not the exception) that no one knows what’s really going on, they only think they do. Since the physics are unknown, a hypothesis of the physics behind the conflict/contradiction must be conjured and tested. The hypothesis must be tests analytically or in the lab. All this is done to define the problem, not solve it. To conjure correctly, a radical and seemingly inefficient activity must be undertaken. Engineers must sit at their desk and think about physics. This type of thinking is difficult enough on its own and almost impossible when project managers are screaming at them to get off their butts and fix the problem. As we know, thinking is not considered progress, only activity is.

After conjuring the hypothesis, it’s tested to prove or disprove. If dis-proven, back to the desk for more thinking. If proven, the conflict/contradiction behind the problem is defined, and you know you’re working on the right problem. You have not solved it, you’ve only convinced yourself you’re working on the right one. Now the problem can be solved.

Believe it or not, solving is the easy part. It’s easy because the physics of the problem are now known and have been verified in the lab. We engineers can solve physics problems once they’re defined because we know the rules. If we don’t know the physics rules off the top of our heads, our friends do. And for those tricky times, we can go to the internet and ask Google.

I know all this sounds strange. That’s okay, it is. But it’s also true. Give your engineers the tools, time and training to identify the problems, conflicts, and contradictions and innovation will follow. Remember the engineering paradox, sometimes slower is faster. And what about those tools for innovation? I’ll save them for another time.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change.

The relationship between innovation and technical risk must be changed. For every unit measure of innovation there must be less technical risk. Or, conversely, for every unit measure of technical risk there must be more innovation. Sounds great, but how? Well, deep questions like this deserve deep answers, answers that only the great philosophers can provide. As it turns out, the great American philosopher (and baseball player) Yogi Berra provides the answer:

If you don’t know where you are going, you will end up somewhere else.

“Where we are going”, our destination, is a solution to a technical problem which the innovation process winds us toward, and the probability we’ll “end up somewhere else”, getting lost, is technical risk. We’ve got to know where we’re going if we’re to have any hope of getting there.

The key to getting there is problem definition. Not the regular kind, but the physics-capturing kind; the kind that is expressed simply, with regular nouns and verbs, that can be explained to non-technical folks, and fits on one page. An example of this one-page problem definition can be found in a previous post. (Search the site for “one-page thinking”.) Problem definition of this type is powerful and difficult, and it’s the key to innovation. Once the real problem is defined, once the physics are understood and can be described plainly, the problem is solved, and the destination is close-at-hand.

Not many have seen or done this one-page, physics-capturing problem definition. And it’s power is severely underestimated and poorly understood. I’m sure many think I’m off my rocker when I say that one-page, physics-capturing problem definition is the key to innovation. But, I stick by my assertion. Once this hyper-rigorous problem solving helps you know where you are going, innovation can be as straightforward as entering a street address into your GPS.

Identify specific failure modes, prioritize them, and go after the biggest ones first. Failure modes can be identified through multiple sources. Warranty data is sometimes coded by failure mode (more precisely, symptom type), so start there. The number one failure mode in this type of data is typically “no problem found”, so be ready for it. Analysis of the actual products that come back is another good way. Returned product is routed to the appropriate engineer who analyzes it and enters the failure mode into a database. A formal design FMEA generates a list of prioritized failure modes through the risk priority number (RPN), where larger is more important. To do this, engineers are hauled into a room and a facilitator helps them come up with potential failure modes. One caution – the process can generate many failure modes, more than you can fix, so make the top five or ten go away and don’t argue the bottom fifty. It makes no sense to even talk about number eleven if you haven’t fixed the top ten. But the best way I have found to identify failure modes (problems) that are meaningful to the customer is to ask the technical services group for their top five things to fix. They will give you the right answer because they interact daily with customers who have broken product. They won’t expect you to listen to them (you never listened before), so surprise them by fixing one or two on their list. They will be grateful you listened (they’ll likely want to buy you coffee for the rest of your career) and your customers will notice.

Once failure modes are identified, define the physics of failure – why the product breaks. This is tough work and requires focused thought and analysis. If, when you break the product, it “looks like” the ones coming back from the field, you have defined the physics of failure. This is the same thing as replicating the problem in the lab. Once that’s defined, create an automated test rig or experimental setup that breaks the product in a way that captures the physics of failure. I call this test rig a robustness surrogate because it stands in for the actual failure mode seen in the field. The robustness surrogate should break the product as fast as possible while retaining the physics of failure so you can break it and fix it many times before product launch. The robustness surrogate should be designed to break the product within minutes, not hours or days – the faster the better.

To know if product robustness is improved, the baseline (or existing) design is broken on the robustness surrogate. The new design must survive longer on the robustness surrogate than the baseline design. The result is A/B data (baseline design/ new design) that is presented at the design review using a simple bar graph format which I call big-bar-little-bar. Keep improving robustness of the new design even if it outperforms the baseline design by a factor of ten – that’s not good enough for your customers.

Don’t stop improving robustness until you run out of time, and don’t stop if you meet the arbitrary MTBF specification. Customers like improved robustness, and in this case too much of a good thing is wonderful.

Using this method, I reduced warranty cost per unit by 75% over a five year period. It worked.

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.

My mind clicks and I remember a discussion we had the previous week while on a walk.  I ask, “Do you remember talking about that trick to break intellectual inertia?” “Ya, we talked about how I used it to help a kid work himself out of some destructive behavior. Make it worse and do the opposite,” he says. “I love it; it works great,” he says. I now have my topic. We talk for a while and he helps my thinking converge. This one is a joint effort.

Here’s the problem: problems are stressful. We have a physiological reaction to problems; adrenaline rushes through our veins; our blood pressure increases; our heart rate increases; we get flushed. This is real. It’s run or attack, flight or fight. Our mental processing is all about survival. And there is real reason for concern; there are real consequences to not solving a problem – your reputation, your authority, your job.

There is a certain type of performance anxiety around problem solving. “Solve this problem” makes our thinking mushy. It’s like the deer-in-the-headlights. Problem solving is mentally trying; it’s hard work; it’s a chore.  So, just when it’s most important to have our thinking together, our bodies betray us and tear apart out thinking. Don’t know what I’m talking about? Here are some problems for you: fix our healthcare system; fix our banking system; change your behavior so you don’t use drugs.  Well, have you solved them yet?

While studying TRIZ with Victor Fey, I learned a simple method to overcome the stress-induced blockage.  It’s based on the notion that it’s simple and fun to make problems worse. Here’s the method – make the problem worse and do the opposite. We have a natural ability to make problems worse.  It’s easier to sabotage than to solve, and it’s actually fun. People are energized when asked to make a problem worse.  No stress, just laughing, and a sea of ideas to make it worse. With the “make it worse activities” in hand, the “do the opposite actions” come straight-away.

I am not exactly sure why the method works, but it does. I think has something to do with lowering expectations of a solution and eliminating the associated stress and mental binding. Somehow, the method takes advantage of our little known natural ability to make a bad situation worse.  And I am unsure why it’s pleasurable, but it is.

Remember those tough problems – healthcare, banking, drug use?  I bet you can come up with ideas on how to make them worse, I mean really bad. Go ahead. How can you make healthcare worse? Do the opposite. How can you make our banking system worse? Do the opposite. What behavior makes drug use worse? Do the opposite.

I urge you to have some fun with the method, and try it on your toughest problem.  Break the mental binding and solve your problem. It works.

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.