Solutions Are Easy, Focus On Problems

When we recognize pain around a process it is a natural tendency to jump straight to figuring out how to alleviate it. We immediately try to come up with a solution to whatever the problem is. This is almost always premature and ultimately ends up hindering progress, especially if you are managing a team.

As a software engineer, clients or co-workers have come to me hundreds of times with features they believe we need to implement. They come with the solution they want to see implemented rather than just describing the problem, which is usually a recipe for wasted time.

Focusing on the solution too early distracts you and your team from truly understanding and effectively solving the problem. You focus on the implementation of the proposed solution, regardless of its flaws. This is especially dangerous when you are in a leadership position because it’s less likely your team will be comfortable providing the candor necessary to course correct if you are off track.

The best thing you can do when you recognize a problem is to dig as deep as you possibly can to understand it. You don’t need to think about the solution, because that is going to fall in to your lap once you fully understand the issue.

It’s hard to break the habit of jumping to solutions, but the good news is that understanding problems doesn’t require any hard skills. You don’t need to be a developer or a UX expert to dig deeper and fully understand a problem. You just need to learn to ask the right questions and keep yourself from thinking about solutions.

Real World Examples

I used to work for a company that maintained software for ISP call centers. People would call in with issues and network engineers would use the software to troubleshoot their issues. It was our job to make it easy for the people answering calls to get the information they needed to diagnose and fix customer problems quickly.

We released an update to our UI that changed the format of MAC addresses from “abcd.1234.abcd” to “abcd1234abcd” and quickly received a request to change them back to the old format. This request wasn’t questioned when it came in and made its way in to our backlog to implement. Luckily one of my co-workers recognized there was probably a deeper issue here.

It turns out the engineers wanted the addresses in this format because it made it easy for them to copy and paste in to their terminal so they could log in to the devices and check statistics on their own. This meant that they were completely bypassing our software!

It turns out there were some very deep issues here and that the technicians didn’t even trust the software because they had received out of date information in the past which provided false positives. Needless to say, the format of those MAC addresses was the least of our worries!

One more quick example…

I was doing some consulting for a client who was trying to figure out ways to improve their onboarding process for new customers. They had a system that needed to be deployed and used by patrons of their customers at their brick and mortar locations. They were discussing a new drag and drop interface they wanted to build to make a configuration screen in the onboarding process more efficient.

This was my first call with them so I wanted to know more. Given all the other development needs they had, this seemed like it had a relatively low ROI, so I was looking for other quick wins we could find in the onboarding process. I asked what the most time consuming process was and it turned out there was one step in the onboarding process that took 4 to 6 hours!

This process was extremely labor intensive because it was customized to each new customer they acquired. Also, it was originally added to the onboarding process because of some assumptions about the value it would provide, but those assumptions had never been tested. We ended up being able to remove the customization piece of this step and take this process from 4 to 6 hours per customer to just 5 minutes.

This was a much bigger win than we could have ever hoped to achieve through the UI updates we were discussing, and that is exactly the danger in focusing on solutions. The drag and drop UI was fun to think about, so it was natural to jump to it.

A Framework For Understanding Problems

Because it’s so hard to resist the temptation of jumping to solutions, I’ve started leaning on a couple systems for doing discovery to fully understand problems before starting to solve them. Here are the two I use most frequently.

The 5 Whys

It may sound childish, but simply continuing to ask “why” can sometimes reveal fascinating insights. This technique was formalized in the manufacturing industry. However, as with most lean principles, it is equally relevant in software.

The next time someone tries to push a need or want on you (e.g. “We need the software to…”) push back with some “why”s. I guarantee you’ll uncover much larger issues that aren’t going to be resolved by the proposed solution.

Problem Interviews

This technique requires a little more planning, but can produce some really powerful results. The goal of this exercise is to figure out if you have a problem that is worth solving.

You start with answering the following questions:

  1. Who is the prototypical early adopter?
  2. How badly do they want this problem solved?
  3. How do they solve it today?

Once you come up with your answers, you write a script that you can run through in interviews with people in your customer segment (the people who fit the characteristics defined in your answer to question #1).

Check out The Achilles Heel of Customer Development for more information on how to effectively communicate with customers.


Armed with this new knowledge and skepticism, take a look at your current backlog of work. See if anything stands out and if there are opportunities to dig deeper to fully the problems that you are trying to solve.

Please let me know if this exercise is helps you and your team. I’d love to hear about what you uncover.