Problem statement

Overview

A problem statement is a clear, concise, evidence-based description of a specific problem or pain point that users or customers experience. Effective problem statements move beyond vague complaints to articulate the who (which users), what (what exactly is the problem), why (why does it matter), and how it's currently affecting outcomes. Problem statements serve as the foundation for product work—they establish shared understanding across teams about what problem is being solved and why it's worth solving. A strong problem statement prevents teams from pursuing solutions in search of problems, instead grounding product development in real user needs. Problem statements are distinct from solution descriptions; a poor problem statement might jump directly to "we need to build a mobile app," while a strong one would first establish the underlying user problem that a mobile app might solve.

Why Are Problem Statements Essential in Product Development?

Problem statements are the essential foundation that enables effective product strategy and execution. A clearly articulated problem statement aligns teams across product, design, engineering, and leadership around a shared understanding of what they're trying to solve. This alignment prevents wasted effort—teams working from different assumptions about the problem often build solutions that don't fit together or miss the actual user need. Strong problem statements also prevent premature solution commitment by ensuring teams fully understand the problem before choosing how to solve it. Additionally, problem statements provide decision-making criteria; when trade-offs arise during development, teams can refer to the problem statement to evaluate whether potential compromises still address the core issue. Finally, problem statements create accountability and measurability by defining what success looks like—if the problem is "customers spend 45 minutes on manual data entry," success means reducing that time significantly.

When Should You Write and Validate Problem Statements?

Problem statements should be developed early and revisited throughout product development. Create and validate problem statements in these scenarios:

• Discovery phase before solution development begins: Write problem statements during research and discovery to ensure you've truly understood user needs before committing engineering resources to building solutions.

• Before starting major new initiatives or features: Before beginning work on any significant project, articulate the problem you're solving to ensure alignment and provide a filter for design and implementation decisions.

• When stakeholders disagree about direction: When teams or stakeholders have different views about what should be built, articulating the underlying problem statement often reveals whether you're disagreeing about the problem or just the solution.

• Periodically as you learn more: Problem statements should evolve as you learn more about users and context; revisit them quarterly or when significant new information emerges.

What Are Common Weaknesses in Problem Statements?

Many teams create problem statements that are vague, biased, or miss the actual user problem. Common weaknesses include starting with assumed solutions rather than problems ("we need a dashboard" rather than "users can't quickly find the information they need"), focusing on implementation details rather than user impact, and being so broad they don't guide decisions. Other problematic problem statements are based on anecdotes rather than research, lack evidence showing the problem is actually important, or conflate symptoms with root causes. Some problem statements embed assumptions about who the customer is without validating those assumptions. The most dangerous problem statements sound compelling but lack actual evidence—a well-articulated problem statement based on one user's complaint can misdirect an entire team.

How to Write and Validate Strong Problem Statements

Start by gathering evidence about the problem through user research, interviews, support tickets, and behavioral data—problem statements should be grounded in evidence rather than intuition. Structure your problem statement to answer four questions: Who experiences this problem? What exactly is the problem? Why does it matter or what impact does it have? How frequently or severely does it occur? Write the problem statement in user-centric language focused on impact rather than solutions; avoid jumping to "we need X feature" and instead articulate "users can't accomplish Y because of Z." Validate your problem statement by sharing it with representative users and asking whether they recognize the problem you've described; if they don't immediately relate to it, your understanding may be incomplete. Consider alternative problems that might also be present, testing whether the problem you've identified is truly the highest-leverage opportunity. Finally, include a metric or success criterion in your problem statement so you can eventually measure whether solving this problem actually delivered value.