Problem Statement

What Is This?

Overview

A problem statement is a structured, user-centered description that captures the core friction a specific user experiences when trying to accomplish a goal. Rather than jumping directly to solutions, a well-formed problem statement forces teams to articulate who is affected, what they are attempting to do, what is blocking them, why that block exists, and how the situation makes them feel. This empathy-driven framework ensures that product decisions are grounded in real user pain rather than assumptions or internal priorities.

The problem statement skill draws from design thinking and product discovery practices. It provides a repeatable format that product managers, designers, and engineers can use to align on the nature of a problem before any solution work begins. When teams skip this step, they risk building features that address symptoms rather than root causes, or optimizing for the wrong user entirely.

Used during discovery, prioritization sessions, or when writing a Product Requirements Document, a strong problem statement becomes a shared reference point. It reduces misalignment in stakeholder conversations and gives teams a clear criterion for evaluating whether a proposed solution actually addresses the identified problem.

Who Should Use This

• Product managers framing discovery work or writing PRDs who need to anchor requirements in user pain
• UX researchers and designers who want to communicate user insights in a format that resonates with engineering and business stakeholders
• Engineering leads who need to understand the "why" behind a feature request before committing to a technical approach
• Startup founders and product owners defining their core value proposition and validating that a real problem exists
• Agile teams running sprint planning or backlog refinement who want to ensure each item traces back to a user need
• Business analysts translating stakeholder requests into user-centered requirements for development teams

Why Use It?

Problems It Solves

• Teams build solutions before fully understanding the problem, resulting in wasted development cycles and low adoption
• Stakeholders argue about features without a shared definition of the user problem being addressed
• Discovery work lacks focus because there is no clear articulation of who is affected and what they need
• PRDs describe functionality without explaining the user context, making it difficult for engineers to make good implementation decisions
• Prioritization debates stall because there is no agreed-upon measure of user impact to compare against

Core Highlights

• Follows an empathy-driven framework that captures user identity, goal, blocker, root cause, and emotional impact
• Provides a single-sentence or short-paragraph format that is easy to share and reference across teams
• Aligns stakeholders on the problem space before any solution discussion begins
• Serves as an evaluation criterion for proposed solutions during design and development
• Integrates naturally into discovery documents, PRDs, and sprint planning artifacts
• Encourages teams to separate problem definition from solution ideation
• Scales from small feature requests to large strategic initiatives

How to Use It?

Basic Usage

The core format for a problem statement follows this pattern:

[User type] needs a way to [accomplish goal]
because [root cause of the problem],
which makes them feel [emotional impact].

A filled-in example looks like this:

A first-time homebuyer needs a way to compare mortgage options
across multiple lenders in one place,
because current tools require visiting each lender's site separately,
which makes them feel overwhelmed and unsure they are making the right decision.

Specific Scenarios

Scenario 1: Framing a discovery sprint. Before running user interviews, write a draft problem statement based on existing signals. Use interview findings to validate or revise each component, particularly the emotional impact and root cause sections.

Scenario 2: Writing a PRD. Place the problem statement at the top of the document, before any solution or requirements content. This gives reviewers immediate context for why the work matters and who it serves.

Real-World Examples

A SaaS company noticed high drop-off during onboarding. Their problem statement read: "A new enterprise user needs to configure their workspace without IT support, because the setup wizard assumes technical knowledge they do not have, which makes them feel blocked and likely to abandon the product."

A mobile banking team used the format to reframe a feature request: instead of "add a spending chart," they wrote a problem statement that revealed users needed confidence that they would not overdraft, which led to a different and more effective solution.