Understanding Your Problem

Before deciding what to build, start by understanding the problem you want to solve. You do not need to know the answer to everything at the end of the incubator; the goal is to clearly explain the problem, explore possible approaches, and identify what you still need to learn. If your idea moves forward, you’ll have opportunities to refine your approach with your team.

The Problem

A strong problem statement should describe the current situation, not the solution you want to create. It should help someone who knows nothing about the project understand:

• Who is experiencing the problem?

• What are they trying to accomplish?

• What is making that difficult?

• Why does the problem matter?

• What happens because of the problem?

A common challenge is jumping from a problem directly to a technology solution. For example:

“People need better access to food assistance. We should build a website that puts all of the programs in one place!”

This may be the solution down the line. But at this point, we do not know enough to say that a website is the right solution. Instead, let’s start with the people and the problem first.

What makes it difficult for people to find and access food assistance?

By talking with people who experience the problem and organizations that work on it, you may discover that the problem is different from what you initially expected. You might learn that:

• Residents can find information, but the eligibility requirements are confusing.

• Residents know which program they need but cannot figure out which agency website to visit to apply.

• Information is available only in English.

• Some residents actually have no problem finding programs at all, but have trouble knowing whether information is current.

Each of these findings points toward a different way to address the problem. This is why it is important to understand the challenge before settling on a solution.

Once you have an initial sense of the problem, frame it as an open-ended question that leaves room for different approaches.

How Might We

How would you describe your problem to others? A good place to start is by creating a “How Might We” (HMW) statement. HMW statements frame a challenge as an open-ended question that can spark different ideas, rather than a traditional problem statement that simply defines a pain point.

Each of the three words matters:

• How: Signals that you are looking for a way forward.

• Might: Keeps the question open-ended.

• We: Signals that the solution will be developed collaboratively with others.

Let’s go back to our food assistance example.

Residents have difficulty finding and understanding the food assistance available to them. Information is spread across different programs and sources, making it difficult for people to determine what support they may qualify for.

How Might We: How might we make it easier for residents to find and understand the food assistance available to them?

Notice that the HMW statement does not prescribe a solution. There can be many ways to address the problem: a website, a community outreach program, better printed materials, changes to an existing service, or something else entirely.

Now compare that to a problem statement that jumps straight to a solution:

Problem Statement: Residents have difficulty finding information about available food assistance programs. We need to build a website that brings all of this information together.

Try it yourself by writing your own How Might We and thinking about how each of the three words matters.

Explore Many Solutions

Once you have an initial understanding of the problem, explore different ways to address it before committing to one solution. For example, if residents struggle to find food assistance programs, possible approaches might include creating a searchable website, simplifying existing informational materials, or improving how community organizations share resources.

In design thinking, blue-sky thinking is all about letting your imagination run wild before worrying about what is realistic. Think big! What would you build if you had all the time, skills, and resources you needed?

Instead of settling on the first idea that comes to mind, give yourself room to explore different possibilities. You don’t need to worry about what’s realistic right away. Once you have a few ideas, you can start comparing them based on their potential impact, feasibility, and the needs of the people you’re trying to serve.

• Crazy 8s: Fold a piece of paper into eight squares, then set a timer for eight minutes. Sketch one possible solution in each square, spending about a minute on each idea.

• Affinity Mapping: Write ideas on individual sticky notes. Then on a wall, group related notes into themes. This helps you identify common patterns.

• Impact–Effort Matrix: Map potential solutions according to their expected impact and the effort required to implement them. Use the comparison to discuss trade-offs, keeping community needs and your team’s capacity in mind.

Before You Move Forward

Use this checklist to pull together the basics of your idea to share it with others. Don’t worry about having the “right” answer to every question.

• The problem: Can you explain who experiences the problem and why it matters?

• Your How Might We question: Have you framed the challenge as an open-ended question that leaves room for different solutions?

• Possible approaches: Have you explored a few different ways to address the problem without committing to one solution too early?

• Potential impact: What would you hope to improve for the people affected by this problem? How might you tell whether your project is making a difference?

• People to involve: Who could help you better understand the problem, contribute different skills, or provide valuable feedback?

• Questions to explore: What assumptions are you making, and what would you need to learn before deciding how to proceed?

Next up, learn how to identify the people you need to build with and for.