Who is your customer?

This is a popular question in consulting circles — the starting point for most exercises in process redesign.

But process redesigners don’t need to identify customers. They need to identify consumers. Consumers, not customers, understand what they need from a product or service. They’re the experts when it comes to defining specifications.

For process redesign, the distinction between customers and consumers — that customers make buying decisions, whereas consumers use products and services — doesn’t matter, because processes don’t have customers in any important sense. Unfortunately, the “internal customer” concept escaped the narrow confines of process redesign long ago and has been rampaging through many companies ever since, leaving hopeless confusion in its wake.

If you’ve been an IS manager for any length of time, chances are some consultant or other has asked you who your customer is. They should have asked you who your customers and consumers are, because they’re different, and when customers and consumers are different people, it greatly complicates everything. Why?

Customers, by definition, define value. Consumers, on the other hand, define good specifications. When the people who define value and the people who can help you with specifications don’t agree about priorities — and when they’re different people with different goals, how can they? — then how are you supposed to make good decisions about your product or service?

That’s why industries in which the two roles are split are weird. Take the airlines. I’m pretty sure their consumers would prefer inter-seat spacing that exceeds the length of the average human femur, just as they deplore the ever-shrinking in-flight meal. Business travelers though, aren’t the airlines’ customers, only their consumers, (purchasing managers are their customers) and the airlines know it.

In IS, your customers aren’t your consumers either, which is why I generally recommend jettisoning the whole “internal customer” metaphor at the first opportunity. It isn’t that you don’t have internal customers. You do. The CEO and executive committee — the people who approve your budget — are your internal customers. The internal version of a buying decision is budget approval, after all, so by all means keep your customers happy.

Now about those consumers. Do you need to keep them happy too?

Good question. As the airlines have shown, there’s no connection between happy consumers and “success,” let alone a connection between unhappy consumers and failure, so in many companies — certainly, any company in which the executives don’t give a rat’s nostril about the well-being of their employees — you can lead a thriving IS organization and enjoy a successful career by pleasing only your customers.

Well, kind of. Maybe. Except that …

There comes a time in most IS careers when you roll out a new system or a major upgrade. Employees have three choices at a time like this: Embrace the new system; use it as little as possible; or find manual workarounds that let them ignore it completely while still getting their jobs done.

Think your career will thrive when employees fail to use a system the company spent bazillions to implement?

So … what makes the difference between enthusiastic acceptance and rabid resistance to a new system?

It’s obvious, isn’t it? Employees embrace technology that helps them. If you want a system to succeed, design it so it gives something back to the people who will be using it every day. Every single consumer must perceive a net personal benefit from the system.

If you want it to fail, design it so one group experiences more work and inconvenience while “the company” or some other group of employees receives the benefit. What, do you seriously expect employees to sacrifice for the good of the company?

Everything you implement must give something back to the employees who operate it. This doesn’t mean you have to optimize it for them. Go ahead and optimize it for your customers, whatever that means.

In a healthy company, it may even mean the same thing.

Computers operate on binary logic – one or zero, true or false, yes or no.

I guess it’s contagious.

A while ago I gave a simple piece of advice: Never say no. Quite a few correspondents ignored the essay that followed. Instead they applied the binary system to my advice, inferring that I’d told them to always say yes.

False inference. The binary system is wonderful in its place. Applied to human decision-making, though, it’s usually disastrous, forcing a universe of possibilities into two oversimplifying buckets.

To illustrate, imagine a business manager asks you to install a Windows NT server for his department (we’ll pick on NT today – next time we’ll choose a different OS to victimize) so he can run a particular packaged application, in violation of your standards and personal judgment.

What do you do?

You can say “I’m sorry, but that would violate our standards,” or, “We try to avoid NT because it’s far less stable than the other solutions on the market.” Care to guess how the manager will describe your encounter?

“He was a typical chip-head. He never listened to me. He just kept on telling me that what I want won’t work, without once explaining why and without explaining how it is that three of our competitors are doing exactly what I asked him for.”

Is that the way it happened? From your perspective no, from his perspective yes. It’s binary, and his audience is listening to him, not you.

How should you handle a request like this? Be non-binary by responding with a “forcing question” – one that directs the conversation into the right channels. Say, “NT is just an operating system. Let’s hold off on that discussion until we’ve talked through what it is you’re trying to solve. Now what is it you’re trying to accomplish?”

Wham! You’ve forced the conversation into a productive direction. After a while you understand what your new-found friend is trying to accomplish, and then he says, “Now when can I have my NT server?”

Don’t say, “I really think you’d be better off using Linux,” (or Solaris, or AS/400, or Network Computers, or what-have-you). Use another forcing question: “I’m curious – where did you hear that an NT server is the best solution?”

He’ll tell you. He may have heard it from his peer in another company or the sales representative from the application vendor—or it may be that NT is the only operating system he’s ever heard of.

After he tells you, chances are he’ll ask, “Why … is NT the wrong choice?” He’ll ask because the intelligent conversation he just had with you (in which you remained almost entirely silent) has established you as an expert.

If he doesn’t ask, you have more forcing questions to ask, like, “Have you thought through the integration issues you’ll face by going down this path?” He’ll almost certainly either explain his thinking about each issue you raise or ask you to explain it to him.

Don’t take this to extremes. Three issues are enough. Your goal is to move from his proposing a solution to mutual problem-solving.

Let’s imagine all is for naught and this particular manager turns out to be an obstinate fool, insistent on this direction despite your best efforts to bring him to his senses. Do you say no now?

Nope. Your job isn’t to say no. It’s to help this guy succeed. Tell him that. Then use a different negotiating tactic called “absent authority.” Say, “Unfortunately, NT is outside our standards, which means I don’t have the authority to make this decision – let me describe the process you need to go through.”

Make sure the process for approving all bad ideas belongs to the IS Steering Committee, which is chaired by the CIO, populated by the company’s key executives, and responsible for approving resource allocations for IS projects.

Let someone else say no, not you. And if the IS Steering Committee approves this request and is willing to fund it … that’s its privilege.

Yours is to go make it work.