
The Problem Statement Creation Guide
“Too often, leadership directs the product team through a feature-centric Product Roadmap — a set of outputs and features that they require the product team to produce by a specific date. Lean UX teams measure their success not in terms of completed features, but in terms of progress toward specific outcomes.” (“Lean UX”, Jeff Gothelf)
Users don't need features; they need to solve their problems and achieve their goals. We can be heroes at delivering new features, but if nobody wants them or they are not leading us to the business outcomes, what's the point of being so feature-obsessed?
I remember when my design lead introduced the Problem Statement exercise to me. It shifted my mindset of how I design solutions forever. This simple exercise helps you to understand if the problem is worth solving or not and also builds a shared understanding of the problem with the team. At the end of this article, you will know how to create the Problem Statement document and use it for your product.
Crystalize The Problem We Are Solving
Nothing is as strong a reason for the failure of a project as a lack of understanding of the problem we are solving.
To crystalize the problem, answer the following questions about your project in the Problem Statement document:
- Description: What is it?
- Problem: What user problem does it solve?
- Why: How do we know it's a real problem worth solving?
- Success: How do we know we've solved the problem?
- Audience: Who are we making this decision for?
Description: What is it?
In this section, write a brief description of the project so that the rest of the team members reading this document can quickly understand what this is about. Keep it short.
Problem: What user problem does it solve?
Think of the problem as a hypothesis. It helps the team to be open-minded and understand that the hypothesis might be wrong. The key attributes of a clear problem are:
- It's short. Aim for one sentence to describe the problem. The more we have to explain it, the less clear the problem will be.
- It's focused. Includes a single clear problem that a single team can be responsible for and resolve within a reasonable timeframe.
- It indicates a user's need. Try to focus on the user's needs and goals. If necessary, there may also be a business need.
- It includes what and why. What is wrong, and why is it a problem?
- It doesn't include a solution. Don't give in to the desire to quickly find a solution.
Why: How do we know it's a real problem worth solving?
Here include the evidence to support a problem. What convinced you that this was a real problem? What makes you understand that this problem needs to be solved? It can be insights from user research, data from the data analytics team, user requests for the support team, etc.
If you don't have enough data, it's a sign that you need to validate the problem through user research.
Sometimes in this step, we realize that this problem is not worth prioritizing. That's the point of this exercise, so don't resist it. There are an infinite number of problems that we need to solve — our task is to make sure that this problem is worth your team's time.
Here are a few tips:
- Look at both quantitative and qualitative evidence.
- Quality over quantity.
- Play devil's advocate with yourself. Try to convince yourself that this is not a real problem.
Success: How do we know we've solved the problem?
Here we need to answer a few questions:
- How will the team know that they have solved the problem?
- What business outcomes will the team achieve?
This criterion will become very important for the project as it will help you to make decisions and prioritize.
The team must shift its mindset from one based on features to one centered on outcomes. This shift is a radical one. Its product managers work to determine which business metrics require the most attention.
Audience: Who are we making this decision for?
The team can't solve the problem for "all of our users." Is this for new or regular users? Is this for mobile or web users?
In this section, include the link to your User Persona. So the team empathizes with who they are making this decision for.
Here is my article about the value of creating User Personas for business:
Here are a few more tips:
- The best time to create the Problem Statement is at the beginning of working on the new feature.
- Review the Problem Statement with the team. It will allow the team members to ask questions and align with the problem they are solving.
- Keep coming back to the Problem Statement after each iteration to update the data and track the achieved outcomes.
Thank you for reading, and I hope this article will help you to create a better user experience and achieve your business outcomes!