Sharing The Customer's Pain

In this interview with Werner Vogels, the CTO of Amazon, he outlines how Amazon's developers stay in touch with their users:

Remember that most of our developers are in the loop with customers, so they have a rather good understanding about what our customers like, what they do not like, and what is still missing.

We have a lot of feedback coming out of customer service. Many Amazonians have to spend some time with customer service every two years, actually listening to customer service calls, answering customer service e-mails, really understanding the impact of the kinds of things they do as technologists. This is extremely useful, because they begin to understand that our user base is not necessarily the techno-literate engineer. Rather, you may get a call from a grandma in front of a computer in a library who says she wants to buy something for her grandson who is at college and who has a Wishlist on Amazon.

Customer service statistics are also an early indicator if we are doing something wrong, or what the real pain points are for our customers. Sometimes in meetings we use a "voice of the customer," which is a realistic story from a customer about some specific part of the Amazon experience. This helps managers and engineers to connect with the fact that we build many of these technologies for real people.

It's easy to fall into a pattern of ivory tower software development. All too often, software developers are merely tourists in their own codebase. Sure, they write the code, but they don't use it on a regular basis like their customers do. They will visit from time to time, but they lack the perspective and understanding of users who -- either by choice or by corporate mandate-- live in that software as a part of their daily routine. As a result, problems and concerns are hard to communicate. They arrive as dimly heard messages from a faraway land.

When was the last time you even met a customer, much less tried to talk to them about a problem they're having with your website or software?

It's incredibly important for developers to be in the trenches with the customers-- the people who have to live with their code. Without a basic understanding of your users and customers, it's impossible to build considerate software. And nothing builds perspective like being on the front lines of support. I'm not proposing that all programmers pull double duty as support. It'd be impossible to get any work done. But a brief rotation through support would do wonders for the resulting quality and usability of your software, exactly as described by Mr. Vogels.

Dogfooding can be difficult. But manning the support desk, if only for a short while, isn't. Software developers should share the customer's pain. I know it's not glamorous. But until you've demonstrated a willingness to help the customers using the software you've built-- and more importantly, learn why they need help-- you haven't truly finished building that software.