As a product manager, you are very likely to have more feature requests than what you can put out in a given release. In my case, a good product manager’s job at release planning is figuring out what to eliminate from consideration - you have to make hard decisions - that is what you are paid to do.

Please note that my background is working on products that have mass market appeal and did not have to deal with things like customer funded development - where a customer throws money at you to get a feature that only they will use.

Here are the five guidelines I have used effectively ….

1) How MANY customers will ever USE it?

We held a strong line on this - if the feature was meant just for the selected few (no matter how much money these customers had), we said No to the customer. You may say - no way, it will not work in my case. My reply - have you tried - Have you told your customer No and told him why? - if not try it.

I will give you an example - we had a very well known consumer company in Japan as a customer - they had bought a few licenses but had the promise of buying a whole lot more licenses - they had a lot of money. We visited them in Japan, they visited us here, met with our executives etc. - they tried to push their agenda hard on us and they had all sort of ideas as to how the software needs to work. We questioned them hard to get to the bottom of their underlying problems - why, why, why do you need to do something. They had some great ideas and some that applied only to them - we readily agreed to do the former and rejected the latter with solid business reasons why we won’t do it - not enough customers have the need.

They respected us at the end - their feedback was that we were the first vendor to have grilled them on their requests and were bold enough to turn them down, as opposed to other vendors who were ready to do whatever they wanted. They realized that we were a company that knew what we were doing and our willingness to grill them, told them that we wanted to make sure we were solving their problems the right way.

2) How OFTEN will customers USE it?

Is this something a customer will use once a year, once a month or something they would use everyday. Why does this matter? Remember the phrase “death by thousand cuts” - if something that needs to be used everyday is not supported or is very inefficient to do, it kills user productivity. This may not be something that will make a press release when you launch a new release or in your product demo, but this is something that will get you a standing ovation from your existing customers. Believe me, I have experienced this multiple times where the smallest change scored the highest in customer satisfaction. Stuff such as choosing the right default values, remembering the last used options fall into this category.

Taking how MANY customers would use it and multiplying it by how OFTEN they will use it, you get what I define as Velocity of a new feature.

VELOCITY = How MANY customers will use X How OFTEN they will use

Features with highest velocity should be serious contenders to make into your new release.

3) Will this open up new markets?

It could be something that could be asked by your smallest customer - but it could be this brilliant idea that could change the rules of the game and open up a completely new market for you. You as a product manager need to make this call.

I have been asked in the past if we implemented feature requests only from large customers with lots of licenses - my response always has been - size does not matter, quality of the idea does. This is what product managers get paid to do - take such ideas and make a business out of it.

4) Is this considered table stakes by the market?

There could be features you would need to compete in the market - if you don’t have these basic things, you are not even considered a player. These ones should be obvious if you know your market. For example, pivot tables or charting are considered table stakes for a serious spreadsheet application.

But tread this one with caution - this is where sales can take you for a ride. They will say “we cannot compete because we don’t have this X, Y and Z” and the list could be endless. For those being raised by sales, ask them to put you in touch with customers who would not buy without this feature - then from the customers get to the real problem that is solved by the feature - for all you know, you may have an innovative way to do it, or can come up with one that might change the rules of the game.

5) Is the feature a building block to the real thing?

This could be something determined by R&D (architectural changes) or some other user facing feature that is needed to support the final feature.

If you consistently use these guidelines, you end up making a business case why you want to turn down a feature request - this even works with executives because it is now based on facts and not opinions. After all this, if some higher up overrides your decision, it is not in your hands, but you know you did your analysis.

Have you heard this one before - I have - internal pundits claiming they know what the market wants because at one point in time (read “eons” ago, before your market segment even existed), they used to be in the customer’s shoes.

“Hey, I used to do product design”

or

“I used to be a salesman”

or

“When I used to run YYYY department”

they say ….

I have found a quick counterattack for this -

“Great, when did you do that?”

“In 1997, I used to work at XYZ Co.”

“Hummm, 11 years ago - so you mean to tell me that the world has remained stagnant and nothing has changed in those 11 years - did I hear that right? (OK, not exactly in the words above, but you get the point).

