Lesson 17: Problem Statements

Across the last several lessons, you've built a genuine research pipeline: interviews and surveys (Lessons 12–13) feeding personas and journey maps (Lessons 14–15), which surface multiple pain points that you now know how to prioritize using severity and frequency (Lesson 16). What you don't yet have is a single, disciplined artifact that captures the specific, validated, prioritized problem you've decided to solve — in a form precise enough that a team can actually be held to it, and specific enough that success or failure can later be judged against it rather than argued about.

A problem statement is a concise, structured articulation of a validated, specific problem — who experiences it, in what context, what job it interferes with, and what evidence supports its importance — written deliberately without a proposed solution attached. This last point is the crux of the entire lesson: a problem statement's job is to hold a team's attention on the problem long enough to consider multiple possible solutions, rather than letting the first plausible solution smuggle itself into the framing before alternatives have even been considered.

Learning Objectives

1
Define a problem statement and construct one using a structured, solution-free template.
2
Explain why a problem statement must exclude any proposed solution, and identify the specific risks of solution-contaminated framing.
3
Distinguish a well-scoped problem statement from one that is too broad (unactionable) or too narrow (already a disguised solution).
4
Apply evidence citation within a problem statement, connecting it directly to laddered pain points (Lesson 16) and research findings (Lessons 12–13).
5
Use a problem statement as a shared reference point for evaluating whether a proposed solution actually addresses the stated problem.

Lesson 6 (Jobs To Be Done) and Lesson 16 (Pain Points). This lesson assumes you can ladder a stated request to its underlying job and can characterize a pain point's severity and frequency with real evidence — a problem statement is the formal artifact that packages this prior work into a single, reusable, solution-free reference point.

The Core Definition and Template

A problem statement articulates a specific, validated problem without proposing how to solve it. A widely used structural template:

[Specific persona/segment] experiences [specific pain point, laddered to its root cause] when trying to [specific job to be done], particularly in [specific context/circumstance]. This matters because [evidence: severity, frequency, and business or user impact].

Every clause here is deliberate. Naming a specific persona or segment (Lesson 14) prevents the vague, undifferentiated "users" that plagues so much product communication. Naming the specific, laddered pain point (Lesson 16) — not the surface-level version — ensures the team is working from a validated root cause rather than a first-pass symptom. Naming the specific job (Lesson 6) anchors the problem in what the person is actually trying to accomplish, not in the product's own internal feature vocabulary. Naming the specific context prevents an overly generalized claim that doesn't actually hold across every circumstance. And explicitly citing evidence keeps the statement honest and falsifiable, rather than a plausible-sounding but ultimately unverified assertion.

Why Solutions Must Be Excluded

The single most important discipline in writing a problem statement is the deliberate, total exclusion of any proposed solution. This might seem like an arbitrary stylistic rule, but it addresses a specific, well-documented cognitive trap: once a solution is named, even in passing, it becomes extraordinarily difficult for a team to genuinely consider alternatives — the named solution anchors all subsequent thinking, discussion, and even the framing of "success," precisely the anchoring effect Lesson 12 warned about in the interview context, now operating at the level of an entire team's problem-framing process.

Consider the difference between:

Solution-contaminated (weak): "Enterprise customers need a dark mode option because their eyes get strained during long working sessions."
Solution-free (strong): "Enterprise power users, who report working in the product for multiple continuous hours, experience visual fatigue during long working sessions, particularly on their evening or late-shift usage; this affects roughly 30% of daily active enterprise seats per session-length analytics, and several report reducing time-in-product as a workaround."

The second version leaves entirely open which solution best addresses the fatigue problem — dark mode is one candidate, but so are adjustable brightness controls, scheduled break reminders, session-length-based UI simplification, or something else the team hasn't yet considered. The first version has already, silently, foreclosed all of these alternatives before a single discovery conversation (Lesson 8) has taken place.

Scoping: Too Broad vs. Too Narrow

A well-constructed problem statement must be scoped correctly, avoiding two opposite failure modes:

