When I have done customer interviews to better understand customer pain points and ways to enhance the product, often times I have been asked one of two questions:
- Are you really interested in solving this or listening to my problem? I only have 2 licenses of your software. Don’t you only listen to customers who have 50 licenses or more?
- But this is a simple issue, will this ever make it into your list of things to improve on?
I remember giving the same answer each time for question 1) – my job as a product manager is not to worry about how many licenses
(“size”) you have, but to understand your pain point and then extrapolate to see how many other customers will benefit from solving the problem (“frequency”). Innovative ideas typically come from one individual (think about all the great inventors – many of them invented things in their basements individually) and not from organizations. So before you ignore your small customers, think twice. Instead worry more about the “frequency” of the issue.
The second concern has some validity. Companies under the false pretext of being innovative are looking for problems that are big news – the one that will make a splash. Agreed! Product managers should always look for differentiated ways to solve “common” problems to stay ahead of the competition. But this should not be at the cost of ignoring simple issues with your current product. Here is a simple formula I have used to prioritize all of the issues.
Determine:
- How many times a typical user encounters the said issue? (Once a day? many times a day? once a week, once a month, once a year etc.) = A
- How much time in minutes do they waste each time they encounter this issue to find a workaround? = B
- How many users will encounter the same issue? = C
Importance of the issue (priority) = A x B x C
For example, if the user encounters an issue with every 3rd mouse click (because of the delay the software responds to the click) and if a large number of users encounter it, it will be amplified a whole lot even if the delay is only a few milli seconds. Compare that to an issue which occurs once a year for a very few users. It maybe something you could easily de-prioritize because it could very well be a niche problem.
Don’t get me wrong, lot of emotions do get involved in whose issues get fixed – one with executive mandate, one from a vociferous customer, one for the customer that will make a huge purchase etc. But as a product manager having the above data will help you justify the prioritization you are making and then if someone wants to override your decision for valid/invalid reasons, that is perfectly fine. At least you should be able to sleep in peace that you did your homework.
Thoughts? Do you agree? How do you do prioritization?
If you read this post, please consider leaving a comment, share this blog with your friends and colleagues or subscribe to the feed to receive future articles delivered to your feed reader or via email (use the text box at the top of the right column)
Image: Courtesy of fiscalgeek.com
Software Product Manager by Gopal Shenoy 
Very interesting – thanks a lot. I think the small features are very important for long term sustainability. If there are only big/splash features at every roll-out but the smaller inconsistencies that pain the customer every day , it’is risky in the long run. Two ways I think to best integrate these smaller improvements /additions, either on a continual basis drop by drop (always plan them in eveb if the final candidate is not yet chosen) or bundle them with a not so big/splash feature release (i.e. once a year)
This is a good article Gopinath. I agree, that most of the times, we as product managers, look for biggies and ignore the small, but painful dots.
Thanks Gopal, and I agree to Gopinath as well. Tech support are really the folks who understand the customer pain with regards to usability and sometimes performance. That may not necessarily be a bug, or a missing feature. Moreover, this formula is suited once the product has been established in the market. Until then, I would prefer prioritizing things that make the product breadth intuitive, and features that resolve unknowns.
Apart from talking directly to customers, I feel that product managers should work closely with the company’s support team (the team that directly handles customer support calls) to identify customers pain points. As an example: If a lot of customers are asking for clarification on a particular feature, the PM should look into in and make the feature more intuitive.
Just my two cents…