Defining the problem can be easily overlooked in favor of getting shit done
One of my go to books for planning sprint workshops
There’s a short, but poignant shout out to the importance of defining The Problem Statement in Banfield/Lombardo/Wax’s Design Sprint book (on page 96).
‘The propensity to create and deliver often overpowers the desire to understand why (you) are creating something.’
It’s in their Phase 1, the Understand Phase, which they recommend you do after the sprint planning, but before you start diverging.
The full Phase 1 agenda for getting mutual understanding of the problem to be solved can be done over the course of a day-ish. Much of the day is intended to develop empathy for the customer and each other which is the bedrock of any shared problem solving effort. Here’s the breakdown (pg 75):
Getting the background
Get inspired
Define the Problem
Know the User
Wrap Up
You want your solutions to emerge from a firm understanding of the actual problem to be solved. And more importantly a shared understanding of that problem is essential, as it sets the whole tone and direction for subsequent sprint activities.
Group exercises usually work towards a problems statement which can bubble up from a bunch of post-its after which a Challenge Map exercise(pg 102) might be useful to vet everyone’s assumptions about why this problem is worth solving.
I’ve also used the approach of getting the team to craft a very specific sentence in order to produce a honed problem statement – something like…
‘This [persona] will experience less of this [pain point] using [this feature] because of [this reason].
The former (persona and pain point) has you brainstorm many problem definitions which are then whittled down and vetted. The later (this reason) forces a constraint on the team up front which can be uncomfortable if people are easily discouraged by having to rework the sentence multiple times.
But addressing the problem head on as a statement of some kind, it usually forces us to ask all the dumb questions we’ve been afraid to ask all along. This is probably why the problem statement phase is often ignored. It’s better to feel a bit stupid for a shorter period of time than to act on assumptions that might drive us to build things that are solving the wrong problem for our customers.
References
Design Sprint, A Practical Guidebook for Building Great Digital Products by Richard Banfield, C. Todd Lombardo and Trace Wax