Problem Framing workshop planning at BPP
As part of our P&T Innovation Week in December, I was asked to come up with an introduction to Problem Framing to familiarize a range of BPP Product and Technology team members with both the framework itself and the benefits of defining the problem space before any further work — in this case a Hack day — is undertaken. In my role as P&Ts Principal User Researcher, and having over a decade of experience of running these type of workshops, it was still a fairly challenging brief to come up with something both streamlined and lightweight enough, while still conveying the key tenets of the methodology.
A Problem Framing workshop can take weeks to prepare and days to run. From the usual workshop ops of making sure there are enough working Sharpies to specific needs such as journey alignment pre-workshop. As we wanted to demonstrate the power of a structured understanding of a problem before moving on the solution space, we shaped the Problem Framing workshop based on five core concepts:
1. Respect people’s time
The literal first step was to agree that the workshop would not last longer than 2.5 hours, and then working back from that constraint to hit every key requirement needed for a solid Problem Statement in the leanest manner possible.
In the end we did eventually add in an extra 30 minutes taking the whole workshop to 3 hours including breaks with everything run online over Miro so everyone could be included no matter where they were in the UK and across all teams in P&T. This also allowed us to run 6 distinct workshops in groups of three moderated by people in the Product Design team who were familiar with the technique.
2. Problem Framing is evidence driven
Problem Framing isn’t brainstorming, it isn’t a Design Sprint, and it isn’t requirement gathering. It might borrow aspects from all three, but Problem Framing should take attendees on journey from a solid base of strategy and insights in a defined problem space through the contextualisation of this evidence, to a natural expression of what is possible for the most impact.
The workshop had to start with an articulated problem area, the business’ strategy and vision, and a lightning talk of insights from a subject matter expert (SME) so attendees could make informed decisions at every step.
3. Consolidation and agreement is at the core of the exercise
Strategy and insights without context are meaningless so attendees went through a process of journey mapping and then flagging all known pain points before deciding which part of the journey and, more importantly, which pain point they should focus on. This is always a tricky part of the experience because so many opportunities are identified, but there’s only time to address one. We had to lean heavily into the use of a Decider, someone who would listen to the group’s opinions and make the final decision on where they should focus e.g This part of the journey! This pain point! This HMW!
The goal was to ensure that every workshop attendee was pulling in the same direction and accelerating the overall experience.
4. The output needs to work for the end goal: the Hackathon
The alignment behind a contextualised pain point was not the end of the workshop. This honour goes to a finalised Problem Statement. What is a Problem Statement? A How Might We (HMW) combined with a succinct summary of everything a team would need to confidently move from ‘building the right thing’ to ‘building the thing right’ in the Hackathon:
- the problem and its context
- who’s affected
- where the problem arises and why
- the benefit of solving this problem for the user
- and the benefit of solving this problem for the business
5. It’s a learning experience
Finally, on one hand the workshop needed to directly feed into the Hackathon, but it also needed to show people how Problem Framing worked. This meant that the trickiest parts were given extra time so people could get their heads around them and learn by doing.
For example, a HMW might seem simple, but in practice it takes skill to move beyond just re-expressing the pain point (e.g. HMW reduce errors in the application experience) or explicitly detailing a solution (e.g. HMW decommission platform X). The sweet spot sits in the rearticulation of the problem in a way that suggests a direction of travel for the solution (e.g. HMW better indicate student progress and performance, suggesting appropriate ways to enhance their learning outcomes) — and that, of course, takes practice.
Each workshop ended up looking something like this:
In the end, we received the feedback that every facilitator dreams of:
- Problem framing is valuable, so we need to ensure someone familiar with it is always the facilitator
- the workshop should be a little bit longer to get the full value out of it
- the structure of the workshop shouldn’t change, it’s spot on
- and more domain knowledge and insights should be injected into the process.
From never really having done that style of problem framing, to then going into only a 3 hour session to learn and come out with an output it was tight, but I really enjoyed that session. Found this really valuable to work with in my team.
Data & Analytics team member feedback
In fact, the Problem Framing was deemed such a success that we’re holding another Innovation Week in the summer which again will start with Problem Framing. However, this time we will invite stakeholders from across BPP to participate in both Problem Framing sessions and the Hackathon itself — which will be really interesting!
