We’re taking a break from the Best Friend Series and exploring problem discovery!
As a product manager, one of your tasks is to manage the process in which problems are solved and not to solely focus on developing the solution. Aditya Kothadiya put it perfectly when he stated in his Medium article that Product Managers should be Problem Managers, not Problem Solvers:
Product Managers shouldn’t be problem solvers. Their focus should be to:
- Identify the right problems their company and team should solve
- Prioritize which problems to solve first and which can wait until later
- Communicate the rationale behind these decisions to their team and other stakeholders
In terms of the actual development of the solution, you must work with and leverage the expertise of your Prod Squad to finalize how things will be built:
- Your designer will use their expertise to determine the arrangement of buttons, text and toggles facilitating the user’s efficient completion of the product experience (as noted in Why Your UX Designer is your best friend)
- Your engineer will analyze the product requirements to scope the engineering resources needed to build out the engineering infrastructure to support the product solution.
- Your data scientist will help in determining the right metrics to monitor and in ensuring the data analysis tools can collect and display these metrics upon launch.
- Your product marketing manager will work with you to communicate the goodness your members can expect once they interact with the feature.
Great! Now you clearly understand everyone’s role in the problem-solving process. This article is going to focus on that first bullet of Aditya’s article: Identifying the right problems that your team should be solving.
You may be asking yourself, “Where do I begin with identifying the right problems that my team should be solving?” If you don’t have a user problem to solve then your development team can’t even come up with a solution!
Well my friend, I’ll give you a few tips on how you can do just that. That’s what I’m here for so stop biting your nails!
Let’s break down what it means to identify the right problem. In order to know if a problem is the right problem, you must:
- Identify a problem. At this point, you are simply trying to figure out what member pain points even exist.
- Determine that it is the “right” problem. After identifying a potential member problem, you need to then more deeply investigate and validate this problem to see if this is something that your team should solve.
Identifying a Problem
In order to facilitate your understanding of where problems can even be found, I’m going to introduce a high-level view of the product development funnel. Once we understand the various steps in the product development funnel, we will be able to determine at which stages problems can be uncovered.
Product Development Process
Organized Discovery – Actions that fall within the organized discovery category include explicit member outreach or planned brainstorming sessions. The purpose is to search for qualitative or quantitative data related to a customer pain point (and its subsequent product) that you want uncover. This can take the form of UX Research interviews or marketing surveys. These actions can also include “How Might We” Ideation sessions which help facilitate the problem discovery and idea generation process.
Define and Validate Problem – After you have completed the organized discovery stage, you will be more clearly defining the problem that you discovered and potentially a high level view of what a solution could look like. You also need to validate that the pain point does indeed exist for your members.
Design Solution – At this stage you work with your Prod Squad to design your solution. The design portion involves all aspects of the product:
- UX/UI
- Engineering Infrastructure
- Marketing Plan
- Metrics and Data Tracking plan
- Legal concerns and UX Copy are also included here
The solution can be just the MVP or MVP and its subsequent iterations.
Develop – This is when all aspects of the product that have been designed are built.
Deploy – Fairly self-explanatory. At this stage, you launch your product and see how people interact with it.
Assess– After launching, this is where you analyze the success of the product launch. The assessment can come in both qualitative (metric analysis) and quantitative (customer feedback) forms.
Iterate (Decision Diamond) – At this stage you combine the insight from the assessments you have made after launching with your original product plan to determine the best path forward for your product (if iteration is necessary)
Great, Joe. You’ve now introduced me to yet another version of the product development process (which is probably the 10th one I’ve seen online) but I am still unclear on what aspects of the process facilitate the identification of a potential problem to solve!
Okay, let’s get to it…
Let’s dive into where in this timeline you can identify problems. Below you’ll see the timeline with the areas where problems can be identified, which are highlighted in orange.
Where can problems be identified?
Organized Discovery
This is definitely the most obvious portion of the timeline in which problems can be identified given the goal of this stage is to actively and deliberately seek out problems to identify through interviews, surveys, focus groups, or brainstorming sessions.
Deploy
At this point in the process, you are seeing how people are interacting with your product. One fool-proof way to find a potential future problem to solve is to see if people are hacking your product to create their own solution. “Hacking” in this sense indicates that a member is using your product for a purpose outside of the purpose that you intended for the product.
- For example, if you created a product to enable members to keep track of their daily tasks by creating short bulleted lists but noticed some members were not only writing tasks but also writing due dates at the end of each task. At this point you think, “Hmmm…if every member adds dates in their own way, this will create inconsistency in our understanding of the data but also puts more strain on the member to then add the information to their own calendar. Maybe we can add our own calendar to ensure consistency in date additions and/or perhaps integrate the calendar of the member’s choice (Google Calendar, Outlook, etc.) with our product so they can see the task as they scroll through their daily agenda.”
- Another real life example I recently came across at work includes how members interact with the experience section of their LinkedIn member profile. The purpose of the experience section is to highlight any work-related experience a member has (including accomplishments, responsibilities, location, company, etc). During research I was conducting for international members, I stumbled upon another use case: members were entering in non-work related experiences in their experience section. These non-work experiences included maternity/paternity leave, gap year, military service, general unemployment, and sabbaticals. When trying to uncover the actual pain point that members were indicating by hacking their profile, I worked closely with my UX Research counterpart (the regal and magnificent Renee Reid) to answer the following question: What goal do members want to achieve by entering in these non-work experiences and how can we facilitate the addition of these experiences in a way that enables members to fulfill these goals?
Assess
At this stage, your product is out, your members are interacting with it, and your platform is collecting data (both qualitative and quantitative) on member usage.
- Quantitative Data Assessment – You can work with your data scientists to analyze trends in user behavior (i.e. how are specific user segments interacting with the various aspects of your product? Which aspects are underutilized/overutilized? Does this match your expectations?) You can then use this data to devise product changes to further encourage positive user behavior or change negative behavior.
- Qualitative Data Analysis – You can work with your customer operations team to get direct quotes from members regarding their use of the product. Your customer ops team will track positive/negative feedback and track trends in member complaints to give back to the product team in order to continue to improve the product.
One fool-proof way to find a potential future problem to solve is to see if people are hacking your product to create their own solution.
How to determine that it is the right problem to solve?
Amazing! You've found a potential member problem. How can you ensure that this is the RIGHT problem to solve?
Let’s say you feel you have uncovered a potential member problem that could meet your company’s threshold for attaining engineering/design resources. The next step is to ensure that this is the RIGHT problem to solve. What’s next?
Sidenote: There are many criteria that determine whether a problem is the right one to solve including company/team strategy, timing, available resources, problem validation, etc. Delving into all the various criteria would require an article in itself (which I’ll write at a later date). For the sake of simplicity for this exercise, we’ll assume we will be focusing solely on problem validation and all other criteria (company/team strategy, timing, resources, etc.) have already been considered (i.e. For the remainder of this article, determining if the problem is the right problem simply means you will validate the problem through user experience research.)
As stated in the “Why Your UX Researcher is your best friend” article, you can work with your UX Researcher to validate your hypothesis to:
- Ensure the pain point actually exists and gauge its severity.
- Ensure your high-level solution has a good chance of succeeding.
- Gauge how the solution will scale across all member segments.
Remember the product development process diagram in the UX Researcher article? I’ve included it below for your reference:
The problem discovery process described in this post enables you to be that product manager with a hypothesis. Once you are able to identify a potential problem (and come up with a hypothesis you want to test), you can work with your UX researcher to validate the hypothesis to ensure you are solving the right problem (i.e. In the diagram, you’ll move from “I’m a product manager with a hypothesis” to validate/refute the hypothesis. You will then move to “completing your initial product designs” if the hypothesis/problem validation process goes well.
It’s beautiful how it all works together, isn’t it?
You now know a few ways to pinpoint member problems! If you have any suggestions for more to add, ping me at joe @ thepzeropm.com and I’ll add them to the list (along with attribution).
