What Is The Customer Really Buying?

Background: Frank’s still-under-warranty freezer stopped working. The service tech decided it would be repaired, ordered a new compressor and said “See you when the part gets here next week.” Frank and his wife, about to lose a freezer full of food, are not happy with the with this level of service, call “Customer Care” and are basically told that the repair will run its course.

The question posed at the end of follow-up #1 was:

“What, exactly, did the customer want here?”

I asked that question because occasionally it is good to think about not only the product we make or service we deliver, but to reflect a bit on exactly what value the customer receives from that product or service. Sometimes we confuse the technology we apply to get something done with what we are really trying to do.

Let’s look at Frank’s case. If, instead of Bellevue, Washington in July the freezer had broken down in Grand Rapids, Minnesota last December, this would not have been an issue at all. Take the food out of the freezer and set it on the porch where it was actually colder than in the freezer.

What the customer is buying is not a freezer, but an environment that keeps food from spoiling. Any environment that accomplishes that purpose will work. With our current technology, freezing the food by placing it in an insulated box with a vapor-compression heat pump attached is the best way to do that. But it isn’t the only way.

What upset Frank, and his wife, was not so much that it would take a week to fix the freezer, but that their food would spoil in the meantime. Any solution that solved that problem would have worked for them.

What, exactly, does the customer find valuable?

You press the button, We do the rest.

Sometimes the product or service simply helps the customer create, or recreate, an emotion. George Eastman “got that” and grew an empire from that idea by making photography simple enough for anyone to do. Prior to that, amateur photographers had to mess with mixing their own chemicals, glass plates, their own processing, and persevering to actually get a photograph. The value came from the technical accomplishment as much as the image itself. But that didn’t work for families that just wanted to remember an occasion, and share it with their friends. Kodak changed all of that forever. But their way wasn’t the only way, and a few years ago, a better way emerged. It wasn’t about the technology, it was about sharing the memories.

I have spent a lot of time in the construction equipment business. I recall a senior manager making a pretty insightful comment. “The only part of the crane that the customer cares about is the hook. Everything else just makes it work.”

Most construction equipment is actually is capital equipment for the customer’s business. The owner-operator of an excavator is selling a service: The customer has dirt where he wants a hole. The excavator is a tool that can fix that problem. The owner-operator needs to be able to deliver the service at a price his customer is willing to pay and still be able to make a profit. That fact, in turn, sets the prices for the equipment.

But it is important for the seller of that equipment to remember that, to his customer, it isn’t an excavator so much as a business. The seller that thinks “How can I help my customer provide better service to his customers?” rather than “I sell decent hardware at a fair price” has an opportunity to think of things beyond the hardware itself.

Look at your own operation. What value do you provide to your customers? Not just the product itself. What is the problem the customer can solve, or what is the source of pleasure he gains from your product or service? How would (or could) the customer solve the same problem, or gain the same benefit, without your product or service?

What is your customer really buying?   What business are you really in?

Design Innovation Example

This post on the Fastcompany.com blog shows a clever desktop manufacturing invention.

But what really got my attention was the development process that starts at 3:40 in the video. It shows the process of developing it. They may not call it “3P” but, by and large, this is what it looks like.

As they develop ideas, they try them out in simulation, learn, improve, try, learn, improve. As the design matures in stages, they are moving forward, step by step, with concepts that are solid. This process is fast, flushes out problems early, while they are cheap to fix, and fun.

Contrast this with what might be created by a traditional process with the assignment of making a “tabletop NC cutter for cardboard.”

Is this a “problem?”

This morning I got an email from a friend that recounts a (still ongoing) story of a failed freezer.

We arrived home Tuesday from a week away to find the “extra” freezer in the garage totally kaput…..much of the stuff inside already ruined but some still partially frozen. It’s only 4 years old and within warranty, so [we] go on line and schedule an appointment with GE service for the next day, and spend hours sorting what [food] might be savable, getting bags of ice to try and bridge the time until (you would assume) they will exchange this unit with a new one. Tech comes out the next day, announces that the compressor is fried, and that he’ll order the part and see you in a week to install.

