Customer centricity is another one of those points that is constantly talked about but often rarely actually reasoned about. As a result, most of the discussion out there is usually trivial and essentially consists of the equivalent of “Go ask what the customer wants, then go build it”. I would respectfully offer the opinion that that is not customer centricity, but rather, customer servitude! There are three fundamental mistakes in the idea of “Go ask what the customer wants, then go build it”, and I want to examine all of them critically to dispel the trivial hype around the topic.

The customer is not always right!

The first mistake, is the hidden assumption that the customer is always right. Needless to say, this is simply not true, no matter what the old drivel says. If you absolutely need a cliché that sounds good, then I offer one of the wisest sayings from an old colleague of mine, when we were both consultants:

The customer may not always be right, but he's always the customer.

Antiquated drivel aside, however, the simple fact remains that the customer is not always right, and in fact he is quite often wrong. One of the advantages of being a consultant focusing on a specific domain, is that you get to learn your domain from multiple data points. This is primarily why consulting makes sense: your customer knows his domain - he doesn't need you for that. But he only knows one data point - his own. If you are a good consultant, you have learned from many customers in the same domain, and can therefore advise the customer based on experience that is in his domain, but he has never had the opportunity to acquire. This is what you bring to the table; knowledge that your customer would have no other way of obtaining. If you were to ignore that knowledge and simply do what the customer says, you are denying your customer the value that he cannot obtain without you, and offering him in exchange more of what he already has. In other words, in true consulting you only add value in those cases where you do not simply align with what your customer says.

This article, however, is not really about consulting (or even bespoke software) - it's about software products. The consulting scenario was merely an example that is easier and cleaner to think about. The principle still applies to software products, however, and even in many other types of products. Imagine any kind of enterprise software. The customer will certainly have opinions on how the software should work, but generally these opinions will be based on a data sample of one - his particular experiences in that particular enterprise. The problem itself, however, is not unique to that enterprise (or to that customer). Other customers at other enterprises will have solved the problem differently, and if you are a good product manager you should know every single one of their solutions.

In addition, your customers may lack the sophistication, or the knowledge and skill to innovate. This is your job, not theirs. Henry Ford is rumored to have once said:

If I had asked my customers what they wanted, they would have asked for faster horses.

At the end of the day, your customers are always solving their problem from within their specific box of experience. That is hardly a situation that guarantees that their solution would be right. It is your job to find the right solution. So when all is said and done, you should certainly go ask your customer what he wants, but only to learn the problem and his particular solution, not to build exactly what his limited experience and imagination could come up with. You should, in fact, ask each of your customers what they want (or, at least, as many as practicable), but only to inform yourself. You should then decide what the right solution is, based on all the information that you have gathered. Pick from the various solutions that you have seen from your customers, or innovate and create a brand new one based on the many data points you were able to gather. But certainly don't settle for offering them the same inferior solution they told you about. Customer centric is about building the best product for the customer, not about catering to his “Not invented here” syndrome, and offering him an inferior solution simply because it is one he is familiar with or emotionally attached to. Just as in the consulting example, if you simply go along with what the customer said in the first place, you are denying him the value that only you can add, having examined many more solutions in the domain than he has, and offering him nothing more than implementation services, just like any near-shore or off-shore vendor.

Which customer?

There is a reason why the usual drivel about customer centricity always refers to the customer in the singular. That kind of narrative is trying to avoid acknowledging the second fundamental flaw: that the customers (plural intended) do not agree with each other! If you have worked with customers in any environment other than bespoke software, you probably already know this. Customers will not only disagree on how to solve problems, but often explicitly contradict each other: Customer A will tell you that what Customer B proposed is the wrong solution, and vice versa. That alone should be enough to convince you that the customer is not always right. But it also brings up a different problem: In the face of contradictory information, who do you listen to? They are all the customer, so which one of them is “right”? At the end of the day, you cannot rely on each one individually, since they are each only seeing their part of the picture, but you must serve all of them. Once again, there is no single customer that is more right than the others. Instead, you must once again collect input from all of them, but decide for yourself what is “right”. Only a product manager with no courage and no conviction will simply do what one of his customers told him. Such a product manager is not looking to build a customer centric product, but is merely looking to make the customer be ultimately responsible for the fact that the product is not as good as it could be. His ultimate answer is not an explanation why he believes the product is great, but rather the excuse of “This is what the customer asked for!”