That usually stops this “we have answers here in the building” or “the way I did is how the world works”.

Yes, there are certain product decisions that you have to make drawing on your past experience, but saying that we know what to build because I was a customer once, is nothing but a recipe for failure - especially in the high tech arena, where the way you did it last month is probably not valid anymore.

It amazes me how many companies claim to be customer driven, but then they limit their product managers from traveling because the travel budget is tight, but on the other side the product development budget is a big leaky bucket funding products no one will ever want to buy.

When interviewing customers to determine their needs, take the time to also ask them where they get information that keep them up-to-date in their profession.

1) Are there organizations that they regard in high regard that a recommendation from such organizations is considered valued?
2) What magazines do they read frequently?
3) Do they have a blog?
4) Do they read blogs? Which ones?
5) Do they read or contribute online discussion forums?
6) Are there places which your customer absolutely disrespects or would not want to have any association with?
7) Do they read analyst reports - like Gartner, Yankee Group, IDC etc.

You want to find out where they hang out professionally online and offline. This is because if and when you build a product/service that solves their needs, you want to make sure that the new product/service is promoted well where your potential customers hang out. So, there is more to learn in customer interviews than just the unmet needs - take it as an opportunity to profile your customer very well.

I have been a big proponent of online communities and social media - I have written at least two blog posts on this. So when the latest Business Week arrived with the main section titled “Consumer vigilantes” I could not put it down. The most interesting article among many dealing with social media was titled Love the customers who hate you. This is a must read. The net net of the article is captured in “…… Now don’t get mad at these people. Instead, help them get even with you. These angry customers are doing you a great favor. They care enough about your product or service to tell you exactly what went wrong. Other customers may just desert you and head to the competition. But these are telling you what to fix. Listen to them. Help them. Respond to them. Ask their advice—and they’ll give it to you.” - Enjoy reading.

In my product management career, I have always had some users who were more vociferous than most of the others. Their decibel level when they asked for new enhancements or yelled at you for the bugs in the software was orders of magnitude higher than majority of the users. The vast majority of these users were loud because they cared, they were passionate about your product. Hence, don’t discount these users - listen to them, allow them to vent and take action to fix their problems if appropriate.

However, you as a product manager need to do a fine balancing act you - some of the feature requests from these vociferous users could be for functionality that applies just to them, because of what they use your product for or the unique way in which they do a common task. You have to listen to them, but also be willing to say No with a justifiable reason. All of us ask for more, but not everyone expects to get everything they ask for (if you don’t ask, you don’t get - so there is not much downside to asking). As long as you tell them why you would not do something, they will understand - getting back to them tells them you care.

I remember an instance where I was reading through the enhancement requests we had received when I came across a tirade from a user. It was an email bomb filled with expletives how our product sucked and how he thought we were all a bunch of idiots. I picked up the phone and called the user. I introduced myself and told him that I was calling him about the enhancement request he had send in. First thing he said was a sincere apology for having writing such a tirade (I don’t know if he thought I was going to sue him) and said he was having a bad day and the software was not working the way he wanted to get his job done. I asked him not to be apologetic and asked him to help me understand the deficiency in the software. We spend a good 20 minutes on the phone understanding the issue.

Guess what likely happened after the call - I created a passionate user for our product because I took time to read what he had written (however unpleasant),  call him and discuss the issue to see how we could improve our product so that he can be successful with what he does. Do you think he would have shared this experience with his colleagues or other users in his community? I absolutely think he would have. What happens if he encounters someone else who has a similar gripe - he is going to tell them we care and to talk to us. I created another big proponent who is going to spread the word about our product and about us as a company.

Creating passionate users and listening to them is one of the most important parts of your job as a product manager. After all, the answer is not in the building - it is very important for all of us to get out of our busy schedule of internal meetings and take the time to talk to real users.  After all, they are the ones who buy our product.

Customer visits have always been one of my pet subjects because the only way I have learned to deliver good products is by getting out of the building and talking to real people who buy or will buy my products. At SolidWorks, customer visits was ingrained into our working culture and all of us had an MBO of conducting six customer visits every quarter.