Too broad: "Users find the product hard to use" is so general it provides no meaningful direction for discovery or design — it fails to name a specific persona, a specific pain point, or a specific context, and could describe almost any product issue at all. This mirrors Lesson 7's "for everyone" value proposition failure and Lesson 9's generic-vision failure, applied at the level of problem framing.
Too narrow (a disguised solution): "Users need a one-click export-to-PDF button" is not actually a problem statement at all — it is a solution wearing a problem statement's grammatical structure, having smuggled in exactly the kind of premature commitment this lesson warns against, without even the courtesy of stating it as an explicit proposal that could be debated as such.

The correctly scoped middle ground is specific enough to be actionable and falsifiable (a team could, in principle, determine whether it has actually been resolved) while remaining entirely agnostic about which solution will resolve it.

Evidence Citation Within a Problem Statement

A problem statement should cite the specific evidence supporting its claims — directly connecting back to the research techniques covered throughout Module 2. This might include:

A specific, laddered pain point (Lesson 16), with its established severity and frequency.
A specific finding from past-behavior interviews (Lesson 12), ideally including a real (never fabricated, per Lesson 14's quote-sourcing rule) representative account.
A specific, validated prevalence figure from survey or behavioral data (Lesson 13).
A specific business or strategic consequence tied to the problem (e.g., churn risk in a segment where users and customers are the same person, echoing Lesson 5's Detailed Case Study).

A problem statement without cited evidence is, in effect, an unvalidated assumption wearing a formal-looking structure — precisely the same risk Lesson 14 warned about regarding personas built without research grounding, and Lesson 11's general warning that polished presentation does not confer trustworthiness.

Using a Problem Statement as a Shared Reference Point

Once written, a problem statement's most important ongoing function is as a shared reference point for evaluating proposed solutions later in the process. Given any proposed solution, a team can ask: does this solution actually address the specific persona, pain point, job, and context named in the problem statement — or does it address something adjacent, or something the team has drifted toward without checking? This is directly analogous to Lesson 7's Value Proposition Filter and Lesson 9's Vision Filter, but operating at the level of an individual initiative's problem framing rather than the product's overall strategic direction.

A team that skips writing an explicit problem statement, and instead moves directly from a vague sense of an issue to a specific proposed solution, loses this checking mechanism entirely — there is no stable, solution-free reference point against which to later ask "wait, does this actually solve what we set out to solve?"

Common Mistakes to Avoid

Including a proposed solution within the problem statement itself

Even a brief, seemingly harmless mention of a candidate solution anchors the team's thinking and forecloses genuine consideration of alternatives before discovery has even started.

Writing a problem statement so broad it provides no real direction

"Users find this hard to use" fails to name a specific persona, pain point, or context, and could describe almost any product issue — it hasn't actually done the work of specifying a real problem.

Writing what is actually a solution, disguised in problem-statement grammar

"Users need a PDF export button" smuggles in a specific solution without acknowledging it as a proposal, skipping the deliberate solution-agnostic framing this lesson requires.

Writing a problem statement with no cited evidence

A statement built on assumption rather than laddered pain points (Lesson 16) and research findings (Lessons 12–13) is an unvalidated guess dressed up in a formal structure.

Never returning to the problem statement once a solution has been proposed

Without actively using the problem statement as a filter for evaluating the eventual proposed solution, the artifact loses its most important practical function and risks becoming another instance of Lesson 14's "decoration" failure pattern — well-written but never actually used.

Mental Model

The Problem Statement Purity Test

This lesson's mental model is the Problem Statement Purity Test — a quick check for whether a draft problem statement has smuggled in a solution.

Apply this test to any draft problem statement before finalizing it: can you name at least five meaningfully different candidate solutions that would all be consistent with the statement as written? If you can only think of one, the statement has very likely already smuggled that one solution in, whether or not it was named explicitly.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Problem Statement Purity Test" when evaluating trade-offs in your product decisions?

Problem Statements