Problem Solving: Defining the Problem
Saturday, March 8th, 2008In a series of posts on problem-solving, I will be sharing my personal approach to finding and evaluating solutions. At times, I may also evaluate other methods or draw from other resources, in which case references will be cited at the end of the post. This is the first post in the series.
Defining the Problem (or in most cases, problems)
My first step in solving a problem is to clearly define the problem. This may seem obvious, but I have found most people skip it. I work in the internet industry spending most of my career at early-stage startups and have encountered the following scenario more times than I can count. It illustrates the need to clearly define the problem.
At some point your team realizes you are behind schedule, customers are knocking down your door asking for more and more features and your engineers are working around the clock. Meanwhile, your site stability needs to be improved and you have a growing list of bugs. What do you do?
It’s easy to feel overwhelmed by this scenario, especially in a startup where the vision is grand, but the day to day grind is tough. There are a few simple steps you can take to fend off feeling overwhelmed. The most effective one is to list out the problems and to focus on each one at a time.
In our scenario, we can separate the following problems:
- you are behind schedule
- customers are getting antsy
- your engineers are at risk of burning out
- site stability is putting your business at risk
- the quality of your product is at risk due to the growing bug list
Looking at each of these in turn, not only fends off feeling overwhelmed, it also introduces a whole new set of solutions. For example, if we look at all of these problems together, we will probably decide, we need more engineers. This is probably true, regardless of how we look at the problem, but this solution may take time. By looking at each problem independently, we can look at other solutions that we can pursue in parallel.
Let’s brainstorm for a minute.
You are behind schedule, what can you do besides hire more engineers?
- Reduce the scope: cut out anything that isn’t a must-have.
- Identify acceptable short-cuts that can be addressed after the release.
- Release incremental progress in exchange for more time.
Customers are getting antsy, what can you do besides hire more engineers?
- Be transparent. Send regular updates of development progress, including screenshots.
- Release incrementally so they can use what you have now, but know more is coming.
- Start a beta program and allow customers to help test your software.
You get the idea. We can do this for each of these problems and generate many possible solutions besides the most obvious (and most costly in both time and money) of hiring more engineers.
I’ve found that when you can only come up with one solution, you probably haven’t defined the problem correctly. The goal is to define the problem such that it becomes easy to identify solutions.
A well-defined problem meets the following criteria. The problem is defined such that:
- Generating solutions becomes easy.
- All stakeholders agree that solving this problem addresses their needs.
- One and only one problem is represented.
To clarify, the last point, this doesn’t meant that a single solution can’t solve multiple problems. But by defining problems one at a time, you set yourself up to generate more possible solutions.
As we’ve seen, defining the problem this way, makes it much easier to generate solutions. But how do we know which solutions are the right ones. In the next post, I’ll walk through my process for defining constraints. This is a critical step for making sure all stakeholders are satisfied with the final solution.