Sadly, this is something I have heard too many people say too many times in the last couple of years. If you think your customer is stupid, I can guarantee you that either:
a) Your product sucks.
b) You did not explain it right.
Everybody understands that being on the cutting edge of technology is hard. However, developing a technical product is not an exercise in showing people how smart you are. It is an exercise in allowing the nonspecialized to execute a specialized function.
I don't need to understand the entire backend of Google to use their search function. I don't need to understand electronics, radio frequencies, battery chemistry and programming to use an iPhone. That's the whole point.
The main reason why I became a proponent of simplifying systems, and why I have a different approach to development than many people in Silicon Valley, happened early in my career. Back in the early 2000's I had the unique opportunity to work at NASCAR and specifically in the competition department. My boss was David Hoots. the Race Director. If you have ever watched a NASCAR race between 2000 and 2019, you'll have heard his voice on television. When I started working for David, he asked me to build him a completely new Race Director application that would feed him all the timing and scoring information he needed to control the race. That was my specialty, having worked for the company that developed the Timing & Scoring application for several years. He told me he wanted something called a "Lap Table" and scribbled on a notepad what it should roughly look like and then did the same for two or three other screens.
I built something for him based on his notes and showed it to him a couple of weeks later with a simulator. He told me I had too many buttons and said: "any button you put on the screen, I will click at the worst time." I explained that every button had a function and was useful and he just looked at me and repeated the same sentence. I did not agree at the time because I wanted to prove myself and considered myself an expert in the technology, but being new on the job, I realized I should do as asked and I so simplified.
Then, a couple of weeks later the season started. NASCAR always starts with their own version of the Superbowl, the Daytona 500. David wanted me to be in Race Control so I could be there to answer any questions. So, I sat there and watched him and the rest of the teamwork.
I was astonished.
David had three radios plugged into his ear: the timing & scoring team, the safety vehicle team and the main channel. Then there were two more radios on his desk, one to communicate to the race teams and the other one I don't know what it was for. Then he had the Series Director, the VP Competition and the President talking to him as well. It was an unbelievable amount of information that he had to process. Then I noticed that he was able to interpret the "Lap Table" screen effortlessly.
I understood exactly how the data was produced and what the data meant, but I had a hard time following him in how he actually interpreted the data and made decisions based on it. The "Lap Table" can get messy when there's lap down cars, pit stop cycles and accidents happening, but David was able to tell at a glance where everyone was and where they should be.
This is where I realized that although I thought all my fancy buttons were useful, there was no way it would have improved his job or, at least, not at that time. As we worked together longer, we did start adding more and more functionality, and I think David ended up with 8 or 9 different screens that he could access with F1 to F8 keyboard shortcuts. I also realized that, although I knew exactly how the technology behind the data worked and what the data meant in technical terms, David was much better at consuming the data and interpreting the output.
What's the moral of this story? I hope it's clear, my customer was not stupid (although he'll be the first to tell you he is), I did not understand the customer environment. I was about to build a product that sucked.
Did I learn my lesson immediately? Of course, not. In my next job I was asked to create a new on-screen graphic for one race car catching up to another car and a calculation of how many laps that would take. I designed something really fancy with the time interval graph and two intersecting lines and where they intersected was the 'catch up' point. In my mind it made perfect sense, but the producer and announcers simply could not grasp the concept. Were they stupid? No, of course not, I just made it too complicated (product sucked) and did not do a good job of explaining what I was trying to do (explain it right). This graphic made air once or twice and was never used again. Weeks of effort wasted and to this day it bothers me that I made that piece of crap.
The "the customer is stupid" attitude is especially pervasive in high-tech engineering. This is, I believe, caused by engineers having a very narrow and deep skillset and, because they were always top of their class, creating the false belief that being an expert in one skill, makes you an expert in every skill. Tying back to earlier articles, this is where you get an expert in Optics making decisions about which connector to select or how to build a mount for the Lidar unit. Or perception experts complaining about their customer not knowing how to use quaternions to calibrate sensors.
99% of customer struggles are not their fault, they're yours. Lose the attitude and learn to understand your customer's environment.
If you hear a peer or employee or subordinate say something like this, please correct them and explain that this kind of talk is not helpful and encourage them to come up with solutions. If you hear your boss say this, maybe it's time to find a different job. If you hear your CEO say this, get out, because the company will fail.
