3 Reasons to Stop Solving Problems and Start Delivering Outcomes

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.

1. It's Easy to Express a Problem Incorrectly

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:

• The problem is expressed as an internal problem rather than a customer problem.  For example, a user story whose goal is to increase usage of a particular feature, rather than delivering customer value through usage of that feature.  No customer cares about your feature adoption metric.  They care about whether the feature is helping them. 
• The solution dictates the problem statement, rather than vice versa.  This is really common with feature requests.  I've seen a lot of teams take the request at face value and build a solution that's very specific to one customer, instead of understanding the problem and designing a solution that can work for every customer (or most, at least).  Don't get me wrong - sometimes things like single-sign-on or data-sharing integrations are one-off solutions.  But you need to know when you're explicitly choosing to solve a problem in a way that's specific to one and only one customer, versus not doing the research to see if the suggested solution would solve the problem for other customers.
• The wrong problem is expressed.  Sometimes it's hard to know what problem needs to be solved, especially when you've identified multiple problems.  If you get the problem statement wrong, it's likely the solution (your new product or feature) will be wrong as well.
• The problem is expressed as a product problem, not a real-world problem.  Imagine all the usability feedback and bugs product teams get.  Those are all problems with the existing product, to which customers are anchored.  They speak in terms of iterative changes to the existing product, and therefore only listening to the problems they have with the current product will limit the amount of product innovation you can deliver, as you're stuck talking about the existing problem set.  (Of course, there's a time and a place for usability polish, especially as you find product-market fit and want to optimize conversion rates and reduce friction to extract every ounce of value possible from the product).

2. Not Every Problem is Worth Solving

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:

• Number of people affected by the problem
• How frequently those people experience the problem
• How painful the problem is for those folks
• Whether they're already paying for a solution to the problem (always a good sign)

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.

3. It's Hard to Know When a Problem is Solved

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.

Case Study: Chuckwagon

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.

Chuckwagon: The Problem Solving Approach

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:

• Deciding what dishes to make (too many choices these days!)
• Mixing it up with a variety of dishes over time
• Forgetting to buy an ingredient for a recipe
• Making sure the entire family (especially kids) like the food
• Reading a recipe fast enough while cooking to not mess up the dish
• Cleaning up after the meal

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:

• Deciding what to make: a menu "coach", crowd-sourced weekly menus
• Mixing it up with a variety of dishes: a "recency" filter for dishes, a modal asking if you've made a dish in the last 3 weeks before viewing a recipe
• Forgetting to buy an ingredient: a grocery list feature
• Making sure kids like the food: a kid-friendly post-meal survey, a kid account from which they get to "veto" a dish once a week
• Reading a recipe fast enough: Alexa Skill (with pause feature)
• Cleaning up after the meal: a "kitchen cleanup" marketplace

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).

Chuckwagon: The Outcome Delivery Approach

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:

• Whether everyone likes the meals made
• How long it takes to decide what to cook
• How much it costs to make the food
• How long it takes to get the right ingredients
• How long it takes to prep and make the dishes

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.

Closing Thoughts

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.