“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.” - Albert Einstein.
When a stakeholder comes to you with a request, do you take the time to really understand what the request is about? Do you ask yourself, why is the person asking for this? What is the context? Why now?
When you take a request at face value, you do a disservice to the requestor, because you have not applied your skills as a product manager. As product managers, we get requests all the time, and we disagree with many of them. When this happens, it’s our job to say “no." This doesn’t mean we refute the existence of the problem but rather the proposed approach to solving it. This leads to my favorite question, “What is the problem we’re trying to solve?”
It’s a simple yet effective question because only when you know what problem you’re trying to solve and define it clearly can you, the product manager, create an amazing solution.
Here are five key tips to help you properly define the problem.
1. Ask the “5 Whys”
Asking “What is the problem we’re trying to solve” is always a good first move, but what you will discover is that most people can’t answer it. For example:
- Stakeholder: I want Super Cool Feature.
- You: What is the problem we’re trying to solve?
- Stakeholder: Well the problem is that we don’t have Super Cool Feature.
This is why you have to ask the question more than once and in different ways. I like to use the “5 Whys” method developed by Toyota as part of its Six Sigma process improvement program. This method recommends asking “why” until you arrive at the root cause of the problem.
And no, you don’t just say the word “why” over and over again. And while you don’t have to ask it exactly five times, you should ask a series of questions until you get to the root problem. Here are some sample questions you can use:
- What is the problem we’re trying to solve?
- Why is that a problem?
- Why do we need this feature?
- How will this feature solve the problem?
- What are we doing today without the feature?
- Who would be the user of this feature, and how would they use it?
- Why is this an important problem to solve now?
For example, a stakeholder requested truck drivers be able to message their estimated time of arrival while en-route to a warehouse, which would have required teams to create a brand new messaging system. However, rather than saying no, I wanted to better understand why the request was made and see if there was a problem worth solving. Here’s how it played out:
The stated problem was “so that the warehouse knows when the truck is arriving.”
- Why?
- The Answer: “So that we have a spot available for them when they arrive.”
- Why?
- The Answer: “To ensure the building has enough capacity to handle incoming trucks.”
From here, I proposed a new problem definition: “I need to know what the plan is in advance so that I can ensure I have enough capacity to handle it.” Going back to the original request, we also picked out a second problem: “I need to know when the plan changes so I can prepare for handling the new plan.” With these statements refined and aligned, we proposed a good solution that wouldn’t require us to create a brand new app.
2. Understand the difference between a problem and a solution (hint: you can’t build a problem)
After all these questions, you might wonder when you’ve arrived at a “true” problem and not just another solution. Problem definition is more of an art than a science. Essentially, a problem stops us from achieving our goals, while a solution is something we can build.
Here are some examples:
- Solution: I need a faster horse
- Problem: It takes forever to get from place to place with my horse
- Alternate Solution: An automobile
- Solution: I need to create a version of the mobile app that can be used on a computer so I can copy and paste the control number into the form.
- Problem: Entering the control number in the mobile app is a manual process that slows me down and is prone to error.
- Alternate Solution: Stop requiring manual entry of the control number.
- Solution: I need a tool to keep track of which suppliers are non-compliant so I can fix their labeling for them.
- Problem: Some suppliers are non-compliant and that causes extra work for me.
- Alternate Solution: Work with suppliers to improve compliance and reject non-compliant deliveries.
- Solution: We can’t use the dashboard so we need a way to automatically produce and send an Excel report by email every week.
- Problem: The data that’s feeding into our dashboard is missing fields that only show up in the Excel report.
- Alternate Solution: Feed additional data fields into the existing dashboards.
3. Use Contextual Inquiry or Story-Telling
Contextual Inquiry, also called “shadowing,” is a fancy way of saying, “ask people questions while they’re having the problem.” Ideally, it involves observing your customers in their natural environments as they do tasks related to the problem you want to understand. Kind of like product ethnography, this approach provides much more information than you will get asking questions over the phone or in a conference room.
If you cannot observe customers in their natural environments (hello COVID), use a story-telling approach to discover the context around the request. Try questions like these:
- Take me through a typical day. What do you do first? What do you do next?
- What kinds of interruptions do you have to deal with while you’re trying to accomplish your task?
- Do you always have enough information to make that decision? If you don’t, what do you do about it?
- Think about the most recent time you did this task. Walk me through the process step by step. Did it go completely smoothly, or were there problems?
Remember, you’re talking to them to define the problem, not the solution. By asking “why” they want the solution, you will get a lot closer to defining the problem than not talking to them at all.
4. Collaborate with Your Stakeholder
It’s best to work collaboratively with your stakeholder on the problem definition. This is especially true if it is an internal stakeholder. If you have more than one, bring them together, especially if you sense they disagree on the problem. Think of this as an interview or a brainstorming session, where you’re helping the stakeholder(s) more clearly express their ideas and opinions. Even if you end up implementing the exact feature they’re asking for, you still need to understand the problem to know whether or not the feature is successful in the end.
If you’re not sure how to position the exercise, you can say “That’s a really interesting idea. I’d like to ask a few questions, just to make sure I understand what you’re asking for.”
One way to do this exercise is to create a shared document and take notes as you ask your 5 Whys. You may write down several solutions disguised as problems, and that’s ok because it shows your stakeholder that you are listening. Eventually, you will get to the actual problem while at the same time having documented the thought process that got you there.
The last method I’ll mention here is a sticky note exercise, sometimes called Affinity Mapping, where you work together to create and organize sticky notes into themes. This exercise is beneficial in a complex space where multiple problems are in play or when multiple stakeholders have differing opinions on the problem or solution. This exercise allows you to discover problems from solutions because you’re forced to articulate what’s common among groups of solutions.
5. Iterate on the Problem Statement
In the end, remember that asking lots of questions and listening to your stakeholders is unlikely to deliver the problem statement on a silver platter. They may not ever come up with a problem statement. However, by using your interview skills, you can infer what the problem is, propose a problem statement, and then iterate on it with your stakeholders to come to a final agreement.
This process can take time, but once you get there, and you will get there eventually, you are now ready to get going on your solution to the problem. By going through this process you’re almost guaranteed to create a more successful solution than directly implementing the original request.
