Stop Jumping to Solutions and Think About the Problem

As an Experience Design consultant at Thoughtworks, I spend time with all kinds of product teams. Often I find they already have a list of features they want to build and are just looking for some innovative ways to make their design process more effective. Typically I start by taking a feature from this list and ask them a question that never fails to bemuse and frustrate. I ask, “What problem does this solve?”

I can read the follow-up questions on their face. Why do I need to understand the problem when I already have the solution? Why are we moving backwards? This feels like a waste of time, who is this guy?

Over and over again I have seen teams get lost by not understanding the problem they are solving. And over and over again I have seen strong resistance to taking simple steps to defining the problem. Why are people resistant to understanding the problem? Why is it so important in the first place? Why And what can teams do to break through?

Why We Don’t Value Understanding the Problem

Problems are abstract. They raise questions, assumptions and gaps in our understanding. They are uncomfortable. Solutions make the abstract concrete and provide specific answers to questions, even if they are just guesses. Solutions make us feel good.

Our brains are good at quickly getting to solutions. We often need to quickly get to solutions to communicate effectively. We assess our needs and subconsciously fill in details about what a successful solution might look like in order to be understood. You would not say, “my body is telling me I need food and I am craving something savory and salty.” You might just say, “Let’s go to Wendy’s.”

So jumping to solutions is comfortable and often necessary. It just happens to be bad for developing software products.

How Understanding the Problem Will Help You

The trouble with using solutions as the unit of discussion in product development is that they don’t include the intent. Someone hearing the solution — aka a feature — for the first time will have to reverse engineer the problem. They will come up with their own reasons for the why this is important and what the criteria for success is. Each person will fill in the blanks differently. As a result, people will start running in different directions from the beginning. As time goes on you’ll struggle to agree on interface details or what features to cut from an MVP because you do not have the same context for why any of this is important. It’s as if you are not speaking the same language.

Understanding the problem you are working on also gives you a powerful tool for communicating progress to your entire organization. Once you get support for a solution, you tend to become responsible for those exact features whether they are right or not. If you get organizational support for solving a problem that has measurable goals, you maintain room to change strategies as you get feedback from the market. If the goal is important and you are making progress towards the goal, it shouldn’t matter what features get you there.

An Approach to Defining the Problem

Writing a problem statement should not take much time. The important part is to do it collaboratively. Designers, developers, product people and the business all need to be present to write a problem statement. This will give everyone on the team focus and the same success criteria for evaluating solutions.

Before creating a problem statement, I recommend first presenting any relevant research and doing a competitive review. Present any research that gives insight into what the market opportunity is. Keep it high-level. If you are improving an existing product, print out all the screens in your workflow and hang them up. Do the same for a competitor. Walk through each with the team.

Now you have set the stage for writing a problem statement together. I like to start with this format, inspired by the problem statement  described by Jeff Gothelf in Lean UX:

Product offers a way for user to achieve goals. We have observed that the product is not meeting goals which is causing adverse effect. How might we do something so that user is more successful based on measurable criteria?

You can tweak the format, but the important things to include are:

• The target user

• The target user’s goal

• How the target user currently solves the problem, and where that solution falls short

• What we will do to provide a better solution to the user’s problem

• The measurable criteria we will use to evaluate success

Now the team has a common starting point for evaluating solutions and communicating intent. Write your problem statement on a board, hang it on a wall near the team and refer to it often. Circulate the problem statement outside the team. When reviewing solutions, encourage everyone to give feedback in the context how they address the stated problem.