原创 Listening to Your Customers

The customer is often wrong.

The agile notion of constantly soliciting customer feedback and incorporating that input into a product is a brilliant way to produce prototypes. Prototypes, of course, are poorly-implemented skeletons that mirror a real product.

Their function is to quickly minimize risk, which arises from vague requirements, unknown science issues, or from other uncertainties. Prototypes are invaluable when needed but are not required for every product. Maybe not for most.

Engineering teams need to be sheltered from customers when developing the real product.

The customer might be an end-user, who, halfway through the engineering effort inexplicably asks for an MP3 add-on to the bottle opener. Or he could be a member of the sales team. My career has been haunted by these guys who invariably say "I can't sell that piece of crap unless you add this feature."

That statement is often correct, though it really illustrates the salesman's own incompetence and is not a commentary about the viability of the product. Sales always asks for more and more. By tomorrow. So do customers.

Iterative elicitation of requirements, while sometimes necessary, is often a substitute for poor requirements analysis. Change does happen, of course, even on the most well-understood products, which is why companies have change control procedures.

Sam Walton was right when he said "There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else."

When a customer asks for a change, the only proper response is: "Mr. Customer, we love you. We'll do anything you want. But there will be a cost, perhaps in schedule or dollars. Let me get back to you."

Any other response will yield poor customer service as he'll be disappointed by the suddenly-late product. Or angry when he discovers that the added MP3 player now means the bottle opener has to be charged every night.

Open communication is key, and that interaction is best if each party has time to think through the implications and the honesty to be clear about what the effect of the change will be on the product.

Change control adds friction to the process, a needed friction. Wild responsiveness is sometimes indistinguishable from chaos.

I once delivered a sailboat owned by a younger fellow who had grown up surrounded by electronics. He steered by the course painted on the GPS screen, and just could not understand when I complained that the GPS only knows where we were pointed, not where we want to go.

We zigged and zagged all the way down the Chesapeake Bay, getting to Norfolk eventually but much less efficiently than if steered by a steady hand reading the compass.

Set a course, follow it, and change it with forethought only if necessary.