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 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.
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.