Learning to Listen
Customers often do not say what they mean. A product manager's success depends on the ability to understand what customers really mean, and it's sometimes very different from what they're saying.
Case in point: Microsoft customers frequently asked for easier ways to access and edit their Word documents, requesting numerous new Word features. Word was (and still is) a pretty complicated word processor, and overlaying a new set of features would have made it more so. But when product planners at Microsoft began to understand the actual problems that the customers were facing, it became clear that the solution wasn't at all what the customer were requesting. Instead, a new application tailored for quickly taking notes and organizing them was born: OneNote. It's been a big success among the customers who thought they wanted more Word features.
I learned how to listen to customers while validating a product concept in meetings with groups of customers at 28 companies, which we visited over a 6 week period. We gathered an enormous amount of valuable information. But the good stuff was rarely the first thing the customer offered.
The customers, including both users and administrators, were asked to describe their work, their tools, and their challenges. People can be very articulate about these, particularly in a discussion with their peers. But they are also quick to point out the solution to their problems. They want to be helpful, they want to show how smart they are, and they really want that cool feature they thought up. This is where the danger lies.
If you go back and design a product based on their solutions and wishlists, you may end up with a camel when you really needed a cheetah. The problem is that customers usually go straight to a solution without understanding the problem, and how it relates to other problems. Sometimes they are totally unaware of related-but-different problems that other customers have. And their suggestions are usually based on their experience of existing products and technologies, rather than the kind of inventions that a good product team can develop to solve a problem.
In our 28-company tour, the most useful information came after we asked "why do you do this the way you do," and "tell us about the problem you're having." Then, in almost every case , it was our follow-up questions that elicited the most useful information. Few of these follow-ups could have been scripted in advance. We were able to ask them because we worked very, very hard at listening.
Listening involves more than paying attention. It means putting yourself in the customer's shoes as they describe their problems, feeling their pain, and continuing to dig deeper. It also means analyzing what someone has said - sometimes we would diagram a process on the whiteboard to make sure we understood what the customer was describing. We highlighted the problem areas, and asked them to explain them in more detail Later, we would discuss the findings with the product team, and follow up with the customer: In many cases, it was a follow-up email or phone call that resulted in a breakthrough in understanding a customer problem.
When were finally were able to understand what the customers actually meant, it enabled us to design a really innovative product. In most cases, the customers were surprised and delighted at the solutions that we had designed.
No one ever questioned whether the time we put into listening was worthwhile - it was obviously priceless.
Case in point: Microsoft customers frequently asked for easier ways to access and edit their Word documents, requesting numerous new Word features. Word was (and still is) a pretty complicated word processor, and overlaying a new set of features would have made it more so. But when product planners at Microsoft began to understand the actual problems that the customers were facing, it became clear that the solution wasn't at all what the customer were requesting. Instead, a new application tailored for quickly taking notes and organizing them was born: OneNote. It's been a big success among the customers who thought they wanted more Word features.
I learned how to listen to customers while validating a product concept in meetings with groups of customers at 28 companies, which we visited over a 6 week period. We gathered an enormous amount of valuable information. But the good stuff was rarely the first thing the customer offered.
The customers, including both users and administrators, were asked to describe their work, their tools, and their challenges. People can be very articulate about these, particularly in a discussion with their peers. But they are also quick to point out the solution to their problems. They want to be helpful, they want to show how smart they are, and they really want that cool feature they thought up. This is where the danger lies.
If you go back and design a product based on their solutions and wishlists, you may end up with a camel when you really needed a cheetah. The problem is that customers usually go straight to a solution without understanding the problem, and how it relates to other problems. Sometimes they are totally unaware of related-but-different problems that other customers have. And their suggestions are usually based on their experience of existing products and technologies, rather than the kind of inventions that a good product team can develop to solve a problem.
In our 28-company tour, the most useful information came after we asked "why do you do this the way you do," and "tell us about the problem you're having." Then, in almost every case , it was our follow-up questions that elicited the most useful information. Few of these follow-ups could have been scripted in advance. We were able to ask them because we worked very, very hard at listening.
Listening involves more than paying attention. It means putting yourself in the customer's shoes as they describe their problems, feeling their pain, and continuing to dig deeper. It also means analyzing what someone has said - sometimes we would diagram a process on the whiteboard to make sure we understood what the customer was describing. We highlighted the problem areas, and asked them to explain them in more detail Later, we would discuss the findings with the product team, and follow up with the customer: In many cases, it was a follow-up email or phone call that resulted in a breakthrough in understanding a customer problem.
When were finally were able to understand what the customers actually meant, it enabled us to design a really innovative product. In most cases, the customers were surprised and delighted at the solutions that we had designed.
No one ever questioned whether the time we put into listening was worthwhile - it was obviously priceless.