Jeff Lash has written a very good article on his blog titled Avoid excuses for not conducting customer visits. It is definitely worth reading.

I was involved in a conversation last week where we were trying to unearth customer pain points. One of the product managers explained that main pain points were integration and scalability. This is what set me thinking about the difference between pain points and requirements. The  two are not interchangeable - in fact there is a parent child relationship here which if you ignore, you could end up building the wrong or a less preferred product.

Pain points are what customers are going through because they do not have a product that solves their problem. For example, before the advent of wireless devices, a customer pain point could have been that he cannot make a phone call while he was in the car - notice that nowhere in this pain point is wireless mentioned. Putting wireless into this sentence would be jumping to a solution as to how to solve the pain point. It is extremely important that product managers understand the real pain points. Here are some other examples - all cooked up for illustration.

1) I am in sales and I get a lot of customer queries via email. I need to respond to these quickly to close the deals. This is especially true towards the end of the quarter. But given that I am travelling and in meetings at customer sites, I am unable to do this because I cannot get to my email unless I am in the office and this costs me time and money. For example, in one instance last quarter I missed closing a deal worth $1M by one day. (I guess RIM probably heard this a whole lot and came up with the Blackberry - but do you see anything about a Blackberry or a mobile device in the customer’s description of his/her pain point? - does it say anything related to integration or scalability or ease of deployment in the description?)

2) I usually get out of the office after the banks have closed. Hence I am unable to get to the bank before they close to withdraw money from my account. Hence I have to remember to withdraw money on Saturday mornings, enough to last me one week. I feel uncomfortable carrying all that money around where ever I go.  BTW, this is still true in a lots of places in India (what do you think could solve this? I can think of two - ATMs, credit cards)

3) I end up paying a lot of late fees because I forget to mail my payments on time or because the postal service takes more time to delivery my check to the credit card company. For example, last month I ended up paying $58 in late fees. It is hard to predict when exactly to mail the payment. I cannot afford to send the money way ahead of time because I have to wait for paychecks to get deposited (Could very well have been one of the pain points that created online banking)

You get the idea. It is very easy to fall into the trap of starting to describe product requirements and not pain points. It is not easy to do tjos because the creative part of our brains loves to start thinking about how to solve the problem. But take control - make sure that you understand the pain points very clearly before you start listing requirements or evaluating product ideas.

Here is a great video that I came across produced by Geert Desager of Microsoft - watch for yourself, it is fun !!

This morning, while walking through Terminal 3 of the San Francisco airport to get to my gate, I happened to notice the design museum display near the moving walkways. The museum is titled “From Prototype to Product: Thirty-three Projects from the Bay Area Design Community“.Behind each display, were quotes of some famous people.

One of them caught my eye - it said ““The ability to simplify means to eliminate the unnecessary so that the necessary may speak”. After getting home, I googled it to find that it is a quote by Hans Hofmann. The reason I find this quote very interesting is because it captures what good product design is all about. Designing a good product involves spending more time deciding what features NOT to include than deciding what features to include. I would bet that designers of iPod had all the pressures to add a zillion features to it - an AM/FM radio station, ability to add/edit/delete songs etc. But they did not - because adding all of these features would have destroyed the elegant design. The end product does not do everything, but what it does it does very elegantly. To this day, I would be willing to pay more for a remote control that would do the five things I want to do - play, stop, forward, rewind, power on/off, instead of the other 500 features it has making it impossible to find these features. The office phone is another example. Try doing a conference call.

To do this right, you need to understand who your target user is and then saying no to features that are not needed by target users. You cannot listen to sales, they will tell you that you need everything under the sun. You cannot listen to just your existing customers, they will ask you for more and more features. What you need to do is get out and talk to real people who want to use your product - especially people who have not yet bought your product. Observe them struggle using the current products (your products or competitors) and then figure out what you can do to simplify their lives. It is not easy, but good things never come easy.

