In conversations you have with your customers as a product manager, you will find that your customers often tell you to build certain features that would help solve their problems. Should you then just note down all these requests and work on them? How do you know which problem is actually worth solving? And which problems should you ignore? If you spend your time and effort in building a feature that doesn’t tackle the right problems, you’re likely jeopardizing the future of your product.
Any feature you build for your customers should have a tangible benefit for them in the form of money saved or money earned etc., or an intangible benefit in the form of time saved, better experience for their users etc. If your feature does not have such benefits, is it even worth spending months on building that feature? How do you validate that a problem is actually a problem before you decide to build a feature that tackles it?
Before I continue, please note that, by no means am I suggesting that customers actively want to misguide you. However, we have many cognitive biases that influence how we think. A product manager needs to identify and isolate these biases so that they can then infer which problem is actually critical and merits time and effort.
At WebEngage, I tend to get a lot of problem statements and specific feature requests from customers. These inputs could be very specific suggestions on a list of features we should add to the product or they could be vague problem statements that describe the business problem the customer is facing. As a product manager, it is my responsibility to understand and validate the problems being reported. The process of validating problems will ensure that we only work on those problems that are genuine and critical to our customers. In order to do so, I tend to ask customers a specific set of questions to validate these feature requests. Once I’ve validated that the problem is indeed critical, it then gets added to our product roadmap and will then get implemented sooner or later.
Here is the set of questions I ask our customers to validate the problem:
Question 1: What is the use case?
Each time a customer requests for a particular feature, my immediate response is to ask them to describe the use case. As a customer describes the use case in detail, I am able to understand their problem and empathize with them. This process also helps me understand how our customers would be able to solve the problem through the proposed feature. If a customer is not able to articulate the use case or the problem, I would discard the feature request almost immediately.
Question 2: How often do you face the problem?
A customer might describe the problem to me in great detail. They might even tell me how critical the problem is to their business. I’ve found that a good follow up question then is to ask them the frequency at which they face this problem. Critical problems tend to crop up often. If the problem is infrequent, perhaps the customer is getting biased based on the recency of the problem. Maybe they faced the problem earlier in the day and in their discussion with you, they end up describing this problem to you. If you build a feature to address this problem, you might discover later that the feature hardly has any usage.
Question 3: When did you last face the problem?
Alright….someone’s telling you that they face the problem quite often. A good question then to determine the frequency of the problem is to understand its recency. Can they recall the last time they faced the problem? If the customer is not able to clearly recall the last time they faced the problem, you might want to dig in more to understand why that is so. Is the customer’s definition of frequency once a month, once a week or perhaps once in a few weeks or once in a few months? Maybe the problem is regular but it happens only once a few weeks. If that is the case, you should ask the customer the next two questions to determine the criticality of the problem before you decide to add this request to your product roadmap.
Question 4: How much time & money does the problem cost your business?
Does the problem have a significant impact on the customer’s business? Is the customer able to measure the time and money that the problem costs their business? If the costs are not significant, then any feature you build to alleviate this problem will not have any tangible or intangible benefits for the customer. The problem is just not significant enough for the customer.
Question 5: How do you solve the problem right now? What issues do you have with your current solution?
If a problem is regular, recent and has a significant impact on the business, surely the customer would have tried to solve it in some way, however rudimentary the solution. A solution should ideally exist. If a solution doesn’t already exist, I would ask myself if the problem is even worth solving. Secondly, if a solution does exist, then what are the issues that the customer faces with the current solution? If a customer is not able to articulate these issues, then maybe it isn’t as critical as it is being made out to be.
Through these set of five questions, I’m able to focus on the right set of problems and features we should build in our product. Once the problem or the feature is validated and listed on the product roadmap, we go through a prioritization exercise where we estimate the urgency of the feature, the impact that the feature will have and the efforts required to build this feature. Based on the combined score of these three parameters, the feature then gets picked up execution at the right time. You can read more on how I go about prioritizing features and building a product roadmap here.
