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.