Unless your product is used only in the US, you as a product manager should make sure that you are listening to the “global” voice of the customer. Customers in other countries typically have vastly different needs than customers in the US. Localization of your product is something you should account for in the very first release if you know that your product will be sold in non-English speaking countries. Even if your first release product launch plan is limited to the US market, you should make sure that R&D accounts for localization such that when you do decide to sell in the non- English speaking world, you will not have to rearchitect your product. Localization is not cheap, nor is it easy to implement as an afterthought.

You as a product manager should also plan on visiting these customers to understand their requirements before you build the product. Even users in the English speaking world have different needs - assuming that customers in the UK have the same needs as those in the US would be making an assumption to your own detriment. One way to figure out who or how often to visit non-US customers is to look at the percentage of established customer base (or potential market for new products) in the major geographic market segments. Thus, if 45% of your revenue comes from the North American market, 30% from Europe, 10% from South America, 10% from Japan then you should plan on visiting customers (prospects) in these countries using the same ratio. You should then use market segmentation based on verticals to figure out which specific customers to visit.

In my experience, on-site customer visits in countries outside of US/Canada are best arranged through your local rep. This will help you overcome the language barrier and also driving in these countries. This will also help you establish a better rapport and expectations with the aid of the local rep who is more in tune with the local culture.

In certain countries like Japan, it is difficult (if not impossible) to have high level discussions on the customer’s goals and tasks. Often, you meet with folks in the trenches who use your product everyday as opposed to management folks and hence your discussions usually revolve around a laundry list of specific enhancement requests. You should try nevertheless to set expectations and send them a discussion guide long before the meeting so that they know how you would like to structure the meeting. Here is where the local reps can really help overcome the language barrier. After all, whatever you want to send to the customer will need to be translated before it can be send.

Listening to the “global” voice of the customer is not easy and not cheap. But it is something you cannot afford to neglect if your product is sold internationally. With some careful planning, it can be done. If you are going to do this for the first time, make sure you budget enough time, money and resources for couple of “learning trips” before you can fine tune to get the most out of these international visits.

“Innovation”, “product innovation” are being used by everyone these days. A google search on “product innovation” returns 169 million results. A search for books on product innovation on Amazon returns over 10,800 books. Sure enough it is one of the most frequently used business buzzword these days. We all have heard phrases like “Innovate or die” - so what exactly is product innovation.

My colleague Rick Chin, Director of Product Innovation and Marketing at SolidWorks (yes, even people’s titles have product innovation in them these days :-)) came up with six criteria (at least one of which has to be satisfied) that can be used as a lens to evaluate possible solutions before they can be considered a product innovation.  According to Rick, these criteria work best when you have a lot of ideas to solve a problem.

Customers will call something innovative if:

1)  If it solves a problem that really matters - Look for a really strong emotion from the customers like frustration.

2) The solution is truly effective - not just effective, but very effective in solving the customer need.

3) Its effectiveness is instantly obvious - this is when customers say “Wow” when they see the product in use for the first time.

4) It is familiar, comfortable, easy to adopt - if the product intimidates, it will not be used.

5) It’s realistic to implement - this sounds obvious, but consider this before starting to implement the solution.

6) It is an unexpected solution - this is what people normally call innovation and the least important on the list.

1.

After 11 fun years at SolidWorks, I am leaving to pursue a new career opportunity. I consider myself lucky to have worked at such an awesome company during a time when it grew from a startup to a force in the CAD industry. In 1996, it was the second job of my fledgling career and I don’t think I could have done it any better. I learned so much during these 11 years, got to contribute to a product used by hundreds of thousands of product designers, worked with some of the smartest people I have met and made so many friends over the years amongst my colleagues and customers alike.

Now it is time to move on and do the next big thing in my career. It is hard to leave a place where I knew so many people who shared the good and bad times during the different business cycles. But I believe that I will never know what I will find next unless I try. It could be the next big success or failure, but the learning cannot continue unless I try. I wish all my colleagues the very best in personal and business success for years to come.

I thought this would be a great opportunity to list the top 11 things that I learned at SolidWorks (yes, there is a lot more than 11) in the last 11 years that will guide me for the rest of my working life.