Needless to say, the customer is not exactly happy here. What could be saved now cannot. When they elevate the problem to “Customer Care” on the phone, the answer is basically holding the line to the warranty terms which give the company the option of replacing or repairing the unit.

Aside from speculation that the response would be different if this had been a commercial unit for a large corporate customer, this story brings up some interesting issues.

Clearly the company here is well within their agreement with the customer. That is (apparently) spelled out in black and white in the warranty, all approved by the legal department. And repair of the unit is the logical economic choice for the company.

But equally clearly, the customer here is not happy with the response.

All of my protestations about how an exchange unit shipped from their warehouse in Kent today would allow my wife to save her food falls on deaf ears. Not even a transfer to a “supervisor” for exception resolution could be arranged. If you don’t like it, tough luck..not buy another GE product? “hey, your choice” hard to believe!

And a customer with a technical problem has likely been turned into a customer for the competition.

So here is the question.

“Is this a problem?”

And when I say “problem” I mean, is this a “problem” from the standpoint of the company’s internal process?

I have my thoughts, and I’ll share them in a day or so. But I’d like to hear what you think.

“Creativity” vs “Opportunity for Error”

One of the things I often hear when we start talking about mistake-proofing and standardizing operations is that we are taking away people’s “creativity.”

“Creativity” in this case is usually the challenge of figuring out how to make a broken process function, or figuring out how to make the product work when, as designed, it doesn’t. “Creativity” means knowing what Julie actually keeps a stash of the parts that are always short, and knowing how to interpret vague, contradictory or obsolete drawings and work instructions. Nobody can look me in the eye and honestly say that a workplace like that is fully respectful of people.

Honestly, the very last thing I want to do is take creativity out of the workplace. But on the other hand, how much creativity is totally wasted on things that should be simple and straightforward?

As long as people’s mental energy must be expended to simply get the process to do something useful, there is none left for them to figure out why is doesn’t work and fix it.

The illusion, I think, is that once things are standardized that there will be nothing left to do.

Nothing could be further from the truth. There is plenty of work to do.

First, “standardizing” is simply setting down what we believe is our best shot at what should work. Once reality sets in, there are nearly always things nobody thought of – opportunities to learn. Capturing those moments is impossible if there is no consistent baseline in the first place.

And, just for the sake of argument, let’s say that the process, as designed, works pretty well. The question must then be asked: “Are we able to provide our customers exactly what they need, exactly when they needed it, on demand, one-by-one, perfect quality, in a perfectly safe environment?” If the answer to that question even includes a hesitation, then it there is work to be done.

Respect your people. Simplify the things that should be simple. Let them focus their creativity on something that matters, not on how to get through the way without screwing up.

Get Specific

A couple of days ago I had an interesting session with an improvement team in a fairly large company. They have been working on this for almost 10 years, and believe that while they have made some spot progress, they are clear that they have spent a lot of money but not yet established what they call a “lean culture.” Their implied question was “How do we get there?”

My question was “When you say ‘a lean culture,’ exactly what are you thinking about?”

What do people do? How do they behave?

“People find and eliminate waste every day.”

OK, so if they were doing that, what would you see if you watched?

There was a bit of a struggle to articulate an answer.

I see this all of the time. We rely on the jargon or general statements to define the objective, without really digging down the next couple of layers and getting clear with ourselves about what the jargon means to us. This is especially the case when we are talking about the people side of the system.

But the people are the system. They are the ones who are in there every single day making it all happen. It is people who do all of the thinking.

Consider these steps:

  • Define Value.
  • Map your value streams.
  • Establish flow.
  • Pull the value through the value stream.
  • Seek perfection.

This is the implementation sequence from Lean Thinking by Womack, Jones and Roos, that has been the guideline for a generation+ of practitioners.

