The Problem Statement Creation Guide

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.

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.

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:

Read the full article here

Total
0
Shares
Leave a Reply

Your email address will not be published.

Prev
Doremus

Doremus

Omnicom-owned Doremus+Co has a century-long tradition of taking a

Next
New Brutalism and web accessibility: what you need to know

New Brutalism and web accessibility: what you need to know

Table of Contents Hide A brief history of New BrutalismNew Brutalism and

You May Also Like