Start with the Problem Space
Why Product Managers should focus on problems, not solutions.
Lots of product managers make the mistake of jumping to solutions. Stop that.
This mistake makes sense: we launch solutions, we’re measured by the performance of our solutions, and we even get bonuses for great solutions.
So people naturally think the solution space is where we should spend most of our time, coming up with the best solution. Wrong. There’s a much bigger space, a galaxy far, far away, called the problem space. Once you explore the entire problem space, you’ll find real problems, you’ll know the whole problem, and you’ll be more creative when you transition to the solution space. And if you don’t, well, I’ll tell you about my disasters here, too.
This post is part three of my five-part Product Management Crash Course, based on my recent guest lecture at MIT. Don’t miss it; subscribe.
Problem space vs. Solution space
The “problem space” and “solution space” are fancy ways of talking about problems versus solutions. Putting “space” at the end sounds smarter, right? Like you work for NASA or something.
It’s actually a helpful way to talk about the difference between the two. Because “space” refers to all the artifacts and actions that separate these two ways of thinking.
When you’re in the solution space: you are actively problem-solving. You seek, design, and build a way to fix or resolve an issue.
The solution space includes your product, all its features, and the designs and plans you make for improving it (like wireframes, prototypes, and written descriptions of the end product).
When you’re in the problem space: you’re exploring, inquiring, and developing an understanding of the issue; you’re not actively trying to fix it.
When you’re in the problem space, you don’t talk about how you could solve the problem. You only focus on what the customer’s needs are.
What’s the problem they have?
What are they trying to do or achieve?
You can dig deeper here:
What are their motivations?
How does this problem make them feel?
Where are they when this need arises?
What is the environment they are surrounded by?
Who are they with?
What are they thinking?
All this information lives in the problem space. It has nothing to do with solutions.
Why you should explore the problem space
As product managers, we all know that we need to start with the problem. It’s phase one of the product development process, define the opportunity. When you write a PRD or kick off a new project with your team, the first thing you do is describe the user problem that you are all going to solve.
That’s great, but many PMs just barely scratch the surface of the problem space. They take a picture of the first moon 🌒 they pass by when the problem space has a whole galaxy to explore. 🪐🌌🧑🚀 Ahhh, space joke, sorry, I had to. 🤓
It's tempting to jump quickly to the solution space when you think you know the problem, but spending more time in the problem space has some huge benefits.
1. Find a real problem
Spending more time exploring the problem will force you to validate if the problem is a real problem that real people care about. Solving a “problem” that nobody gives a kahoot about is a waste of your time. On that note, let’s talk about my biggest waste of time.
My big fail
My biggest product failure was one of my very first launches as an Associate Product Manager. I was a newb and didn’t know any better, so I dove head first into solutions.
My assignment was to improve new user activation – to convert more newly registered users to active users. My team and colleagues had lots of great solution ideas. I picked a solution that was also a conversion tactic recommended by conversion experts. When everyone is smart, with smart ideas, what could wrong? We built a way for users to use the product before creating an account. I thought this would get users more invested and, therefore, more active in the product. Felt like a solid plan. Newbie-PM Sondra ran with it.
But six months later, we launched, and nothing bleeping happened. The activation rate didn’t go up or down; we literally had zero impact. Bad results would’ve been better than nothing; at least we could’ve learned something.
And yeah, I said six months. Back then, our development process was waterfall, it took longer, but still, this was an unreasonably long time to build a doomed solution.
My solution solved a problem that wasn’t a real problem. I had tried to optimize for motivation, but our users didn’t have a motivation issue. My problem statement was weak, at best, and full of unvalidated assumptions because I had only scratched the surface of the problem space. I don’t think I even talked to customers. 🤦🏻♀️
I returned to the drawing board and spent weeks in the problem space. I emailed users who abandoned after signup and talked to many of them on the phone. I learned about the real problems holding them back – new users didn’t understand how the product worked or how much it cost. Armed with this new information, my team launched a new solution, and new user activation improved by more than 20% in our A/B test. We solved a real problem, and the results were massive. Hopefully, these results are so impressive that you’ve already forgotten I wasted six months in the solution space.
A much bigger fail: Segway
It’s not just junior PMs who make this mistake. Entire companies, full of very smart people, launch solutions to fake problems all the time.
Remember the original Segway? 2001? Well then, let’s take a quick history detour.
Back in 2001, the Segway was considered a revolutionary product. Before it launched, there was a ton of hype, and some people thought it would transform how people travel. Unfortunately, the company was too focused on its cool tech, a self-balancing thingamajig. They jumped to the solution space without enough consideration of the problem space.
People didn’t need or want what they built, at least not for 5 grand. The original Segway didn’t solve a real user problem. The self-balancing tech was the main selling point, but nobody needed it.
It’s tempting to jump to the solution space too soon, especially when you have innovative tech you’re eager to introduce to the market. But just because something is technically possible doesn’t mean it’s worth building.
“There's a lot of technology in search of a customer. You know, in other words, a lot of companies do things because it's technically possible, but in the end, nobody cares. Nobody wants to buy them.”
– Steve Jobs (Source: YouTube)
The original Segway was too slow for streets, too big for sidewalks, impossible to park, and unaffordable. It didn’t solve a real problem. Nobody needed “cool” tech; people needed practical transportation. (Source: Segway case study.)
More than 20 years later, Segway is kinda cool again, not for the namesake product they stopped producing in 2020, but for cute little e-scooters that people actually want. The e-scooters solve a real problem.
The lesson here: you should explore the problem space deeply to validate that there is a real user need.
2. Know the whole problem
Even when customers directly tell you what they want, that doesn’t mean you’ve unlocked the problem space. Usually, customers will give you feedback in the solution space – they’ll describe features they want, these are solutions. You have to dig deeper to get to the problem.
When I worked at a data analytics company, we had a lot of customers making this request:
“I need to adjust line thickness in my line charts.”
We had lots of requests for this feature. It seems straightforward at first glance. Everyone on the product team who looked at this request immediately assumed they understood the problem space, but we only understood half the problem.
Problem space: The user has created a line chart; they want to highlight one or a few lines on the chart to make those lines stand out in a report.
That’s an easy problem to solve. If we jump to the solution space, we could build a way for the user to select a line and make the line thicker than the others.
This is an excellent solution if the problem is needing to make one or two lines stand out on a busy chart. And that was the problem some users were facing, but not all.
When I looked closely at the chat transcripts, I saw that some users wanted to display their charts on a large TV screen on the wall in their office. The overall resolution of the chart could have been better at that screen size, and they wanted all the lines on the chart to be thicker.
Poor resolution of line charts on a large screen was a totally different problem, which needed a totally different solution. Can you imagine if we asked the TV users to click every line and make them thicker one by one? They would be thinking, “This product manager knows nothing about the problem space!”
Even though the customers asked for the same thing, their problems were different.
Feature requests from customers are often a trap. What looks like a quick win on the surface could be totally different when you dig in. You must explore the problem space to make sure you fully understand the problem before jumping to solutions.
3. Be more creative
The third benefit you get out of exploring the problem space is a big one: more creative solution ideas.
I work with a few early-stage startups. I recently visited the founders of one of these startups in-person to plan the requirements for a new product. To start the conversation, I asked, “What problem do we want this new product to solve?” The founders have a strong vision for their product, and they immediately answered but were describing features. They were in the solution space.
I respectfully interrupted and asked again about user problems. Again, they instinctively jumped to solutions. Our brains naturally go to solutions first.
So I tried something different. I grabbed a whiteboard and introduced them to Teresa Torres’ Opportunity Solution Tree framework to visualize the problem space.
Note: “Opportunity” is another way of saying “user problem” or “user need.”
We mapped out everything we currently know about our users and their problems. We spent hours breaking down the problem, going four layers deep into the problem space. Instead of scratching the surface, we explored the problem space and uncovered details about the user needs we hadn’t acknowledged before.
And something magical happened – we got more creative. When we were ready to think about solutions, we came up with dozens of great feature ideas that we could test.
Our favorite idea from the session was something none of us had ever considered, which could deliver a ton of value to our customers. That deep exploration of the problem space unlocked the creativity we needed to get there.
Exploring the problem space with your team will generate more creative solution ideas.
How to explore the problem space
Many PMs instinctively want to jump to the solution space or are pushed there. Here are things you can do to spend more time in the problem space, which will lead you to better solution ideas.
Step one: Talk to your customers! Do this often so you’re always learning about customer needs.
Team up with UX Researchers to do deeper user studies. It’s especially helpful when you’re working on a big new project and don’t know much about the problem space yet.
Read support tickets or chat transcripts. These are a gold mine for exploring the problem space. Customers describe their problems to your support team in support tickets and chats. Reading the customer’s description of the problem is often a great starting point, and you can reach out to those customers to learn more, exploring the problem space further.
When customers ask for specific features, find out what problem they are trying to solve. Try asking, “If we built this feature, what would it help you achieve?” If you indirectly hear feature requests through your support or sales teammates, train them to ask customers about the problem they are facing.
Give detail and context about the user problem in your PRDs and project kick-offs. The problem statement should be more than one sentence. Give your teammates a full picture of the problem. Listen to your teammates' questions about the problem; these could be clues that you’re missing context and need to go deeper into the problem space.
When you’re exploring the problem space with your team, gently nudge them back to the problem space if the conversation moves to solutions too early. Write down solution ideas, but then put them aside and steer the conversation back to focusing on the customer’s problem. Try saying, “That’s a great solution idea; let’s come back to that after we completely understand the user’s problem.”
Now you know the difference between the problem space and the solution space, why you need to spend more time focused on problems, and what you can do to explore the problem space.
As the product manager, your job is to keep your team focused on solving the most impactful customer problems. When you explore the problem space, you will find real problems, know those problems completely, and get more creative with your solutions.
You got this!
Further reading
Want to learn more about this topic? Here are more resources to help you:
[YouTube] "Mastering the Problem Space to Achieve Product-Market Fit" by Dan Olsen at Mind the Product 2018 conference – Dan talks about how and why to focus on the problem space in this talk. He also covers this topic in his book, The Lean Product Playbook.
[Intercom Blog] Great PMs don't spend their time on solutions by Paul Adams, Chief Product Officer, Intercom – This post includes great visualizations showing how product teams typically spend their time. (Spoiler: they’re not spending enough time on problems!)
[Forbes] Think Like A Product Manager: How All Leaders Can Thrive By Thinking From The Problem Space by Jiaona Zhang, VP Product, Webflow – Jiaona explains how to think like a product manager (focus on problems) and why this way of working can benefit leaders even outside of product management.
[Product Talk] Opportunity Solution Trees: Visualize Your Thinking by Teresa Torres – A super helpful framework for exploring the problem and solution spaces with your team.
Referenced in this post
[Blue Ocean Strategy.com] Segway Case Study: Avoiding the Fate of the Segway Electric Scooter
[Product Talk] Opportunity Solution Trees: Visualize Your Thinking by Teresa Torres
Thanks for this. In the problem space, especially for new product ideas, are there ways to define how many prospective customers we should speak to?