Your Customers Do Not Mean What They Say

Your Customers Do Not Mean What They Say

Nate Jackson

I’VE NEVER MET A CUSTOMER YET that wasn’t all too happy to tell me what they wanted—usually in great detail. The problem is that customers don’t always tell you the whole truth. They generally don’t lie, but they speak in customer speak, not developer speak. They use their terms and their contexts. They leave out significant details. They make assumptions that you’ve been at their company for 20 years, just like they have. This is compounded by the fact that many customers don’t actually know what they want in the first place! Some may have a grasp of the “big picture,” but they are rarely able to com- municate the details of their vision effectively. Others might be a little lighter on the complete vision, but they know what they don’t want. So, how can you possibly deliver a software project to someone who isn’t telling you the whole truth about what they want?

It’s fairly simple. Just interact with them more.
Challenge your customers early, and challenge them often. Don’t simply restate what they told you they wanted in their words. Remember: they didn’t mean what they told you. I often implement this advice by swapping out the cus- tomer’s words in conversation with them and judging their reaction. You’d be amazed how many times the term customer has a completely different mean- ing from the term client. Yet the guy telling you what he wants in his software project will use the terms interchangeably and expect you to keep track as to which one he’s talking about. You’ll get confused, and the software you write will suffer.
Discuss topics numerous times with your customers before you decide that you understand what they need. Try restating the problem two or three times
194 97 Things Every Programmer Should Know

with them. Talk to them about the things that happen just before or just after the topic you’re talking about to get better context. If at all possible, have mul- tiple people tell you about the same topic in separate conversations. They will almost always tell you different stories, which will uncover separate yet related facts. Two people telling you about the same topic will often contradict each other. Your best chance for success is to hash out the differences before you start your ultra-complex software crafting.
Use visual aids in your conversations. This could be as simple as using a white- board in a meeting, as easy as creating a visual mockup early in the design phase, or as complex as crafting a functional prototype. It is generally known that using visual aids during a conversation helps lengthen our attention span and increases the retention rate of the information. Take advantage of this fact and set your project up for success.
In a past life, I was a “multimedia programmer” on a team that produced glitzy projects. A client of ours described her thoughts on the look and feel of the project in great detail. The general color scheme discussed in the design meet- ings indicated a black background for the presentation. We thought we had it nailed. Teams of graphic designers began churning out hundreds of layered graphics files. Loads of time was spent molding the end product. On the day we showed the client the fruits of our labor, we got some startling news. When she saw the product, her exact words about the background color were, “When I said black, I meant white.” So, you see, it is never as clear as black and white.