Prioritize based on frequency, not size ….
April 10, 2011 4 Comments
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.
- 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