1. Hiring is the most important thing you do at work and always hire people smarter than you: Team success is what will determine your business success, so why not have people smarter than you working for/with you? If you have to micromanage someone or babysit them to do the tasks, why hire them? Hire slowly and make sure you have done due diligence.

2. A manager’s success is all about making his/her reports successful in what they do: Once you are a manager, it is not about “you” anymore. It is all about your team. Your job is to ensure that you are making your reports successful in their job. You have to ensure that their strengths are fully utilized. You will be judged by your team’s success.

3. You cannot move up in the company unless you train your replacement: You have to make sure that you are dispensable by training your replacement. Otherwise, you cannot move up and take up another position within the company. Pay attention when you are hiring – can your new hire replace you one day? Thanks to Aaron Kelly for teaching me this. I would not have made my move from Product Definition to Strategic Marketing without Bruce Holway.

4. It is all about “relationships” and not “products”: This is true whether it is with customers, colleagues, partners and resellers. When someone buys from you or when your colleagues work with you, you are winning their trust and they are making an investment in you. Trust once broken, cannot be repaired. Relationships you build will outlive any technology or product. In other words, it is all about “people” and not “products”.

5. Only viewpoint that matters is that of the customer: The answer is not in the building. You have to get out and talk to real customers and understand their “pain points”. In fact, none of the people in the building will buy your product, only your customers do. So take the time to figure out what your customers need and then solve their pain points with a kick ass solution. Worry about the competition, but worry more about what customers need. Respect the customer.

6. There is a big difference between products that customers will “buy” vs. products customers “like”: You should only be solving problems that customers are willing to pay money for (in some cases, you make money via the network effect that is generated by solving problems – eDrawings, 3D ContentCentral are prime examples). After all, business needs to make money to stay around (there are no two ways about it !). It does not make business sense to solve problems customers don’t care about. Never get enamored with technology and then start looking for problems that the technology can solve. Do it the other way. Find the real customer problems and then find the best technology to solve these problems and then make money out of it.

7. Be “market driven” and not be “marketing driven”. There is a big difference: Never thought how big a difference adding “ing” to a word could make.

8. Have technical and business arguments with colleagues as long as none of it turns personal: Make sure that all perspectives are considered when devising the best possible solution for a customer’s problem. Have heated technical/business debates if you want, but never ever make any of these arguments/disagreements personal. When you have these disagreements and then make a decision, you at least know that you have considered all possible solutions and picked the one that is the best. After all, the customer does not care whose idea it was, to them the idea came from SolidWorks. Either all of us are going to look like heroes or a bunch of idiots. Which would you rather be?

9. Have meetings before the meeting: If you are asked to present to a large group of people meet with the key stakeholders one on one before your big meeting. You do not want to get ambushed because you did not do due diligence on the material you are presenting. Meet with them one on one before hand and make sure to get their feedback on your thinking and ask specifically for any concerns they may have. You would then have time to do more research to address those concerns or list them as risks. If you do this right, the final meeting should be one of consensus and no “surprises”.

10. Trying and failing is a lot better than failing to try: All successful people have failed more than they have succeeded. No one writes about their failures. Failing to try is trying to fail. Never forget the lessons you learn from these failures. There is no better learning method than trying and failing, but never fail the same way twice. I have to thank SolidWorks for all the wonderful opportunities over the last 11 years to try new things and having the luxury to fail and learn from these failures.

11. Execution is the key to being successful: History is filled with people/companies who had great ideas and got nowhere because they did not execute. Devil is in the details. Many times, flawless execution can compensate for any flaws in the idea as long as you quickly iterate and continue to execute. Execution is the key.

You have decided to get out of your office and embark on the journey of discovering unmet needs of customers by talking to customers and listening to them express their unmet needs. One of the pitfalls to avoid is talking to the same customers - customers that you know very well, those that that love your product - and then claiming that you have gone through the motions of talking to customers. If you do this, you will end up making a product that meets the needs of the few.

You have to keep rotating the customers you talk to. You cannot be talking to the same customers over and over again. Find customers you have never visited, new customers who have just bought your product, or customers who have been using your product for a long time. You should be prepared to listen to customer who may not have all good things to say about your product. In fact bad news is the best good news you could get from a customer visit, because they are actionable pieces of information you could take back and get fixed. But, bear in mind that just because one or two customers told you that they liked something or absolutely hate something in your product, it does not mean that the whole world shares that opinion.

