Why the customer isn’t always right

Last week I went to get my hair cut (yes, sorry, this is a story about hair). I had thought long and hard about what I wanted. I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion. I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with. I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.

He did an excellent job. It was almost exactly what I had asked for, with some variations to account for my particular hair type. It was a very cute hair style that suited me. But I had a niggling doubt.

A few days later, that niggle was a certainty. It wasn't what I wanted.

However, it was what I had asked for.

Being English, the thought of going back and telling him I wasn't happy with it was horrifying. Especially since he had done a really good job of it. It wasn't his fault that what I'd asked for wasn't what I had actually wanted. But I knew what I wanted now, and I was prepared to pay for it (again).

This time I didn't show him a picture. I didn't point to anything specific. I said I wanted it much shorter after all and outlined the look I was going for. We had a conversation about it and I left it to him to apply his skills to actually implement it.

This time, I was much happier with the results. In fact, it was exactly what I wanted.

So what?

Of course this got me thinking about work. It's not just a lame excuse to write about girl stuff on a supposedly technical blog. It got me thinking about our customers.

Whoever our customers are, whether they're end users, internal business owners, external clients, or we work in a bank and have fifteen thousand layers of Business Analysts between us and Real People, whoever they are they want something from us. And in many places, we, the techies, have trained them to ask for more and more specific things, so they can be sure they're going to get what they really want. Remember that time Bob asked for that extra field on that report because it would make his job easier? Remember when Sandra wanted the workflow to be altered in a specific way? It's because they know that if they ask for something specific, the chances are better that it will make its way to the front of the work queue at some point, and when it comes out the other end it is more likely to be what they wanted.

Only it isn't, is it?

There's always another field to add, or another change to make. And your customer isn't quite satisfied, even though you did exactly what they asked for. And sometimes they don't tell you that they're not getting what they need from your system, because it's expensive or time consuming to get changes made.

The key to delivering something they really want, instead of something else that's merely adding to the weight of your code, is finding out what they're actually trying to achieve.

So Bob wants that extra field. That's easy enough. But when you ask him why he wants that extra field, turns out it's because the numbers in the reports he's getting at the moment aren't the ones he needs, or aren't quite correct. He's probably created a monstrous Excel spreadsheet into which he manually types half of the numbers from the reports it took you ages to develop, which munges them into something quite different, in order to get the real thing he wants. He's just missing this one small piece of information to get the final figure correct. It would save your company a lot of time/money/mis-typing errors if you completely re-wrote the reports Bob uses to give him exactly what he needs. Or if you gave him a tool to download CSV formatted raw data from the database.

It's not Bob's fault he can't ask for this, he doesn't know what we're capable of providing him. It's not our fault for not delivering it the first time round, we don't know what he does day-to-day. But having a conversation where we recognise where the knowledge lies (Bob knows what the output of his day job is presumably, and we know what's available and how we can provide it), and collaborating to come up with the least rubbish solution for everyone, is a step to providing that overused term, "business value".

We're not on different sides here, we all play for the same team - we want our jobs to be as painless as possible, which (should) ultimately provide better efficiency for our company. After all, we want the company to make money so they can pay us, right?

Caveat: Mileage may vary. Sometimes, with some customers, you really do need to tell them what they want.


  • Trisha Gee

    Trisha is a software engineer, Java Champion and author. Trisha has developed Java applications for finance, manufacturing and non-profit organisations, and she's a lead developer advocate at Gradle.

    View all posts