Strategy
Problem Framing
The team writes, compares and tests its versions of the problem before anyone proposes a solution. A well-executed solution to the wrong problem is still a waste. You leave with one agreed problem statement, its boundaries and the metrics that will show it's solved.
Duration
1.5 hours
Group Size
4-8
Category
Strategy
Difficulty
Easy
The goals are to: articulate the problem clearly for everyone, distinguish between symptoms and root causes, define success criteria before brainstorming solutions, and identify constraints around the problem.
You'll get a well-articulated problem statement, clear boundaries defining the scope, and documented success metrics and constraints.
Be aware that people often want to jump to solutions. If someone says, 'The problem is we don't have feature X,' remind them that's a solution disguised as a problem. Ask: what user problem does feature X solve? Disagreement is valuable data. Don't immediately resolve conflicting problem framings. Explore the different perspectives. What evidence supports each framing? You might discover multiple problems. The 'Five Whys' technique can feel repetitive, but that's why it works. The initial answers are often symptoms, while the later ones get closer to the root cause. Encourage participants to push through the discomfort. Problems tend to expand in scope. 'Improve search' can easily become 'improve the entire information architecture.' Explicitly define the boundaries. You can always expand the scope later, but shrinking it is more challenging. To run it remotely, have each person draft in their own frame on a shared board and paste their statement in at the same moment, so nobody anchors on the first one. Run the Five Whys with everyone together and one person typing.
Add unlimited notes to any activity
Start the conversation
Be the first to share your thoughts, experiences, or questions!