A problem statement is not a complaint
“Checkout is bad” is a useful signal, but it is not yet a problem statement. A good problem frame gives the team enough context to investigate without prescribing the solution.
Current state before future state
Document what exists before designing what should exist. Map the current process, systems, people, handoffs and pain points. This prevents the team from designing a beautiful future state that ignores operational reality.
Example: subscription commerce
Suppose repeat customers want to reorder frequently, but the current store makes every purchase a manual checkout. The business need may be increase repeat-purchase convenience and recurring revenue. Subscription functionality is one possible response, not the business need itself.
Separate symptoms from causes
| Question | Practical answer |
|---|---|
| Symptom | Orders are being abandoned. |
| Possible cause | The checkout is slow or confusing. |
| Deeper cause | Customers are being asked to repeat information unnecessarily. |
| Business effect | Lost conversion and lower customer lifetime value. |
Evidence makes the frame stronger
Use analytics, support tickets, interviews, process observation, operational data and stakeholder testimony. One anecdote can start an investigation; it should not automatically become the business case.
From problem to opportunity
A well-framed problem can also reveal opportunities. A recurring service complaint might expose a process bottleneck, a product gap, a data-quality issue or an opportunity to simplify the customer journey.
Write the problem so that different people can test it
A strong problem statement is specific enough that another person could investigate it without having to guess what you meant. Include the affected context, observable symptom, consequence and the boundary of what you are investigating. Avoid embedding the solution in the problem statement.
For example, “We need a new CRM” skips the investigation. “Sales representatives are manually copying lead data between three systems, causing duplicate records and delayed follow-up” gives the team something they can observe.
Separate evidence from interpretation
Evidence: support tickets increased from 30 to 75 per week after the new checkout release.
Interpretation: the new checkout caused the increase.
The interpretation may be correct, but it is still a hypothesis until you inspect timing, ticket categories, error logs and the affected user journey.
The framing test
Read your problem statement and ask: could a different solution than the one the stakeholder proposed solve this? If the answer is yes, the statement is probably framed at the right level. If the only possible answer is the requested feature, you may have accidentally written the solution into the problem.
Rewrite “We need a dashboard because management has no visibility” into three versions: a symptom, a problem statement and a measurable desired outcome. Then list the evidence you would collect before selecting a solution.