Design Thinking

The Problem Statement: Unpacking Empathy to Define the Pain

Creating solutions without defining the problem is a form of malpractice: you can’t write a prescription without a diagnosis.

When we apply Design Thinking to our product delivery processes, we start with empathy so that we can truly connect with the customer or end user. 
It’s important to define the problem statement in order to move through to product creation. 

We remain agile throughout this process, because it’s very possible to get the problem statement wrong. 

Humans often think and say one thing, while actually doing and feeling yet another thing. As we addressed in Empathy: It’s How to Deliver Human-Focused Solutions, going beyond active listening is how we work to really get to the core of the problem.

We want to know a customer's intent as we define the problem statement. This illustration depicts a pair of giant ears behind a product team member who holds a clipboard.

“What is this person’s intent? What are they feeling? What are they hoping they can communicate to me in this moment?”

Creating a good problem statement requires extreme active listening. This is how we uncover that nugget of truth, that underlying pattern.

We listen, observe, ask, and really empathize.

When we create our problem statement, we know that we will have to check back in and challenge these assumptions often. That’s why we’re able to deliver the most agile, human-centered software solutions.

Figuring out what to solve, and writing a good problem statement

While defining the problem statement, we’re essentially making sense of our entire purpose.

We observe what our users are feeling, and we ask what they would like to be feeling when interacting with this type of product or experience.

Driving to have as many conversations as possible, we look to ask open-ended questions, and not describe any solutions. We let the user explain a problem, and ask them to explain how they’re currently getting around this problem.

As we do this, we take notes on each bit of friction they encounter. We listen to pain points and find out about other problems they’ve faced when trying to accomplish this task. 

Taking good notes – and comparing them

Gathering notes from this observation is a group effort. It takes many points of view to perform observation, and we really want to get the problem right so that we can get the solution right.

We take notes as we perform user observation. This illustration depicts two product team members as they arrange colored post-it notes on a whiteboard.

The notes we take might be physical: we’ll write observations on Post-It notes and stick them up on a board.

Or, our notes might be threaded: we’ll start a Problem Statement thread in Slack for the current project and drop notes into the thread.

A problem statement contains both a clear description of a problem and a potential method to go about solving the problem. So, our problem statement is written in the form of a “How Might We” question.

Moving on to take action with How Might We questions

From the notes on the challenges, our team will come up with these How Might We (HMW) questions that address the potential of the challenges that surface. And again, we can utilize Post-Its or Slack threads or just about any medium to collect these questions.

How to write a quality “How Might We” statement:

We come up with
  • It’s not too broad: “How might we build a better house?” generates too many unhelfpul ideas.
  • It’s not too narrow: “How might we build a door that swings inward and outward?” produces a solution within the question.
  • It’s just right: “How might we improve traffic flow in high-use areas of the house?” targets a segment and makes room for possibilities.

Narrowing it down: Getting to targeted “How Might We” Questions

Here’s the mechanism we use to surface the most promising HMW questions to address. The team takes 5 minutes to perform voting. By the way, this is a silent process. There is no discussion involved.

Each team member gets 3 votes. They can use those votes in any way they like: spread across three great questions, load up on one terrific question, or divide in another way. Sure, you can vote on your own submission! 

If this is happening in Slack, your vote is an emoji. If this is happening on paper, your vote is a dot placed on a Post-It. There are all sorts of ways to facilitate voting in any setting.

The top 2 or 3 vote getters are the best How Might We questions to address the problem at hand.

“How Might We” is the start of a beautiful question

Phrasing our problem statement in the form of a HMW question opens us up for idea exploration, so that we can ideate, prototype, and test solutions. We’ve opened ourselves up to really learn about what will delight our users, so that our product or business idea is sufficiently de-risked and on its way to success.

Remembering that we are creating human-centered solutions, our HMW question must also be human-focused. What does the user want to feel? What will an interaction with our product cause them to feel? The ability to delight a customer is directly tied to how they feel when using the solution you’ve built.

And your customers usually can’t tell you exactly what it is they need. So, you’ve got to come up with multiple possibilities. And you’ve got to test them.

Where are all these possibilities going to come from?

Read next: It starts with the premise that no idea is a bad idea.