The anatomy of a complete Problem Statement
The Problem Statement doesn't exceed half a page. That constraint is deliberate. Brevity forces precision. A long Problem Statement is a Problem Statement that hasn't finished being thought through.
But brevity is not simplicity. A good Problem Statement is a dense document that integrates multiple dimensions of the problem into a reduced space. To achieve this, we've identified seven elements that, when present, produce a problem definition that is complete, actionable, and resistant to ambiguity.
The seven elements of a Problem Statement
| # | Element | What it describes | Key question | Example |
|---|---|---|---|---|
| 1 | The gap | The distance between what happens and what should happen. Not the symptom, but the real gap. | What is wrong? What's the difference between the current and desired situation? | "Managers discover stockouts when the customer asks, not before." |
| 2 | The owner | Who lives the problem and who has the ability to decide it gets solved. Sometimes they're the same person; often they're not. | Who suffers the consequences? Who can authorize the solution? | "Store managers live it. The operations director decides." |
| 3 | The success criteria | What the world will look like when the problem is solved. Not in terms of solution, but of observable and measurable outcome. | How will we know the problem was solved? | "Managers anticipate stockouts at least 24h before they occur." |
| 4 | The constraints | The real barriers that limit the solution space: budget, time, regulations, legacy technology, organizational politics. | What can't we change? What limits what's possible? | "ERP updates in daily batch; replacement not viable in 12 months." |
| 5 | The actors | All stakeholders who can influence the solution or be affected by it, beyond whoever lives the problem directly. | Who can block, boost, or be impacted? | "Purchasing, warehouse, IT, customer service, suppliers." |
| 6 | The temporal context | When it happens, how often, and what temporal patterns the problem has. | When does it appear? Is it constant or does it have triggers? | "Daily in peak season; weekly in off-season." |
| 7 | The cost of inaction | The quantified impact of not solving the problem, expressed in terms the decision owner understands. | What is lost every day/week/month this isn't solved? | "12% of sales lost + 45 min/day × 120 stores." |
The first three elements — the gap, the owner, and the success criteria — are the heart of the Problem Statement. Without them, you don't have a problem definition; you have a vague description of discomfort. The remaining four — constraints, actors, temporal context, and cost of inaction — are what turn that definition into something actionable, complete, and resistant to interpretation.
Why is the success criteria defined here and not in the solution phase? Because the success criteria belongs to the problem, not the solution. If you don't define what "solved" looks like before thinking about solutions, each stakeholder will have a different definition and you won't discover it until it's too late. Defining success here is an act of preventive alignment that saves enormous conflicts later.
Complete Problem Statement example
The gap: The chain's store managers (120 points of sale) discover stockouts when a customer asks for a product that isn't available, not before. The central inventory system updates every 24 hours, which means all replenishment decisions are based on the previous day's data.
Who lives it / Who decides: Store managers live it daily, responsible for 40-80 SKUs per point of sale. The investment decision for a solution belongs to the retail operations director.
Success criteria: Managers can anticipate a stockout at least 24 hours before it occurs and act preventively. The "discovered by customer" rate drops from the current 100% to less than 15%.
Context: Occurs daily during peak season, when the rotation speed of some SKUs exceeds the system's update frequency. In off-season, frequency drops to weekly. Managers have developed manual workarounds — personal spreadsheets, calls to the warehouse, physical counts — consuming an average of 45 minutes daily and unreliable.
Constraints: The central ERP (SAP) updates in daily batch and its replacement is not planned for the next 18 months. Integration budget limited to €150K. Minimum stock regulations for health and food products.
Key actors: Purchasing team (replenishment decisions based on outdated data), warehouse managers (receiving orders that don't reflect real demand), IT team (maintains integrations), customer service (handles customer complaints about out-of-stock), frequent replenishment suppliers.
Cost of inaction: 12% of sales lost due to lack of available stock at the moment of demand. 45 minutes daily of manual work per manager × 120 stores = 90 hours/day of lost productivity. Erosion of customer trust from recurring "not available" experiences.
Validation: two levels almost nobody completes
A Problem Statement is not complete until it has been validated. But validation has two levels that most teams don't distinguish.
Level 1 — Validation with those who live the problem. The Problem Statement is presented to at least two of the clients or users interviewed. The question is direct: "We've written this as a summary of what we understand the problem to be. Do you recognize it? Is anything missing? Is anything incorrect?" If the person reads it and says "yes, this is exactly what happens," the gap and context are validated. If they say "well, more or less, but it's missing..." you need to iterate. No exceptions.
Level 2 — Validation with the decision owner. The user who lives the problem validates the gap and context. The decision owner validates the success criteria, constraints, and cost of inaction. Both validations are necessary. If the user recognizes the problem but the decision-maker doesn't recognize its cost, there will be no solution. If the decision-maker recognizes the cost but the user doesn't recognize the gap, the solution won't solve the right thing.
A Problem Statement that uses internal organizational language, technical jargon, or abstract concepts that the user doesn't recognize. If you read your Problem Statement to the person who lives the problem and need to explain what it means, it's poorly written.
How to detect it: Read the Problem Statement aloud to someone who didn't participate in the discovery. If you need to add explanations for them to understand it, the document uses internal jargon instead of universal language.
How to prevent it: Apply the external person test: would someone outside the organization, with no prior context, understand the problem by reading this document? If the answer is no, simplify. Every technical term or acronym is a barrier that reduces the Problem Statement's usefulness as an alignment tool.