April 2024
Product management is all about delivering value to the customers while keeping in mind business goals. As Marty Cagan described in his SVPG article, product managers are responsible for:
Viability → ensuring the solution aligns with the business objectives
Value → ensuring the solution meets customers’ needs
The viability part relates to what your company needs at the specific time. Mostly, it’s based on your team’s OKRs. These are given to you by your product leadership based on a proper product strategy. The main goal here is to drive business outcomes.
Let’s assume your team has clear goals, a product metric related to it, and a user persona defined. What happens next? What should product managers do to understand what customers want? The answer is product discovery and in this article in more detail — problem discovery techniques.
Product discovery
Product discovery is becoming more important and a standard in modern product teams. It’s divided into two stages and should answer these questions:
Problem discovery ⚠️ What is the problem? Who experiences it? How frequent and severe is it for the users? How to define the problem, and is the product team aligned around it?
Solution discovery 🎯 What solutions can solve the problem? What are the risks in the solution? It he solution usable by users?
You learn more as you go and iterate through the phases. The process increases your confidence that the problem exists and gets you closer to solving it. I like how Productboard illustrates the product discovery:
Whenever I start the discovery, I want to convince myself first and the more data I have, the better. Here’s what I look for during problem discovery.
Problem discovery
User insights
One of the key elements in problem discovery is going through user feedback. This is the most direct validation saying if your company does it right or not. These insights are stored in product management tools such as Jira Discovery or Productboard. They gather feedback and enable analysis but it doesn’t matter what tool you use. It’s about having the feedback in one place, analyze it, and make better decisions.
I usually start with Productboard, look at our defined OKR, and search for related problems from our users. Here I’m pointing to problems because I define the tickets as problems, not features. Searching for the identified problems depends on how often I clean up the feedback. It is painful and takes time to keep it organized, but it’s critical.
The feedback helps me understand the problem qualitatively and quantitatively. The quantitative data are necessary for prioritization between problems that tie to the defined OKR. These data relate to:
Frequency → how often the issue occurred
Problem severity → how much of a problem it is for individual users and the overall sum of these individual scores (sometimes called impact score)
Pro tip: I use user quotes as qualitative data and add them to my summary or presentation. It amplifies the urgency and empathy toward the users. It’s a great convincing tool.
Product data analysis
This part can be tricky and takes some time. Especially, if you rely on your data team to provide you with the data. It’s best to do the analysis on your own in tools like Mixpanel or Amplitude Analytics. The prerequisite is to have all major events tracked in the tool and have tracking on individual elements such as buttons or tabs.
If we come back to the assumption that you have a defined OKR and a user persona you know all about, you should be able to access:
the user journeys and their conversion trends/rates
engagement metrics
other related metrics
Initially, the data gives you more context of what’s going on and it uncovers the weak spots. As the analysis unfolds, you narrow down what you want to focus on and see what can bring the biggest improvement. Maybe there’s a steep drop-off in one of the user journeys because the path is hard to find. Or maybe some elements are not visible at all on smaller screen resolutions. Whatever it is, the data give you additional arguments on why to focus on the problem. And again, your confidence goes up.
User recordings
Some data analytic tools enable user recording such as Smartlook or Hotjar. You would be surprised about what happens within your product and what daily problems users encounter.
This helped me confirm some of my assumptions and is a must after you release your initiatives. Not every company allows record user sessions due to compliance though.
Assumptions
Once you get user and data insights into the problem, there are 2 things you can do:
Summarise the research
Continue in the problem discovery
No matter your choice, it’s good to outline your assumptions about the problem. At this point in discovery, you care only about:
Desirability assumptions → What do users want based on the insights? How can users achieve it?
As a first step, I outline the assumptions in a table or as an assumption map. Then I assign how much evidence I have (weak vs. strong) and their importance (high vs. low). Here’s what it looks like:
Using the importance and evidence helps to prioritize the assumptions. It navigates you to know what to discover more. The logic is to go from the most important assumptions with the lowest evidence.
I like to outline the assumptions because it sparks a discussion and creates alignment within the product trio. Discovery is a team activity. I can agree with the team to focus on some assumptions and prepare solutions. Or I can continue in the problem discovery and start user research.
User research
The best way to get quality feedback is to talk to your users. It’s hard to get users to talk to you and it’s critical to talk to the right users — your user persona. Before the call, you can send to the candidates screening questions to narrow down who you talk to.
Screening questions are a list of questions that qualify or disqualify your interview candidates. There are usually 2-5 questions to ask depending on your research activity.
When I have the right users to talk to, I prepare for the user interviews:
Research question 🥅 It helps me answer the critical information I want to learn about users’ behavior. The findings guide me to make better decisions for our designs. In most cases, I list one question related to the discovery process at a time.
Interview questions❓ I ask them during the meetings and they stem from the research question and assumptions. They should motivate the users to tell a story. You can ask them in the form of “Tell me about the last time you did X.”. There‘s typically at least one question to each assumption, and the goal is to understand how users behave.
Assumptions 🤔 The list of the assumptions identified before. Only the most important assumptions should be tested.
