When The Customer Sometimes Isn’t Right…

Mark Rittman -

The customer is not always right : "First, though, I’m posting the longest comic I’ve ever drawn - practically a graphic novel by my own standards - illustrating why the customer is not always right. This is an old adage which I think goes back to a time when it was your job to let the customer dictate terms to you, making the decisions about your products and services.

It turns out that this is kind of a crazy way to go about things. Most customers are customers because they themselves do not produce the product or service in question, and need someone else to do it. While, as the consumers of these goods and services, they definitely have some real insight on how improvements and additions could be made, they’re limited in some ways.

One limitation on the usefulness of customer input is that a customer will almost certainly make a request for himself without considering the needs of others. This can be quite obvious in jobs like mine where a customer who, for example, works in the underwater welding industry would like to see more presentations on underwater welding and web services. Obviously, this would be of limited use to other people in the audience.

And the list goes on.

So there’s a point at which the person responsible for producing the product or service has to put her foot down and draw the line. Otherwise, things like this might happen…"

Check out the rest of the article before you read on. Done it? Good.

This of course is yet another consultant's dilemma. The customer is always right, and yet the customer doesn't necessarily know what's good for him - if they did, they probably wouldn't have needed to hire you in the first place. This can manifest itself in many ways, including:

  • The Customer Who Wants To Implement Every New Feature - sometimes based on a presentation you've previously given, which can sometimes be tricky...
  • The Customer Who Has Already Decided What Technology To Use, Regardless Of Requirements - I've had many of these, where whatever you say they're going to implement it using a certain pet technology, regardless of the logic or the time/cost to implement
  • The Customer With The Nightmare IT Department - where the IT department second guesses every recommendation, imposes their own solution and then questions every architecture recommendation you make
  • The Customer With The Never-Ending Set of Requirements - adding "just one more feature" when you know that it's making it less and less likely you'll deliver while there's still a business benefit to be had
  • The Customer With Their Favourite Methodology - where you spend more time on documents and meetings than you do on analysis, design and coding
  • The Customer Who Doesn't Believe In Prototypes - and then ends up throwing the first version away anyway

... and so on.

So what do you do? Well this is of course a tricky one, and something that requires the kind of "soft skills" that most coders (including myself much of the time) sometimes lack. A lot of it in the end comes down to confidence, the confidence to have an opinion, have the facts (and ability) to back it up, and the people skills to handle someone who obviously believes things for a reason. At the end of the day, the customer might not be right but it's still your professional obligation to look out for them, however difficult that might be. Luckily, most of our customers are pretty switched on, and in some cases they can be right, and you can be wrong, and it's important sometimes to know when this is actually the case. From my point of view, the key to this is tact, solid product knowledge, testing things out yourself beforehand and as one of the original article comments put it, remembering that "The customer may not always be right, but they are still the customer".

Any thoughts on this?