A few years ago there was a new phrase that made its rounds through the product management community: “love the problem, not the solution.” That is, make sure you’re solving a problem for customers, and have a deep understanding of that problem. Focus on the problem over your product (the solution). All great advice. But I’ve seen teams struggle when applying it. In this post, I’ll talk about 3 common issues I see with this concept.
No user research interview starts with "So, what problems do you have?" People have a hard time expressing the problems they're facing. Instead, they're able to explain potential solutions or the impact the problem has on them. As a result, I see these common mistakes when defining a problem statement:
Imagine you've identified 4-5 opportunities for your product to solve a customer problem. How do you know which ones are worth pursuing? You might have identified these opportunities through customers who aren't representative of your overall customer base, or your target customer. You might consider a problem prioritization scorecard, where you rank each problem based on factors like:
Note that identifying problems with the existing product vs talking to customers about different problems that the current product doesn't even address are two very different things. Don't get caught up just solving the existing product's problems at the cost of solving the next set of problems for your customers.
In the end, the top problems to solve are still hypotheses, and it's hard to validate those hypotheses because if you ask customers or prospects whether those are problems they'd want you to solve, they'll likely say yes (if you've done your prioritization well). But they may never mention that there's a bigger problem they wanted you to solve for them.
Let’s say you did figure out what problems to solve for a customer. There’s still the question of knowing when the problem is solved. Do you ask the customer point blank? Track their clicks in your product? Most data-driven product teams would likely choose a KPI to measure how well the problem is solved. That is, it's not binary - yes, we solved the problem or no we didn't. Instead, there are gradients, and knowing what is "good enough" will let teams know when it's OK to celebrate their milestone and move onto the next initiative. The idea of customer outcome KPIs is to quantify how a customer would measure the value of a product or feature, and the internal goals for that metric should captures whether the problem is being solved.
As you hopefully know, we don't like to just talk in theory. Let's use our fictitious home-cooking product Chuckwagon as an example to show how different your product might be depending on whether you focus on problems vs outcomes.
Imagine we're staring to plan the launch of Chuckwagon and therefore set out to do some user research on what it takes to get a home-cooked meal on the table with a bunch of consumers. You could imagine an interview guide with this key question:
Walk me through your process of getting a home-cooked meal on the table. What are the most painful parts?
We might hear common responses such as:
So the PM will still need to prioritize these problems against each other and brainstorm potential solutions. Imagine all the ideas that might come out of that brainstorm with the team:
None of this looks wrong - these are legitimate problems and innovative solutions. But they lack cohesion, or a common thread that weaves them together. Let's look at the outcome-focused approach to see how it might solve this problem (pun intended).
Now instead imagine we set out to identify what key outcomes consumers seek when getting a home-cooked meal on the table, and the interview guide had a question like this instead:
Walk me through your process of getting a home-cooked meal on the table. How do you know if your process is working well?
Imagine some of the responses we might hear to this question:
Aha! They're telling us some of their success metrics, or the outcomes they seek. Satisfied tummies. Speed. Cost. In the case of Chuckwagon in particular, we did more competitive research and based on the number of 5-star recipes in the world, we decided the product couldn't differentiate based on good food alone. There are a couple of nuggets from those responses above that lead us to believe that the amount of time it takes to get the home-cooked meal on the table is a key outcome metric, so we went with that, and built this key outcome KPI pyramid:
Now, you could still express this as a problem statement. Using design thinking, "How might we reduce the time it takes to get a home-cooked meal on the table?" For more on the particular solution we've envisioned, check out the Chuckwagon strategic planning case study.
Don’t get me wrong. Product managers, designers and engineers are all problem solvers. So as product managers, we need to set the context of the problem. But writing down the problem isn’t enough. We need to be clear on how we’ll know if we’ve solved the problem. We included the concept of customer outcomes as a part of our Vision-Led Product Management framework at the same time another shift is starting on product teams: focusing on outcomes (goals) over output (on-time feature delivery). I see the two concepts as complementary. The key difference comes in the area of which outcomes you’re focusing on - internal ones like revenue and NPS, or customer ones. The point of the customer outcome KPI pyramids is to make sure teams never lose sight of what matters to the customer.