Problem Statement

← Back to Method Diagram

“A problem well stated is a problem half-solved.” – Charles Kettering, inventor & head of research at GM

Purpose of a Problem Statement

A Problem Statement is, without question, the single most impactful document in any project. It defines its success or failure and the extent to which it becomes one or the other, very early on. 

Without it – and without validating it during the research phase – we build the wrong thing, or a pointless thing, wasting a lot of time and money as we try to correct assumptions and omissions for the same budget and to the same deadline when we realise later that we were so keen to start building, no-one really understood what the requirements actually were.

It needs to be defined with or by the stakeholder(s) and then refined between them and the Problem Solver (UX, SD, BA etc) to reflect a pragmatic combination of the stakeholder’s needs and the data uncovered during discovery/research so that it points the delivery team clearly and unitedly toward the same shared vision and goal.

A problem statement is a North Star. It should be the love child of the clients intent and the users need.

Value of a Validated Problem Statement 

  • The stakeholder agrees the goals, clearly, with us.
  • We all – the entire project team – have the same single vision of success.
  • It avoids delivery team members making assumptions, filling in the gaps and all heading off in different directions
  • With a single, agreed, validated problem statement, the Project manager or Scrum Master does NOT lose their minds trying to correct course and herd cats on a daily basis
  • It states the problem, not the solution – empowering the delivery team experts to leverage their expertise to solve it
  • Validating the problem statement means we address the root cause, not a symptom – leading to additional benefits and success
  • The client doesn’t “change their mind” about the product or service half way through – because we’ve validated the problem statement and they have signed it off – they are psychologically and professionally committed and this means they focus on it more carefully.

“Projects (and businesses) don’t fail because they have problems that can’t be solved – they fail because they don’t take the time to validate them before trying” – Anthony McSharry, all the time

Anatomy of a Problem Statement

Anatomically, a Problem Statement looks like this|:

Provided the words of the problem statement articulate the problem and the client’s intention properly, they’re in the form of a challenge, and provided those intentions deliver value, then we have a good problem statement.

Problem Statement Anatomy Main Words The client's description of the problem to be solved ("Solve this…"), not the solution they'd like delivered ("Build this…"). Intentions What the client's underlying intention is. What the words are trying to articulate and what success llooks like to them. What are they trying to achieve? Value(s) The value the client hopes to achieve by solving this problem – will it be valuable to solve this? Something that can be measured when the solution goes live.