What has worked me in the past is making customer visits something I do all the time throughout the year. I try to be out of the building one day a month visiting two customers during that day. Make it part of your working culture. If you are going somewhere attending a conference or on a pre-sales call or to visit some particular customer, try to find other customers in the area that you have never visited and extend your stay by a day and visit them. This lets you justify the travel expense you would have incurred anyways.

Good sources for names of customers you could possibly visit include:

1. Your tech support
2. Enhancements database (if you have one)
3. Your sales organization
4. Existing customers (they always know someone else that you could visit in their area)
5. Prospects database

Figure out your objectives of doing the customer visits (what are you trying to accomplish) and then try to figure out who you need to talk to. Then make sure more than 50% of those you would talk to would be first time customers who you never talked and listened to.

I have found this picture to be very hilarious and after having talked to different people working in different companies, I am led to believe this is very true in a lot of companies. (I give the credit to the original creator of this picture whose name is unknown to me)

To avoid the above situation, in my opinion a product manager has to do three fundamental things:

1) Thoroughly understand the customer problem, rather than taking what the customer tells you at face value. Need to do a deep dive with the customer using the concept of Five why’s. While doing this, you need to make sure you need to involve your engineers/qa etc. or take the time to educate them about the customer problem that needs to be solved.

2) Engage the customer throughout the product development process to ensure that you are building what he is really looking for. My mantra is that it is never too early to show anything to your customers. Sign NDA’s if you have to, but engage them early. Get them to review specs, let them play with early code. The whole idea is to know if you are building the right thing, that you are rowing the boat in the right direction. The boat could be leaking water at this time because it is not finished, but you want to make sure that you are building the right boat and rowing it in the right direction.

3) Educate other departments in your company about the customer problem and why you are creating this product/service so that they can align their tasks with what you are trying to do.

How many times have you read marketing brochures, datasheets etc. shook your head and really wondered what the product that is being described is meant to do? Marketing collateral is full of “flexible, scalable, reliable, robust, next generation, empowering, state of the art, ….” - you get the idea. I have always wondered if the folks who write such stuff understand it themselves let alone their customers.

One of the key things to do while listening to customers is making note of words, phrases they use - the vocabulary they use to describe things. If you don’t understand these terms, ask them to explain. Once you start seeing a trend of what words are commonly used, incorporate these terms in your product UI, documentation, in your presentations, in your marketing materials and so on. Communicating to your customers using terms they are familiar with helps you to immediately connect with them. Companies that do this will be able to differentiate themselves (agreed that this is not going to compensate for an inferior product). It is amazing to me how the vast majority of these companies don’t do this. Communicating benefits of your products to your audience is going to be so much simpler if you pay attention to the user vocabulary. It is such common sense to me to do this, but hey who is it that said that common sense is not that common.

Customers are wishing someone would listen to their needs and concerns, as opposed to talking to them. You sales people, your marketing people, your competitors and everyone else is talking to them about the products they should buy. But companies that are successful listen and observe their customers. So before you call or visit the next customer, commit to listening. I sometimes write “Don’t talk” as a reminder on my note pad so that I constantly remind myself to shut up and listen. After all, we have two ears and one tongue, but unfortunately the latter gets used a whole lot.

There are couple of active listening techniques I use all the time:

1) Paraphrasing - After the customer has told you something, repeat back to the customer what he just told you in your own words. This serves two purposes - tells the customer you were listening and also makes sure that you did get the essence of what the customer told you

2) Followup questions - Ask follow up questions based on what the customer told you. This again reinforces to the customer that you indeed were listening and interested in knowing more about what he just said.

Remember that if you indeed listen to the customer, you will also be building trust and rapport with the customer. Not many people do this and hence you will be the one the customer remembers. After all, it is all about people relationships and not about products. Happy listening !!