Even for a single enterprise, however, the question still stands: which customer? Except in extremely rare circumstances, the software will have multiple users. Which one do you listen to? The most common mistake is to listen to the sponsor, or to a representative, but without actually speaking to the real end-users. And when you do, you will once again be faced with the same problem: they will not agree on what the right solution is. Once again, you will have to be the arbitrator, by examining all of their respective opinions but forming your own mind as to the best solution. The worst you can do is defer to some internal decision maker to arbitrate between the contradicting opinions. This was a common pattern when I consulted with government clients: the internal decision makers would not allow us to do anything else. More often than not, the original end users that had disagreed with each other told me that they ended up with the worst of both worlds in such cases.

Incidentally, there are always some product managers that think they will be clever and get around the problem by building both options and switch between them using a run-time configuration. Well, I guess “clever” is a relative term then. I have three points to think about for them:

1. You still have failed in giving the benefit of your experience to your customer; nothing has changed! You are still just offering implementation services rather than product excellence.
2. This works for the case of enterprises as customers disagreeing with each other, but you still have not solved the issue of different end users within the same enterprise disagreeing with each other.
3. And you have now made it much more complicated to build and operate the product, which means you will offer a poor quality product. But we will talk a lot more about that in the next section!

Make sure you can build and operate it.

Henry Ford has another famous quote attributed to him:

Any customer can have a car painted any color that he wants so long as it is black!

As the story goes, he said this during a meeting with his management, speaking about the Model T, which according to the story, only came in black (in actuality, when first introduced the Model T came in a few colors, but not black). Henry Ford is often said to have invented the assembly line; a claim that may not be entirely accurate. What is unquestionably the case, however, is that he perfected the standardization of a product design to optimize the assembly line, and be able to produce the Model T at an affordable price and massive scale. Back when it was produced, it cost $240, and by 1927 there were 16.5 million Model Ts produced! Ford kept tweaking both the design of the car, as well as the assembly line itself in order to make it continuously faster and cheaper to produce Model Ts, and by 1914 it took only about 93 minutes to assemble a Model T! There can be no question that Henry Ford mastered the challenge of producing a product at scale and at an affordable price. The Model T is also said to have been significantly more reliable than its contemporaries.

Now, let's revisit the realm of enterprise software, but through this lens of optimizing a product for production, as well as for purpose. Even if we were to assume that the customer was actually right in his proposed solution for the problem, it does not mean that the proposed solution is the best from an implementation, reliability, or cost perspective. More often than not, the “customer” for a piece of software (often meaning the decision maker, but not necessarily the end user), is not a software professional, and will have little to no understanding of the best way to implement a solution reliably, and/or cost-effectively. Even if he does, he has little incentive to do so. The burden for this lies squarely on the shoulders of the product manager for the product. Any product manager that says that it is not customer centric to worry about implementation cost or complexity has but a superficial understanding of what customer centric really means! What is actually better for the customer: to have a user flow that is slightly different than how he used to do things, but have it be always present and realizable, or to have the exact flow he always used to use, but be denied access to it when the vendor that built it goes bankrupt? Which do you think the customer would prefer: 90% of the functionality he wanted available 100% of the time, or 100% of the functionality he wanted available 90% of the time? If those questions are not trivial for you to answer, then by all means ask your customers! I think their answer will make you think twice before you take on the cost and complexity of building three different options for each feature, and configuring which one runs with feature flags!

Also, do not be fooled into conflating “cool” or “desirable” with the idea of a good product. A good product is one that serves a lot of customers. Niche products never change the world! At the end of the day, which car did more for its customers, the Model T, or the Tesla?