Based on Design Sprint & Problem Framing methods
Imagine you come across a great program, and you want to scale it through the organisation, 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 uncertain.
No worries, with this 2h 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:
- one hour to explore the needs of the business.
- one hour to empathise with “DevOps X” customer problem.
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.
Time: 10 min
Why: to uncover strengths and highlight similarities between people.
- 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 are the people with all the crazy ideas, who are the ones making them tangible and who are the ones doing all the deep thinking and analysis. It also helps us, as facilitators, map the roles and strengths to 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 organise 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.
- 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 in a more philosophical manner writing : “digital transformation, beyond buzzwords”, “transformation enablement”, “empowerment”, “hope”; Carla, the Business Development person answered with: “making boring companies savvier”, “sharing tacit knowledge”, “organisational 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 as well as 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.
- 9 min Individual Brainstorming
- 20 min Affinity mapping
After understanding the needs of the present, 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 organise the notes in a 3 column grid on the wall: Actions/ Success/ Barrier.
We created a mini-report together on previous endeavours, 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.
- 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, 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, and it was a good enough indicator for us as external consultants to understand the project’s purpose.
Time: 10 min
6. Who is affected by the problem?
Time: 15 min
Why: to empathise with the client, change the perspective and align on the same understanding.
- 5 min Individual Brainstorming
- 5 min Proto-Persona
- 5 min discussion
We needed a break in order 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 particularly difficult, 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 organisation, managing 20 different verticals, with more than 10 years experience, who has been trying to do 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
Then, we asked everyone to pick the notes that they know to be valid facts 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 also. 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.
7. How are they achieving their goals today?
Time: 15 min
Why: to spot barriers, pain points and ultimately opportunities.
- 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 organisation today, what actions and behaviours are visible, what challenges and barriers are blocking 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 corresponding step on the map. 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.
Time: 10 min
Why: to spot the opportunity and ignite ideas.
- 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’s 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, as well as 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 visualise with the help of HMWs, but at the same time, this visualisation 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 the digital transformation journey of their clients. So, these HMWs turned into really big 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 organisation. However, a 2h framing session is far away 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 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 one of our public workshops in Berlin, London or New York.