Guest Post by: Rashid Manzar (Mentee, Session 7, The Product Mentor) [Paired with Mentor, Harikrishna Menon]
I love solving problems. From high school to business school, and throughout my professional career, I was supremely comfortable with it , and reveled in solving problems, to the appreciation of my managers, colleagues, and teachers.
Over time, I realized that my true passion lived in product management, but when I tried to showcase my problem solving skills in multiple interviews, I failed miserably. I went back to the drawing table, mastered all the suggested interview materials and sought guidance from multiple people, but to no avail.
Luckily for me, In one of the interviews, an awesome interviewer told me that I like what you are doing, but you don’t really know what problem you are solving. That was an eye opener, as most of my life, I focused on jumping to solutions, but spent little or no time in defining them in the right way. When I solved math problems, puzzles or computer programs, I never gave lot of thought to where those problems are coming from, why it is a problem, or who is defining them.
When I started working as a product manager, I understood that identifying and defining the problem is a crucial first step before even thinking about solving it. After every discussion with customers, sales, service, leadership and my colleagues, I was left with a laundry list of problems that needed my attention. However, in a product there are always a gazillion problems to solve but only a few are worth working on. On one hand, everybody expected me to focus on the problems that will help them to succeed in their workflows or function, and on the other hand, I had limited time to give all the problems their due attention it. Therefore, it was important for me to be aware of the following three things: 1) Where should I start? 2) What should I solve? 3) How should I go about solving it?
Management guru, Peter Drucker had said, if you can’t measure it, you can’t improve it. This lesson is very much applicable in every situation. As a product manager, my goal is to ensure customer satisfaction, long term success of my product and contributing to the success of my organization. All of my activities should revolve around achieving and improving on these goals. To get started on this path, one has to identify and define metrics that can help in measuring success.
Given any product is a part of organization, I started with metrics that reflected the goals of the organization.
One of those goals was to reduce the overall cost of service across the organization. In this instance, the metric that reflected this goal was “call volume to the service team”. The next step was to identify and define the problems that were leading to high call volume. I listed down my assumptions and identified problem hypotheses by collecting inputs from service team members and analyzing data from the customer complaint system. To validate/invalidate my hypotheses, I interviewed customers and service team members and focused on understanding the pain-points. I took comprehensive notes to capture facts, feelings/emotions and opinions. Although these interactions provided me with a set of problems, but these problems were just symptoms, not the root cause that we should have focused on. I applied the 5-why approach to dig deeper into what customers were feeling.
As a new product manager, I was not well versed in this approach. I faced lot of problems that not only slowed me down but also left me with enough ambiguity that made it difficult to move ahead. During this journey, some of the key challenges that I faced are follows:
- I found it very difficult to define the positioning statement for the product. I knew my users, but I struggled with defining the value proposition, and its competitive advantage.
- The list of features kept on growing, which increased our cost, pushed our timeline and forced us to cut corners in building features.
- Even within the features, the differentiation between must have, good to have and convenience use cases become blurred resulting in constantly changing scope, which added to the frustration of UX and development teams.
- Aligning stakeholders became extremely difficult because everybody had a different view of the problem that needs to be addressed, and they felt we were missing key use cases. Occasionally, we had situations when stakeholders started to propose solutions.
- We ended up spending time in those use cases which had no relevance to the core needs of the customer.
After adopting my new approach, things changed completely. For example, on one of the occasions, my colleague was explaining the requirements to the UX team and they had lot of questions on how they should handle content and user flow for the feature. I highlighted the pain point that we were trying to solve, and it changed the track of conversation from rambling to a more focused discussion. On another occasion, I started a business review discussion by explaining the customer profile, sharing the problems faced by customer and why I was focusing on those problems. The stakeholders nodded in agreement and they asked relevant questions rather than suggesting the solution.
The impact of this approach was not only reflected in the stakeholder and UX discussions, but also in the negotiating development scope with the engineering leadership and running sprints efficiently. For example, in one of the features, engineering leadership wanted me to cut down on the scope to accommodate the ask within the expected timeline. But, when I explained them how reducing the scope will prevent us to solve the core problem, they agreed to take it in. Similarly during the user story discussions (grooming), developers wanted to spend time on points that were important but not critical to the core problem. For example, they wanted to determine how certain field validations and calculations can be done when user change focus away from field. Given it was not impacting my core problem, I simplified the requirement and asked them to do all the validations at the time of “submit” action, reducing our effort significantly. It saved time/effort and instilled trust in the direction I was trying to lead the product into.
As a product manager, it is extremely important to put this approach into action. First step is to understand your organization’s priorities. Reading annual reports to understand strategy, mission and goals of the company, listening in town halls, and speaking with senior leadership to get their perspective and the rhythm of business are some good ways to keep yourself aligned with the organizational needs and priorities.
Second step is to identify success metrics. Some of the key metrics that impact product and eventually your organization are acquisition, retention, monetization and cost metrics. Good places to find and benchmark these metrics are NPS scores, customer call volumes, data around sales funnel, product usage and attrition information.
Third step is to come up with a set of problem hypothesis. Analyzing customer complaint data, listening to service and sales personnel, engaging in customer forums and data on customer requests are some of the good ways to build initial hypotheses on customer needs and pain points.
Fourth step is speaking with customers, running experiments and/or using existing customer/product/market data to validate/invalidate hypotheses.
Finally, you start your journey towards solving the right problem.
Rashid works as a product manager, focusing on small business segment, at ADP Canada. In 8+ years of his professional experience, he has worked as a product manager of payroll/time products, a business consultant (product focused) on e-commerce and subscription platforms and a software developer of self-service, API and reporting products. He completed his MBA from UNC Kenan-Flagler (USA) and Engineering in Computer Science from BIT Mesra, India.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 