Problem statement

A problem statement is a clear, concise description of an issue that needs to be solved. It defines who experiences the problem, what the problem is, and why it matters - without prescribing a solution. A good problem statement creates focus, aligns teams around shared understanding, and prevents the common trap of building solutions to problems that don't exist or don't matter.

Why it matters

Teams that skip problem definition often build the wrong things. Without a clear problem statement, solutions emerge from assumptions, preferences, or copying competitors rather than from genuine customer needs. The resulting features may be well-built but poorly aimed.

A strong problem statement provides several benefits:

Focus for ideation. When everyone understands the problem, brainstorming produces more relevant solutions. Without focus, idea generation scatters in unhelpful directions.

Criteria for evaluation. How do you know if a solution is good? It solves the problem. The statement provides the standard against which options are measured.

Alignment across teams. Engineers, designers, product managers, and stakeholders can all rally around a shared understanding of what they're trying to accomplish.

Prevention of scope creep. When new ideas emerge, the problem statement provides a filter: does this address the problem we're solving?

Anatomy of a problem statement

Effective problem statements share common elements.

Who is affected by the problem? Be specific about the user segment, persona, or stakeholder experiencing the issue.

What is the problem they experience? Describe the difficulty, pain point, or unmet need in concrete terms.

Where and when does the problem occur? Context matters - a problem that happens daily is different from one that happens rarely.

Why does it matter? What are the consequences of the problem remaining unsolved? Impact justifies investment.

What is explicitly excluded? Sometimes clarity about what you're not trying to solve is as important as what you are.

Writing a problem statement

Several practices produce better problem statements.

Start with research. Problem statements should emerge from evidence - user interviews, support data, behavioral analytics, market research. Statements based on assumptions are often wrong.

Be specific. "Users have trouble with onboarding" is too vague. "New users abandon signup when asked to connect integrations, with 47% drop-off at that step" is actionable.

Avoid embedding solutions. "We need a dashboard" isn't a problem statement; it's a solution. "Managers can't see team performance metrics in one place" is the underlying problem that a dashboard might solve - or might not.

Quantify where possible. Numbers make problems tangible. "Some users complain" is weak. "23% of churned customers cited this issue in exit surveys" is compelling.

Make it testable. A good problem statement implies how you'd know if you solved it. If success can't be measured, the statement needs refinement.

Problem statement formats

Various formats structure problem statements effectively.

The simple template:

"[User segment] needs a way to [accomplish goal] because [underlying need/motivation], but currently [obstacle/problem], which results in [negative consequence]."

The Five Ws:

Who has the problem? What is the problem? When does it occur? Where does it manifest? Why does it matter?

Point of View (POV) statement from design thinking:

"[User] needs [need] because [insight]."

How Might We converts problems into opportunity questions:

"How might we help [user] accomplish [goal] despite [obstacle]?"

The format matters less than the thinking. Choose whatever structure helps your team articulate the problem clearly.

Problem statement examples

Weak: "Our checkout is bad."

Better: "Mobile users abandon checkout at a 73% rate, compared to 45% on desktop, primarily due to the payment form requiring excessive scrolling and retyping information."

Weak: "We need better search."

Better: "Users searching for products can't find what they're looking for 34% of the time, leading them to browse competitors instead. Exit surveys indicate frustration with irrelevant results."

Weak: "Customers want reporting."

Better: "Account managers spend 4+ hours weekly manually compiling data from multiple sources to create client reports, reducing time available for strategic work and causing delays in client communication."

Common problem statement mistakes

Stating solutions as problems skips the understanding that produces good solutions. "We need a mobile app" isn't a problem; the problem is the underlying need that a mobile app might address.

Being too vague produces statements that could mean anything: "Users are frustrated." With what? When? Why? Vague statements don't guide solution design.

Skipping the "why it matters" fails to justify investment. Problems worth solving have consequences worth avoiding. If you can't articulate why the problem matters, maybe it doesn't.

Making it too narrow constrains solutions unnecessarily. "Users need a button to export data" is too narrow. "Users need to share data with external tools" opens more possibilities.

Making it too broad loses focus. "Users struggle with the product" is so broad it provides no guidance. Scope should be actionable.

From problem statement to solution

The problem statement is the foundation, not the destination.

Validate the problem before solving it. Is this actually a problem? Do users confirm it? Does data support it? Solving non-problems is expensive.

Generate multiple solutions. A well-defined problem typically admits multiple possible solutions. Explore options before committing.

Evaluate solutions against the statement. Does this solution address the problem as defined? Will it produce the outcomes that matter?

Measure success by problem resolution. After shipping, did the problem metrics improve? Did users confirm the problem is solved?

Problem statements and customer feedback

Customer feedback is the richest source of problem statements. What users complain about, request, and struggle with reveals genuine problems worth solving.

Tools like Klero help product teams extract problem statements from feedback by identifying patterns - the recurring themes that indicate problems affecting many users, not just one. When feedback analysis reveals that dozens of customers describe the same underlying issue, you've found a problem worth stating clearly and solving deliberately.