How to run a mini problem framing workshop?
--
An effective 2-hour workshop based on Problem Framing and Design Sprint exercises
Imagine you come across a great program, and you want to scale it through the organization, or you develop a new service, and you want to sell it to your clients, but you don’t know where to start or what to focus on. You want to run with it, but you’re still confused and afraid to take the risk.
No worries, with this 2-hour mini-problem framing workshop, you will be able to gain clarity and make effective decisions fast.
A couple of months ago, we were asked by a DevOps company, let’s call it “DevOps X,” to run a mini problem framing workshop to help them gain more clarity on their business needs and reach a decision concerning changing their business model. We only had a couple of hours for a face-to-face meeting, so we needed to make this session valuable with minimal preparation. This meeting was, in fact, the project scoping meeting.
For maximum efficiency, we decided to tackle two perspectives equally:
- Explore the needs of the business — ⏰ 1 hour
- Empathize with the “DevOps X” customer problem — ⏰ 1 hour
We drafted a mini Problem Framing workshop agenda around this objective: discover the business opportunity and decide if it is worth the investment.
For this meeting, the “DevOps X” team of three joined: Jim (the CTO), Carla (the business development person), and Simon (the Development Team Lead) and us, Design Sprint Academy, playing the Facilitator’ role.
Disclaimer ⚠️ This workshop is not the full Problem Framing process that we teach through our public and corporate courses and use as part of our Design Sprint 3.0 method. Consider this mini-workshop more like a preview of the power of Problem Framing.
Mini Problem Framing Workshop Schedule
1. Superhero
Time: 10 min
Why: to uncover strengths and highlight similarities between people.
How:
- 2 min to draw a superhero or a superpower.
- 8 min for everyone to introduce themselves as superheroes to the group.
To start the conversation, we all introduce ourselves using the Superhero icebreaker. We like this exercise because it shifts our mindset from its current state to a potentially positive one focused on the future. Even if this may be entirely fictional, it also helps uncover similarities between us. For instance, in less than 10 minutes, we can discover who the people are with all the crazy ideas, who are the ones making them tangible, and who are doing all the deep thinking and analysis. It also helps us, as facilitators, map the roles and strengths of the people in the room. From the superhero drawings presented, we learned who is the double-sized brain, super analytical and visionary (aka Jim the CTO), who is the most friendly emoji, ready to connect and share stories (aka Carla -the Business Dev. person), and who is the multitasking octopus, prepared to organize everything and everyone, yesterday! (aka Simon the Team Lead).
2. What is the business need?
Time: 10 min
Why: to get specific answers and align everyone on the same need.
How:
- 4 min Individual brainstorming
- 4 min Abstraction laddering
- 2 min Affinity mapping
We wanted to gain a clear understanding of their current business needs, so we asked everyone in the “DevOps X” team to write down their answers to the question:
What is your business need?
Easier said than done. As we anticipated, everyone had a different perception of the business problem. Jim, the CTO, answered this question more philosophically, writing: “digital transformation, beyond buzzwords”, “transformation enablement”, “empowerment”, “hope”; Carla, the Business Development person, answered with: “making boring companies savvier”, “sharing tacit knowledge”, “organizational healing”, “deliver value by saving customers time and money”, while Simon, the Team Lead, answered with: “enable development teams to have real ownership of their work”, “new technology adoption”, “upskill developers”, “enable companies to save $ by making DevOps roles redundant”.
We invited everyone to read their notes aloud while also arranging them on the Abstract-Concrete axis. In less than 3 minutes, we could see very abstract definitions of the problem and very concrete ones. As you might have guessed, we were interested in the concrete ones, so we asked the team to cluster all the specific answers by their similarities and concluded the exercise with a business need statement that everyone agreed with:
We need stakeholder’s buy-in for implementing DevOps within their organization, through our unique program focused on upskilling the development teams.
3. What have we tried?
Time: 30 min
Why: to have everyone share what they know, to highlight what worked and what didn’t.
How:
- 9 min Individual Brainstorming
- 20 min Affinity mapping
After understanding the present's needs, we wanted to take a good look into the past so that we know what mistakes to avoid, what challenges to expect in the future, and most importantly, what worked before.
To explore the “DevOps X” history, we asked the team three questions:
What are some steps, actions they tried?
What were some small wins?
What were some challenges they faced?
Everyone answered the questions individually, in silence, one idea per sticky note.
After the first 9 min were up (3min per question), we asked everyone to read their answers to the rest of the group and organize the notes in a 3 column grid on the wall: Actions/ Success/ Barrier.
We created a mini-report together on previous endeavors, highlighting what worked, what didn’t, and what could stop us from succeeding in the future. At this point in the process, this overview was all we needed.
4. What do you want to achieve?
Time: 10 min
Why: to align the team towards the same direction, to make the CTO’s vision tangible to the team.
How:
- 3 min Individual brainstorming
- 6 min Abstraction laddering
- 1 min Vote
After understanding the pressing needs of the present and the challenges of the past, we were finally ready to define the future. So we asked the team to answer this question individually, in silence, with one idea per sticky-note:
What do you want to achieve?
Again, the answers were diverse, from very broad as in: “holistic approach”, “powered by people”, “happy employees”, “improve products”, “digital transformation cartel”, “$$$ sell more”, “break the consultancy model”, to more specific, like: “aligned marketing strategy”, “reach C-level executives to scale our offerings”, “integrated suite of DevOps Org products”, “understand the internal marketing channels”.
We invited everyone to read them aloud and position the notes on the Abstract-Concrete scale.
The team focused on the concrete section of the ladder and voted their top goals (one dot per person). The dot-voting exercise generated a heatmap that highlighted the direction the team wanted to go. It was a good enough indicator for us as external consultants to understand the project’s purpose.
5. Break
Time: 10 min
6. Who is affected by the problem?
Time: 15 min
Why: to empathize with the client, change the perspective and align on the same understanding.
How:
- 5 min Individual Brainstorming
- 5 min Proto-Persona
- 5 min discussion
We needed a break to brace for the ambiguous part of this workshop, understanding the Client/Customer, the person affected by the “assumed problem”. You might think this is easy, but in our experience of running dozens of problem framing and design sprint workshops as external facilitators, this part is tough, plagued with biases and assumptions, because people actually don’t know much about their customers. So, our goal as facilitators was to learn what “DevOps X” knew, and most importantly, to learn what they didn’t know.
We used a Proto-Persona Template to map what we knew or assumed about the client, in this case, the CEO of a co-operative organization, managing 20 different verticals, with more than 10 years of experience, who has been trying to do the digital transformation for more than five years. To learn more about him/her, we asked the “DevOps X” team to brainstorm ideas individually for each quadrant of the grid:
- Relevant demographics
- Challenges
- Behaviors
- Goals
Then, we asked everyone to pick the notes they know to be valid and share them with the group.
After everyone was aligned on the facts, we invited them to label with an “A” their guesses or assumptions and added them to the map. The proto-persona now became a 70% “A” labeled. Having these clear visuals helped the team understand how much they don’t know about their client.
Check out our free 👉 Problem Statement Template for online workshops, available in Mural and MIRO. To see how it works in practice simply refer to our 🎥 webinar: Problem Framing. How to prioritise the target audience and define the problem statement.
7. How are they achieving their goals today?
Time: 15 min
Why: to spot barriers, pain points, and ultimately opportunities.
How
- Storytelling
- User Journey map
Fully aware that we are working with assumptions now, we moved on to the CEO’s journey map. We wanted to learn how the CEO is transforming the organization today, what actions and behaviors are visible, what challenges and barriers block their path.
Luckily, Carla, the business development person at “DevOps X,” recently had a Client meeting and was able to bring some valuable insights into this exercise. So we asked her to share what she knew, mapping her story while she was talking. Each sticky note representing one step in our CEO’s journey.
We also gave the team the assignment to capture on pink sticky notes every pain, complaint, challenge they hear, and position it on the map's corresponding step. In less than 10 minutes, we had our map ready, some areas being more populated with pink sticky notes than others. We also noticed the team having an A-HA moment while sharing the same understanding of their client.
8. HMWs (How Might We?)
Time: 10 min
Why: to spot the opportunity and ignite ideas.
How:
- 1 min to review everything
- 5 min Individual Brainstorming
- 4 min revise and Vote
We needed to bring everything together, meaning the DevOps X business need of getting the stakeholder’s buy-in for implementing change through their program, with the actual barriers and pains the CEO is facing in his journey towards digital transformation. For that, we used HMWs, as a tool for opportunity finding.
We asked the team to review their goals and their customer’s pain points and convert insights into questions. They ended up creating HMWs like: “HMW create a plausible recipe?”, “HMW make them feel in control of their transformation?”, “HMW produce a quick win?”, “HMW position this as PRODUCT IS THE COMPANY?”.
They were very excited about all the different possibilities and future solutions they could now visualize with the help of HMWs. Still, at the same time, this visualization triggered an important A-HA moment. These types of challenges exceeded by far the company’s capabilities. “DevOps X” wasn’t experienced, mature enough, or equipped with the right skill set to solve the major pain points in their clients' digital transformation journey. So, these HMWs turned into considerable challenges, some of them waiting to be overcome through Design Sprints.
Wrapping up Problem Framing
Hopefully, you will use this formula to run effective decision-making sessions with relevant key stakeholders at your organization. However, a 2-hour framing session is far from a 1-day Framing Workshop backed up by user research and real data. Do not consider this as a 1-time event, but more like the start of the conversation.
We usually run Problem Framing workshops two-three weeks before any Design Sprint to ensure that we are tackling the right problem, recruiting a capable sprint team, focusing on the right target user, and most importantly, we have the key stakeholders buy-in, as a phase 0 in our Design Sprint 3.0 framework.
For a deep dive into Problem Framing, join our public courses in 2021 or make it a team event and bring this training into your organization.
Don’t forget to download our free 👉 Problem Statement Template for online workshops, available in Mural and MIRO. To better understand how the template works in practice please refer to our 🎥 webinar: Problem Framing. How to prioritise the target audience and define the problem statement.
