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 software 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.
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.
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:
- Your tech support
- Enhancements database (if you have one)
- Your sales organization
- Existing customers (they always know someone else that you could visit in their area)
- 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.