CX Mental Models & Frameworks · Problem Definition
Problem Statements
A problem statement separates what you know from what you assume — before anyone builds anything.
Problem Statements turn vague complaints into structured, evidenced problems. Each statement links the customer's pain to the internal business cost, separates assumptions from verified knowledge, and names the risk of doing nothing. That structure is what makes the business case stick.
Most initiatives start from opinion. Someone senior believes they know the problem, and the team builds from there. A problem statement blocks that path. It forces two descriptions of the same problem: the customer's view — what task can they not complete — and the internal view — what it costs in escalations, lost sales, or rework. If you can only fill in one side, you don't understand the problem yet.
- Describe the problem from the experience side and the business side
- Split what you think you know from what research has verified
- Name the responsible and affected teams so ownership is explicit
- Document the risk of not fixing it — in money and brand damage
- Match the problem to a strategic objective like retention or growth
Where teams go wrong: they populate the evidence column by workshop. Dozens of stakeholders guessing together still produces guesses. Evidence comes from qualitative research and observation of real customers, not consensus in a conference room. The risks column is your lever with leadership — stakeholders who want it fast tend to reconsider when the cost of shipping below the quality threshold is written down.
A workshop full of guesses is still a guess.
Apply this
Reading about problem statements is one thing. Seeing where it applies in your journey is the useful part.