Learning to See taught that generation (and is teaching this one) to establish a current-state map of the value stream, and then a design the future state to implement as flow is established. The follow-on workbooks focused on establishing flow and pull, and did it very well.

While not the only way to go about this, it does work for most processes to establish flow in materials and information.

But what do people do every day to drive continuous improvement, and how are those efforts organized, harnessed, and captured to put the results where they can truly benefit customers and the business?

Here are some things to think about.

What exactly is the target condition for your organization? Can you describe what it will look like? Can you describe it in terms of what people experience, and do, every day?

When your people go home to their families and share what they did at work today, what will they talk about? And I don’t just mean the engineers and managers. What will the front-line value-creating people remember from the workday?

How will they talk about problems?

If your target future state now includes changes in how people work, ask yourself more questions.

When, exactly, are they going to do these things you described? By “when” I mean what time, starting when, ending when.

What, exactly, do they do when they encounter a problem during production?

How, exactly, do you expect the organization to respond to that problem? Who, exactly, is responsible to work through the issue and get things back on track? How long do they have to do it? If the problem is outside their scope, what is supposed to happen? How, exactly, does additional support get involved?

If these new activities involve new skills, when and how, exactly, are people supposed to learn them and practice them to get better at it? Who is supposed to teach them, when, where, and how? How will you verify that the new skills are being used, and are having the effect you intend?

“If we do this, what will happen?”

And then what? And then what?

Think it through.

The “people” future state is far more important than future state of the material and information flow.

John Shook: “A Technical Problem or a People Problem?”

John Shook dives into some of the messy issues of true root cause in his most recent post.

We touched on a similar issue here a few months ago. But it is always worth coming back around to people because because in this system (actually in any system) there are always two issues with people.

  1. People are the most fallable part of the process.
  2. The process cannot operate without them.

The reflex is often to go into total denial about #1 and expect people to be vigilant and perfect every time. “Weed out the bad apples, and everything will be fine.” Of course that doesn’t work.

In John Shook’s example, he traced through Ohno’s classic “5 Why” example.

1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently?
The lubrication pump was not working sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was warn and rattling.
5. Why was the shaft worn out?
There was no strainer attached, and metal scrap got in.

Then Shook asks a really interesting question:

Why was no strainer attached?

Why not indeed? Isn’t that somebody’s job?
And now, as he points out, we have transitioned from “technical” to “people.”

Maybe the standard work for the maintenance worker or machine operator didn’t go far enough. Or maybe the standard work did specify changing the strainer but the worker failed to observe the standard. How was the standard developed, how was it communicated and trained? How easy was it to “forget” to change the strainer?

Coming, as I do, from mostly “brownfield” environments, the existance of standard work in the first place isn’t something that we can take for granted.

Nevertheless, Shook is making a critical point here. It does not matter whether there was no standard work, or whether the standard work broke down for some reason that we do not yet know (another “Why?”). This is still a process problem. We must start with a working assumption that the team member cares, and is doing the very best job possible, given the expectations, the resources, and his understanding at the time.

I am aware of a couple of cases where engineering change implementation pulled up short of actually observing the new installation and looking for unforeseen problems. One of them was quite subtle, and actually took a few weeks to find the basic cause, much less the root cause.

Another resulted in a bolt snapping during final torque. Messy to fix, but better in the factory than in the field.

These are additional cases where technical problems resulted from process breakdown, and in both cases, it was a case of unverified or blindly held assumptions, and not following through with the customer process.

Shook concludes with two really important points, and I can’t agree more. First:

…the work design must also include the “human factors” considerations that make it possible to do the job the right way, and even difficult to do it the wrong way.

I like to say “Make the right way the easy way” if you want things done in a certain manner.

Which brings us to Shook’s final point: You have to look at the total package – the human and the technical as an integrated system. You can’t separate them because. You can’t “take people out of the process.” All you can do is construct the process to give people’s minds the most opportunity to focus on improving the work rather than burdening them with making sure they get it right.

