Problem Statement
A problem statement is a short, specific description of the problem a team intends to solve: who experiences it, in what situation, and why it matters to them and to the business. It deliberately leaves out solutions. In product discovery, it sets the scope of exploration and gives the team a shared target before anyone designs or builds anything.
How a Problem Statement Works
A useful problem statement answers a few questions in a few sentences:
- Who has the problem. A specific user group or segment, not "users" in general. Internal staff can be affected too.
- What the problem is and when it shows up. The situation, the task people are trying to complete, and where it breaks down.
- Evidence that it is real. What the team observed in research, support data, or analytics.
- Impact. What the problem costs the people affected, and what it costs the organization if nothing changes, such as lost revenue, churn, support load, or damage to reputation.
Nielsen Norman Group recommends keeping a problem statement to one problem and leaving solutions out, because early in discovery the team does not yet know enough to choose one. "We need a mobile app" is a solution in disguise. The underlying problem might be that field technicians cannot record job details until they get back to the office.
Some teams phrase it as an opportunity statement that contrasts the current state with the desired future state. The ingredients are the same: a clear gap, a specific group, and a reason to care.
Why a Problem Statement Matters
Teams often agree on a feature long before they agree on the problem. Writing the problem down exposes that gap early. It gives designers, engineers, and stakeholders one shared definition to test ideas against, and it makes scope decisions easier: if a proposed feature does not address the stated problem, it is out of scope for now.
It also keeps the work honest. A problem statement grounded in user research can be checked against new evidence and revised. One written from internal opinion tends to drift toward whatever solution the most senior stakeholder prefers. Later, the problem statement becomes the anchor for a Product Requirements Document (PRD), so each requirement traces back to a real need rather than a feature request. For a sequence that moves from segment and job to evidence and scope, see how technical founders scope a product before building.
Problem Statement Example
A team building invoicing software for freelancers sees more support tickets about late payments. Their first draft reads: "Add automatic payment reminders." That is a solution.
After interviewing a dozen freelancers, they rewrite it:
"Freelance designers who invoice several clients a month lose track of which invoices are overdue, because their invoices, emails, and bank deposits live in separate tools. Chasing late payments takes hours each month and delays their own cash flow. For us, the problem shows up as support tickets and as accounts that cancel after their first few months."
The new version names the group, the situation, the cause, and the impact. It also leaves room for several solutions, from reminders to bank reconciliation to a simple overdue dashboard, which the team can compare before committing.
Problem Statement vs. Hypothesis
A problem statement describes a need worth solving. A hypothesis is a testable prediction about a possible answer, for example: "If we send a reminder three days after the due date, more invoices will be paid within 30 days." The problem statement comes first. Hypotheses are how the team tests possible solutions to it.