Finding the Right Problems for a Product Manager to solve
“Choose your battles wisely. After all, life isn’t measured by how many times you stood up to fight. It’s not winning battles that makes you happy, but it’s how many times you turned away and chose to look into a better direction. Life is too short to spend it on warring. Fight only the most, most, most important ones, let the rest go.”
― C. JoyBell C.
Whenever a new PM joins a company or takes up the job of leading a new product in the existing company, the first fear that runs in their mind is if they are going to identify and solve the right problem or not.
The previous or current folks who have worked on the product may provide insights and tell you that the biggest problem to solve is ‘x’ but it may or may not be true. One should try to not succumb to the pressure of what has been discovered earlier as a problem statement. It is every PM’s duty to embark on the journey of finding the right problem to tackle and set the priorities for the upcoming times to come.
In this quest of truth, the following pointers may come handy to a product manager:
- Know thy product inside out:
Whenever you join a new company or be a PM for a product, it is very essential to know the product in and out. To garner that knowledge one must:
- Navigate, use and test the product with bare hands.
- Read the help or reference documents to gain more insight about the product features.
- Understand the high level architecture of the product, data flows and how various components of a system interact with each other.
- Talk to your peers, developers, testers and other PM to give a walkthrough on the product.
Knowing your product is the first step in the right direction as a PM!
2. Quantitative Analysis:
One must never ignore numbers, for without numbers, your management and bosses would never okay a project! If you want to uncover problem areas — quantitative analysis will help you point in that direction.
- Get access to ‘Support tickets’ raised by clients from CRM systems. The numbers will help to find out the most problematic areas of the product.
- Get a dump of ‘bugs’ in the system (may be raised by Clients or identified internally). Try to categorize them the same way as you did for support tickets to get a sense of which feature has more number of issues.
- Most of the organizations have a mechanism to intake client feature request. This should also be categorized and added to the the list to find the areas of improvement or innovation.
- Surveys — They provide insights on the customers problem areas, where they want to see immediate improvements in the product, etc to get actionable items.
- User Behavior and Product Analytics — Tools like amplitude, mixpanel, google analytics can help you understand the user journey and provide valuable insights on feature usages, time spent on a page or features, conversions and how your product’s working for them. Analytics make metrics useful by giving them context, allowing you to discover insights about what to do next.
- System Data and Failure Analysis — Not all your problems can be attributed to usability or functional issues. Some of the projects to be undertaken can be due to underlying technical issues. Reach out to the engineering teams to pull up some data on system failures, page errors, issues caused by bad data, time-out issues etc. If possible, you can do it yourself by using tools like Splunk, Loginsight, etc. This will give you a perspective on other problem statements that can be addressed.
To illustrate — if one of your page is crashing too often because of monolith code issue (one team pushes the code and breaks the other pages since they have the same artifacts), it is time to move to microservices. This becomes a project and a problem to be solved. PMs would be in-charge of making sure that when there is a movement from monolith to microservices, they need to ensure that functionality remains intact or upgraded.
3. Qualitative Analysis:
Qualitative Analysis will help you develop empathy on the problems and wants of your customers. Let us look at some ways to uncover that:
- Talk to Clients: Let’s face it — if you are a PM, you shoul not and cannot avoid talking to Clients. It is important to have meetings with your clients to understand their use-cases, their woes, rantings and sometimes praises! You could do this individually or in groups/forums — in person or virtually. The wider and diverse type of Clients you talk, the more perspective you get about your product. By diverse, it can indicate geographical regions, industry type, size of the company, etc
- Feedback and Reviews on public forum: Just do a google search of your product and you will be able to uncover a lot of good or bad feedback about it. They may be from individuals, industry experts, websites, analyst etc. Places to look for these feedback are — google reviews, twitter, facebook, market research companies, vendor research companies, etc.
- Competitor Analysis and current trends: A wise man once said — ‘keep your friends close and enemies closer’. It makes so much sense to keep yourself updated on what your competitors are upto. It would help to see what they are doing new or better than your product. Doing an analysis between your product and your competitors offering will help you understand what your product lacks. Knowing where the market is heading to, by following the current trends in the industry would help you to be ahead in the race.
- Interact with Internal Teams: There are a lot of customer facing teams within your company — Sales, Marketing, Customer Success, Customer Support, Tech Support and may more. Talking with them will help you uncover a lot more problems that the Clients are facing. A PM cannot know it all and has to depend upon a lot of people to provide him/her such insights that can help them expand their horizon on customer problems.
4. Qualitative + Quantitative data and analysis = ‘One Big Holistic View’
While qualitative data analysis will help you point in the direction of the issue, qualitative data analysis will help you uncover in depth as to what the problem is, why is it affecting clients and what behavior is desired.
When you want to test out a hypothesis, you cannot go ahead analysing one without the other.
For example — The quantitative analysis points out that 30% of the bugs or support tickets for a product are attributed to ‘attendance or roster management’ areas. From Qualititative analysis we see that majority of the customers have voiced out their concern that there is no way to bulk upload attendance and the page times out when submitting attendance for more than 100 attendees.
Try to fit in numbers or metrics for the observations that comes out of qualititative analysis. This will help solidify your argument and confidence when you want to pursue a solve for problems.
5. Picking the right problem to solve:
When you have the data from qualititative and quantitative analysis, it is time to put them in a single pane of glass to come up with a decision as to which problem do we need to solve first. Out there, we have excellent models to accomplish that — RICE model, Kano Analysis, MoSCoW technique etc.
What I do is take the best of those models and try to encompass them in a comprehensive sheet to make a decision. The sheet comprises of the following fields:
a) Feature : Tagging the feature that has issues or new requirement.
b) Issues: Both qualititative and quantitative analysis can be filled in this column. For example — 60% customer leakage post items added to cart, low conversion rate from prospect to buyers.
c) Severity: Determines the seriousness of the issue . Can be broken down in to — Low, Medium and High.
d) Compliance/Legal Impact: Some features or issues can be attributed to compliance or legal requirements — GDPR compliant systems, SOC compliance, etc.
e) Revenue Impact: By not doing this feature or fixing the bug, do we incur a revenue loss. If so what would be the value.
f) Competitor Analysis: Does our competitor have these features? Is this a feature separating them from us?
g) Feature Usage: How many number of customers and users are using this feature. What is the frequency of usage or how often do they use this?
h) Cost to build or fix: This is the initial level estimate from Engineering and other teams involved to fix or build new feature.
Once all the requests are put in this format, it helps a Product Manager to choose the right problems to tackle first by taking a look at it!
