The Customer is Always What?

Mark "Justin" Waks
4 min readJan 31, 2019

--

There’s an old and largely unexamined saw in many services industries: “The Customer is Always Right”. I’ve seen it picked up and tossed around in software for many years now, particularly in consulting (the more “service-y” side of programming) but also in the product world.

On the one hand, it’s a useful counter to the programmer instinct to produce software that is Cool and Interesting and Beautiful (but frequently not, y’know, Useful). It gets across the important idea that It’s Not All About You. Yes, it’s important to be motivated in your work, but ultimately, in most cases, you’re not just writing this software for yourself.

On the other hand, it has one fundamental flaw, especially when you try to use it on a typical literalist programmer: it’s obviously nonsense.

Yes, there are occasional customers who are at least usually right. Treasure them, for they are among your most valuable assets. The customer who really groks what you are doing, and provides bug reports and feature requests that fit that framework, will give you insights into your software that you will have difficulty getting any other way.

But those customers are few and far between. More often, the customer is sometimes right, but sometimes wrong — they haven’t thought the problem through far enough, or don’t understand the technical issues involved, or are just being willfully blind to reality. Some customers are usually wrong. (A few turn out to be batshit crazy.)

So the statement is wrong, and kind of begs argument. But we shouldn’t throw the baby out with the bathwater. So let’s instead say what we really mean:

The Customer always matters.

That is, if they’re the customer, you should be taking their statements into account. If they are the ones ultimately paying the bills, then you should never simply disregard them. Sometimes, there’s nothing for it but to help them understand why reality doesn’t match what they are saying. (Note: this is not the same thing as talking at them without effect. If they don’t get it, you are failing.) Frequently, they are right, and you should have enough humility to be able to recognize this when it happens. And sometimes, you just have to suck it up and roll with the stupid, because it’s what they want and they are paying the bills.

But — and this is the really important part — you have to have your eye on the big picture. Especially if you are building a product, the Customer may well be wrong, and you need to be able to stand up and say that. When you get a feature request, the correct answer is neither “No, we have a plan and must stick to it” nor “Yes, sir!”. Instead, you should always step back, look at the roadmap, and see whether rearranging things to do this now will cause any strategic problems. Often, you’ll find that this feature was on the roadmap anyway, and that it doesn’t actually cause any problems to move it up. When that happens, see if you can rearrange things to make the customer happy.

Some bullet-point corollaries that are worth pinning on your mental wall:

  • When a customer reports a bug, thank them. They are doing you a service by pointing out where something is wrong. Seriously: if you take away nothing else, remember this one.
  • Don’t get argumentative with the customer. If you think they are wrong, engage with them, listen sincerely and with an open mind to the possibility that they may be right. If they are wrong, it is your responsibility to help them understand why.
  • The customer usually isn’t entirely wrong. Even if their requested solution isn’t appropriate, they are usually identifying an actual problem. Work hard to tease out and understand that problem, and come to an agreement about it.
  • Corollary to that last point: UX bugs are still bugs. If the users of your software don’t understand how to use it, that is your fault, not theirs, and you should log that as a bug to be fixed.
  • Track every feature request. When a customer asks for something, the correct response is usually to add it to the story list. But be honest with the customer (and yourself) about where it is on the story list, and whether you’re likely to get around to it any time soon. There is no reason to be ashamed about the reality that you have to prioritize your work.
  • Never think of your customers as adversaries — if you get into that mindset, you’re probably dooming the relationship. Think of them as partners in building stuff that is both Great and Useful.

These are all rules I try to follow religiously with Querki, and they’ve worked well for me. I commend them to your consideration…

--

--

Mark "Justin" Waks
Mark "Justin" Waks

Written by Mark "Justin" Waks

Lifelong programmer and software architect, specializing in online social tools and (nowadays) Scala. Architect of Querki (“leading the small data revolution”).

No responses yet