Always work to support people to do the right thing in the right way. If the organization carries a belief that it is necessary to force or “incentivize” people to do the right thing, then there is a people problem, but it isn’t with the workers.

Evidence of a Problem

In most references describing the process of good problem solving, the first real step is to explain what actually is the problem.

It is easy to get tripped up at this stage and describe the problem in terms of the desired target, or in terms of “lack of” a specific countermeasure. That, of course, skips over the whole point of gaining a deep understanding of the situation before moving too far into intestigating causes.

I heard a great way to frame that first bit of description tonight from Richard.

“What is the evidence of a problem?”

That word, “evidence” does a much better job of conveying the point that this should be a description of the things that are observed, heard, felt, etc. rather than any kind of analysis.

In many cases a “big problem” is actually evidence of many small ones. “Too much inventory” is one of those. So is “defect rates” or any other aggregated measure. If you are running KPIs you probably know that, because they aggregate so much, they are often relatively insensitive until things are so far into the hole that it is a mess to untangle. Better to instrument your processes at much finer levels and get “evidence” in real time.

How Do You Look At Problems?

A couple of posts ago, I tried to emphasize “hypothesis testing” as the key, core thinking behind the TPS. For that matter, I think that anyone who truly understands any of the various improvement approaches out there will find the same thinking at the core. Certainly Six Sigma; Theory of Constraints; and TQM are all about surfacing and solving problems. They may use different language, might insert the initial lever between different bricks, but in the end, the approaches all embrace the same basic thinking.

I’d like to put out there an idea that it is the way problems are regarded and approached that separates “gets it” from “business as usual.”

What Constitutes “a problem?”

In “traditional thinking” a problem is something which disrupts output. It is something serious enough that it cannot be ignored.

In a true continuous improvement mindset, anything that causes variation from the plan, in any way, is “a problem.” Any barrier between the current condition and the idealized world is “a problem.”

What triggers a response?

In “traditional thinking” if output isn’t disrupted, spend time elsewhere. There is a caveat to this, however. The parable of the “boiling frog” (whether true for actual frogs or not) can drive an ever higher level of numbness as “normalized deviance”   sets in.

Since continuous improvement is a process of discovering the ideal process, variation from the plan is new information. It must be investigated and understood. If everything is running smoothly, then the problem solving shifts to the next barrier to higher performance.

What triggers alarm in the organization?

This one may be the most controversial. While “stopped production” is certainly cause for alarm and immediate response, in the traditional thinking world, it is the only thing that really gets people’s attention.

In a thinking and learning organization, I would add to the above “No problems are apparent.” If there are no andons, there are no defects, there are no line stops, there are no shortages, there are no disruptions, then there is a BIG problem. I say that because these conditions are impossible and it is only because your system is totally numb that you would not see them.

Target Condition

Given the above, then I think it is safe to offer that silence is equated with “stability” in the traditionally reacting organization. Of course it isn’t stable at all, it is just that there is so much systemic anesthesia that nobody feels anything.

In the continuous improvement mindset, things are running as they should if there is a continuous flow of problem being surfaced and solved. That is the only way to be 100% certain that things are getting better every day.

“Management Commitment”

The term “management commitment” is tossed around as a prime reason for failure of improvement initiatives. There are lots of good reasons for this, but until we really define exactly what leaders need to do every day, stop using euphemisms, and start getting real about leadership’s actual role in this process, we are crutching the problem. This is partly “our fault” because we teach the basics very badly. We put top leaders into “kaizen events” but never explicitly link kaizen to daily problem solving. In doing so, we convince them that if only they support enough kaizen events, the organization will be transformed. The logical result is a monthly report on how many kaizen events have been run. Argh.

If we used kaizen events to explicitly teach the core questions, the rules of good process design, and the concept of applying PDCA to everything, we might get more traction. That can be difficult, but maybe if everyone in the industry starts thinking in terms of a few core mantras we might get a chorus going.