William Perry explains why software development teams must identify as many customers for a planned product as possible, as well as the type of information they need from each customer, in order to build a successful product.

This chapter is from the book

This chapter is from the book

A person cannot listen to the voice of the customer until he or she knows who the customer is. A developer, when conceiving of a complex product, probably cannot visualize the full spate of potential customers or even whether satisfying their requirements is more important than satisfying those of organizational management. Many teams become hamstrung trying to please too many parties or failing to recognize which party would be essential to please.

Take, for example, the true story of an insurance company’s IT group, mandated to build an information system for use by independent insurance agents. The IT project team assumed that a “department” within an insurance company was its customer. Therefore, team members interacted with this department, gathered specifications for the software from it, and built the system according to its specs. When the system was operational, the independent insurance agents were aghast. The system was not agent-friendly to independents spread across the globe, did not do what they needed, and was unresponsive to the requests of individual agents, making it difficult for them to close sales with their customers. If the IT project team had recognized that independent agents spread across the globe were the customers, not a single-site department, it would have built an entirely different system.

A mistake organizations make over and over is building a product the customer doesn’t want. Bankruptcies flourish because organizations think that if they build a “better” product, customers will flock to buy it. Very often, exactly the opposite happens. One only needs to skim a hundred-page-plus cell-phone manual to know that manufacturers incorporate many more features in their products than a customer will ever use. Teams need to know who their customers are, and then they need to listen to them.

Putting the “I” into Listening to the Voice of the Customer

For the “I” in this challenge, we need only look to individual software users. I remember attending a conference at which fellow IT professionals almost unanimously agreed that software users—not analysts or developers—were responsible for their own dissatisfaction with software products. In truth, many systems analysts believe they know better what users need than do users themselves.

The trick is to identify the true customer among many potential customers for products and services recommended by development teams. There are different types of customers, with different needs. Teams need to hear the various voices and then make decisions about what will provide the greatest satisfaction to most customers.

Teams cannot always meet with every potential customer. Listening to the voice of the customer means that individual team members need to gather requirements from many different customers. In the independent-insurance-agent fiasco, IT learned the hard lesson that it needed to differentiate between the internal customer, the external customer, and the distant customer.

Teams must identify as many customers for a planned product as possible, as well as the type of information they need from each customer. For example, if an external agent in the insurance-software scenario requested a specific function, the development team would need to identify who would pay for that functionality. Keeping such a request in mind, team members then can decide who on the team is best qualified to listen to that customer’s voice, and report information back for team discussion.