This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. By clicking the consent button, you agree to allow the site to use, collect and/or store cookies.
Please click the consent button to view this website.
I accept
Deny cookies Go Back
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

KBP Media

Just-in-time resources for product people

  • About
  • Blog
  • Contact
  • Follow
  • Login

Kent McDonald / January 14, 2019

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!

Filed Under: Product Management

Inside Product

Get the free ebook Product Ownership in the Wild to find out about common product ownership models and receive Inside Product, a weekly roundup of resources for product people who want to deliver powerful internal products.

Your data will be handled according to our Privacy Policy.

« 4 Product owner assessments to help you focus your learning efforts
The benefits and pitfalls of outcomes over outputs »

Reader Interactions

Comments

  1. Robin Goldsmith says

    January 26, 2019 at 10:59 AM

    My book, Discovering REAL Business Requirements for Software Project Success*, is all about applying the systematic disciplined powerful Problem Pyramid™ to first get the REAL Problem right far more effectively than too often actually occurs relying solely on the too-easily superficial and deceptive techniques described in the article. You can find a shorter description in my Modern Analyst featured article, “BAs Will Falter Until They Learn to Discover REAL, Business Requirements”.

    Reply
    • Kent McDonald says

      January 26, 2019 at 11:19 AM

      Hi Robin,
      Thanks for your comment and for suggesting an alternative resource. While I’m not sure I’d describe the suggestions I offered as superficial or deceptive, I have found that they are easy to remember in the heat of a discussion and have worked for me. Of course your mileage may vary.
      – Kent

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search this Site

Free eBook and More

Join our Free Member Content Library and receive access to all our free content, including the free eBook: Product Ownership in the Wild!

Sign Me Up!

RSS Inside Product Latest Issues

  • Ask questions to get a better understanding February 13, 2019
  • How to communicate with stakeholders February 7, 2019
  • What makes a good outcome based metric? January 31, 2019
  • Why focus on outcomes? January 24, 2019
  • How to identify the real problem January 17, 2019

Connect

  • Email
  • Facebook
  • LinkedIn
  • RSS
  • Twitter

Footer

Contact Us

112 N 1st Ave

Winterset, IA 50273

515.344.3290

About Us

KBP.Media provides services and resources that help product people deliver powerful internal products. 
Learn More

Inside Product

Get a weekly rundown of just in time resources for product owners, business analysts, and product managers. 
Signup

© 2019 KBP Media · Rainmaker Platform

Privacy Policy

  • Home
  • About
  • Contact
  • Privacy Policy