Don’t bring me a Solution, bring me a Problem
It’s a very common advice when entering the workplace to “go to your boss with solutions, not problems.” The sentiment of this advice is good. You should spend time thinking through possible solutions in order to hone your problem solving skills. And giving your boss insight into how you’re thinking about a particular problem will help them support your growth while you solve this problem.
The place where this advice really doesn’t work? Product development.
As product managers, we are often surrounded by people who have internalized this “solutions, not problems” mentality. How many times have we heard the user request “I need a button that does X?”
Usually, if you ask a few more questions, you’ll find that a button is not necessarily the thing that would solve their problem. And a solution provided in this way does not give more context about the problem the user is facing. In fact, it completely obscures it. So if we implement the user-suggested solution without asking more questions, we may not be solving right problem at all (a cardinal sin of product management).
With most users or customers, you’re never going to get them out of it the habit of suggesting solutions, and that’s ok. (You never want to discourage people from offering ideas and collaborating on solutions anway.) The most valuable thing you can do as a PM is to get really good at asking questions that help you better understand your user’s “why.” When a request comes in, ask why. And then do it again, and again, asking “why” up to five times or more until you get to the core problem they are facing.
For one of my client’s customer interviews, it looked something like this:
I need a button that lets me download this candidate data.
What can you do with a download that you can’t do in the app?
I need to download it so I can filter and sort the candidates.
What value does filter and sort for candidates provide?
I only want to look at candidates that fall in the top 10%.
What’s meaningful about candidates that fall in the top 10%?
I can only offer interviews to a few people so I want to ensure that I’m looking at the best candidates.
Ok, and how would you define the best candidates?
So now we’re getting somewhere with this user request! After further discussion, it sounds like as long as we are able to give our user a way to access the “best candidates,” we could achieve this in a number of ways. We also have a lot more context about their need/use case, which means we can think more creatively about how to help them achieve this goal in future features too.
If we had just built a download button, we may not have solved this problem at all or, worse yet, created a different problem to solve. The biggest shift that we’ve made in how we understand a user request is that we are focused on the outcome, what someone needs to be able to do or achieve as a result of this work, and not the output, the specific solution or implementation.
In addition to having a better understanding of the true needs and problems of your user, outcome-focused development also keeps the solution space wide open, which is where your product squad can really shine. With an outcome and information you’ve gathered from your customer and user interviews, you’re set up a for an interesting, productive, and way more fun conversation with your squad, not to mention and a much higher likelihood of delivering a solution that adds true business value.
So when user problems disguised as solutions come your way, ask questions; lots of them. Be sure you understand the actual problem to be solved, so you can focus on the outcome, and not the output. This leaves your team free to generate the best possible solution, which means happier teams and more satisfied users.
