How to make sure you’re solving the real problem

A common refrain for product people is to make sure you’re trying to solve a problem, not just deliver a prescribed solution.

That is definitely great advice, but how do you know you’re solving the real problem?

It’s easy to take a look at a solution you’ve been asked to deliver, such as “I need this report” or “let’s install Salesforce” and identify the problem that those suggested solutions are intended to solve.

But that problem could be a symptom of a deeper problem. A problem that if solved properly can clear up the symptom driving the need for a report and several others.

Here are some ways I’ve found helpful for getting to the real problem in an effective manner.

Pop the why stack

I think there is a law written somewhere that an article about solving the real problem cannot be published if it doesn’t mention the 5 Why’s.

I tend to use a phrase I heard from Chris Matts (who heard it from others) – popping the why stack – but it’s the same idea.

The premise is that when you receive a request, keep asking why? (or some form of that) until you understand a reason behind the request that adds value to your organization.

Asking why five times can you make you look quite pedantic, so it’s always helpful to come up with ways to disguise your curiosity. I compiled a list of ten alternatives to asking why. Chris Matts also suggested 21 other ways.

Popping the why stack can be a good starting point that leads to a couple more involved approaches.

Socratic questioning

The next step may be to ask questions, but not just repeat the same type of question over and over again like a five year old trying to find out why the sky is blue.

You may want to have a series of questions that provide some context around the request and helps the person who came up with the request arrive at the real problem themselves. This is the idea behind socratic questioning.

Socrates used this approach to teach his students. You can use it to refute or disprove your stakeholder’s thesis (that a particular solution will solve a problem and that problem is the root issue) and then get to the real problem.

Here’s a line of questioning you can use to get to the real problem adapted from a list that by Brennan Dunn uses to understand the true needs of his web development clients:

• What is the desired change?
• When did you realize you needed to make this change?
• What problem does this change solve?
• What is the impact to your organization of that problem?
• How much does that problem cost your organization?
• How should tomorrow look after we’ve solved this problem?
• What are the next steps?

This is the next step beyond popping the why stack because it also helps you to understand the impact of the problem which gives you some insight into whether it’s the real problem to solve.

You can also use socratic questioning to explore related problems and see if there is a similar issue underlying all of them.

Identify a specific outcome

A final way to find the problem is to identify a specific outcome that you’re trying to achieve. The outcome is some target that your organization is trying to reach, expressed as an outcome based metric. That metric basically measures whether you’ve solved an underlying problem.

For example, a membership organization wants to continue to grow membership, so it might establish an outcome based metric of new or renewed memberships per month.

If you can’t come up with specific outcome based metrics and your organization doesn’t have any clearly stated metrics, you can walk back from the original feature request using the idea behind the impact mapping technique.

Gojko Adzic suggests the following approach in his book Impact Mapping: Making a Big Impact with Software Products and Projects*:

If you can’t find any objectives, start with suggested features and ask whose behaviour will this change and in what way. Then ask why those behaviour changes are important.

How have you found the real problem?

These three approaches basically suggest that you don’t just take a solution request as given without digging to understand the real problem underlying it, and don’t accept the first stated problem as the real one.

I’ve described some approaches I’ve used to find the real problem. I have no doubt there are others. If you’ve got a unique way to find the real problem, share it in the comments.

---

*This is an affiliate link. When you follow this link and purchase something from Amazon, whether it’s the item or not, KBPMedia receives a small commission, and you pay nothing extra. This is a great way for you to show your support without having to pay anything extra out of pocket. If you take advantage of that, thank you!