How to write a problem statement for a product team requires capturing four elements in one concise paragraph: who is experiencing the problem, what they are trying to accomplish, what is preventing them from accomplishing it, and why solving it matters to the business — without mentioning any solution.
The problem statement is the most important document a PM writes, and the most commonly written incorrectly. A problem statement that includes a solution ("users need a better dashboard") is a solution statement with a problem disguise. A problem statement that is too broad ("users have trouble with onboarding") gives no actionable direction. A good problem statement is specific, solvable, and solution-agnostic.
The Problem Statement Formula
H3: The Four Required Elements
- Who: The specific user segment experiencing the problem
- What they're trying to do: The goal or task they are attempting
- What's preventing them: The specific friction, gap, or failure point
- Why it matters: The business or user impact of the problem going unsolved
Template: "[User segment] who want to [goal] are unable to [specific action] because [root cause], which results in [business/user impact]."
H3: Problem Statement Examples
Weak: "Users have trouble finding reports."
- No user segment, no goal, no root cause, no impact
Better: "Operations managers at mid-market companies who need to share weekly performance reports with their team cannot export reports to PDF without losing formatting, forcing them to manually recreate reports in Google Slides — adding 2–3 hours of work per week per manager."
- Specific user (operations managers, mid-market)
- Specific goal (share weekly reports)
- Specific friction (PDF export loses formatting)
- Specific workaround and its cost (2–3 hours/week)
H3: Solution-Free Language
Every word in the problem statement should describe the current state, not the desired future state. Signal words that indicate solution creep:
- "Users need [feature]" → Replace with "users cannot [action]"
- "We should add [capability]" → Replace with "users experience [friction] when attempting [task]"
- "The product lacks [X]" → Replace with "users resort to [workaround] because [current limitation]"
According to Lenny Rachitsky's writing on product discovery, the discipline of writing a solution-free problem statement is one of the hardest skills for PMs to develop — the team knows what they want to build before they start research, and the problem statement becomes a rationalization for the predetermined solution rather than a genuine discovery of the user's need.
Validating the Problem Statement
H3: The Evidence Check
A good problem statement should be supported by evidence from at least two sources:
- User research (interview quotes, survey data, session recordings)
- Behavioral data (funnel drop-off rates, support ticket volume, workaround usage)
- Business data (deals lost to this gap, churn attributed to this problem)
If you cannot point to evidence for each element of the problem statement, it is a hypothesis, not a validated problem. Labeling it as such changes how you approach the decision to invest in solving it.
H3: The "So What?" Test
Read the problem statement and ask "so what?" If you cannot answer with a specific business outcome (reduced churn, faster conversion, lower support volume, unlocked enterprise deals), the problem may be real but not worth solving.
H3: The Scope Check
A problem statement is well-scoped if it can be solved with a focused product investment. Warning signs of over-scoping:
- The problem statement implies changes to 5+ product areas
- Solving the stated problem would require organizational changes beyond the product team's control
- The problem is so fundamental that it requires a product redesign rather than a feature
According to Shreyas Doshi on Lenny's Podcast, the most important thing a PM can do with a problem statement is share it with the engineering and design team before any solution work begins — teams that write the problem statement together have shared understanding of what they are trying to solve, which prevents the costly mid-sprint realization that everyone had a different problem in mind.
Using the Problem Statement
H3: Alignment Before Solution Work
Share the problem statement with all stakeholders — engineering, design, data, CS, sales — before any solution exploration. Collect feedback on:
- Is the user segment correct?
- Is the root cause accurate?
- Are the impact estimates right?
Revise the problem statement based on feedback. Only when the team agrees on the problem are you ready to explore solutions.
H3: The Problem Statement as Evaluation Criteria
During solution design and sprint review, evaluate every proposed solution against the problem statement:
- Does this solution address the root cause?
- Will this solution be accessible to the specific user segment?
- Will this solution remove the specific friction described?
Solutions that don't address the root cause will not solve the problem, regardless of how well they are built.
According to Gibson Biddle on Lenny's Podcast, the teams that ship the most effective features are the ones that return to the problem statement at every stage of development — it is the contract between the team and the user that prevents solutions from drifting toward what is technically interesting rather than what solves the stated problem.
FAQ
Q: What is a problem statement in product management? A: A concise paragraph that describes who is experiencing a problem, what they are trying to accomplish, what is preventing them, and why solving it matters — without mentioning any solution.
Q: What are the four elements of a good product problem statement? A: The specific user segment, what they are trying to accomplish, what is preventing them from accomplishing it (root cause), and the business or user impact of the problem going unsolved.
Q: How do you avoid including solutions in a problem statement? A: Replace "users need [feature]" with "users cannot [action]." Replace "the product lacks [capability]" with "users resort to [workaround] because [limitation]." Every word should describe the current state, not the desired future state.
Q: How do you validate a problem statement? A: Support each element with evidence from user research, behavioral data, or business data. If you cannot point to evidence, label it as a hypothesis and treat it with corresponding uncertainty.
Q: How should you use a problem statement with your product team? A: Share it before any solution work begins. Collect alignment from engineering, design, data, and stakeholders. Use it as evaluation criteria throughout development to ensure solutions address the stated root cause.
HowTo: Write a Problem Statement for a Product Team
- Identify the specific user segment experiencing the problem — not "users" but a defined group with shared characteristics and context
- Describe what they are trying to accomplish in their own terms — the goal they have, not the feature they want
- Name the specific friction, gap, or failure point preventing them from accomplishing the goal — the root cause, not the symptom
- Quantify the impact in business or user terms — hours lost, deals affected, churn attributed, support volume generated
- Remove all solution language — replace every "needs," "should have," or "lacks" with specific descriptions of current-state friction
- Validate the problem statement with evidence from at least two sources and collect team alignment before any solution exploration begins