It is very typical while talking to customers that they ask you for a very specific enhancement. As a product manager, you should make sure you do not fall into this trap of accepting that the solution proposed by the customer is what they want. Customers are good at what they do, but cannot be considered as the best people to design your product. As a product manager, it is your job to do a deep dive and find the real pain point for which the customer has proposed the said solution.

This is where the concept of Five why’s come in. I believe this concept has its roots in the six sigma philosophy (though I am sure about this). Nevertheless, the trick is to ask the customer why he is proposing a solution. Keep asking why’s until you really arrive at the root of the problem. It is not necessary that you may have to ask five why’s or that you have to stop at five, but the idea is to make sure that you keep probing until you fully understand the customer’s real problem that needs to be solved. Some simple examples on 5 why’s can be found on the isixsigma site.

Before you do this, I have found that it is important that you let the customer at the start of your interview that you would be asking some basic questions (or the why’s) during the interview. Let them know that this is only to make sure that you fully understand their problem. The last thing you want the customer to think is that you are questioning his/her judgement or that you getting defensive based on their input. So I always make it a point to tell this to the customer right at the outset (lay the ground rules first to make sure everyone is on the same page).

Once you truly understand the problem, you can engage the smart people in your development team to come up with the best possible solution to solve the problem. Be ready to be surprised that in some cases, the solution proposed by the customer has nothing to do with the real problem. In fact, in some cases it may even make the customer’s problem worse. You are the expert in your product and it is up to you to figure out how to solve the customer’s problems in the best way.

As a product manager, you could be asked to visit customers to help close a sales deal or to trouble shoot a customer problem along with a technical support person. None of these visits can be considered as part of your effort to listen to the voice of the customer. This is because in either of these cases, you role is to overcome the customer’s objections to close the deal or to find workarounds to the problem faced by the customer. In both of these cases, you are not listening to the unmet need of the customer, you are trying to sell or get your product to work. You are the one who is doing the talking.

When you visit customers to listen to their voice, you should be listening and not talking. Human beings cannot do both of this at the same time (sales people may think otherwise !). When you are visiting customers to listen to them, your role is that of an explorer. You have to keep your eyes and ears open. Customers do not always tell you the whole story, not because they are withholding information, but in many cases sometimes they themselves do not recognize the pain points they have. It is up to you as an explorer, to ask the right questions and to get the customer to tell you their real problems (not solutions) that if solved would create a product differentiation for your product.

Whenever you start talking to users whether it is face-to-face or over the phone, first of all make them feel at ease. Users tend to be a) skeptical whether vendors trying to sell them something int the guise of a conversation and b) fearful of exposing their ignorance of the product you are talking to them about (you hear them say”may be I am doing something wrong” or “I am sure I am doing something it was not designed to do” and so on).

To make users feel at ease, do the following things at the start of the conversation

1) Tell them that you are not a sales person (ie. if you are not) and that you are not trying to sell them anything. You are trying to get their honest feedback about your products so that you can make it work better for them.

2) Tell them that you want to hear both the good and the bad news about the product. Hence, tell the customer not to sugar coat anything. You are not here to defend anything about your product but to make sure that you get honest feedback from them about your product. However, make sure that if the customer blames your company for some issue that is not under your control, do not ratify (you are hearing only one side of the issue), but acknowledge that you have noted down the issue and you will make sure it is brought to the attention of the right people in your company who can resolve the issue to the customer’s satisfaction.

3) Once the stage is set, start with some softball questions. Not everyone likes to talk especially about your product. So ask them to talk about what they know best - their business and their products. This prevents them from starting the discussion with a laundry list of enhancements, but at a much higher level. After all they are ONLY using their product to get better at their business. Hence this helps you to understand their business processes, how your product fits into their processes and then allows you to slowly move the conversation towards pain points, unmet needs and then gradually bringing the focus to your products.

I have used this technique over the last several years and I have found that it works very well to build the rapport with the customer.

I have been working with customers for the last 11 years in determining their unmet needs and then creating products/solutions to solve those unmet needs. Over these years, I have learnt a lot about how to do these customer interactions while I have made several mistakes. I have decided to share these tips via my blog by writing on one tip per day over the next several days.