Imagine you discover a promising program you're eager to expand organization-wide, or you're keen to launch new initiatives that foster a culture of innovation, or you want to work with a new service provider. Often times you might be facing a significant hurdle: lack of stakeholder buy-in. This sometime stems from your own uncertainty about the idea. Although you sense a valuable opportunity, articulating it clearly is challenging, and you recognize that exploring this idea alone isn't feasible.

To move forward and gain the crucial support of your leadership, you need a way to transform this intuitive feeling into a concrete, persuasive concept. And it is common knowledge that the most convincing approach is to demonstrate the direct link between a program, initiative, or business idea and a specific business need or goal.

How do you align an idea, a program or even a new business partnership with your organization's needs, and where do you begin?

Here's an insightful case study and a guide to a 2-hour mini Problem Framing workshop designed to address these questions.

Disclaimer ⚠️ This workshop is not the full Problem Framing process that we teach through our innovation courses and use as part of our Innovation Accelerator. Consider this mini-workshop more like a preview of the power of Problem Framing.

‍

The Problem

A DevOps-focused organization approached us, keen on extending their services to a bigger player in the market. For the sake of this case study, let's refer to them as "DevOps X."

They were wrestling with a bunch of uncertainties: Did their solutions genuinely match up with what their client needed? Was their business model in line with these demands?

They had a lot of faith in their DevOps training program, which was all about arming employees with the skills and know-how for embracing DevOps ways of working. Yet, they were hitting a snag in figuring out how this program fitted into the unique needs of their client.

‍

Our Approach

Rather than just holding a standard meeting, we opted for a Mini Problem Framing workshop. This was to give "DevOps X" a clearer understanding of their business necessities and to guide them in making an informed decision about potentially revamping their business model. With only a few hours available for an in-person session, our goal was to extract maximum value from this time with minimal prep. We split our focus evenly across two key areas:

1. Delving into the needs of the “DevOps X” team — 1 hour on the clock.
2. Getting into the shoes of the “DevOps X” client — Another hour dedicated here.

We crafted an agenda for this mini workshop with a clear goal: uncover the true business opportunity and determine its viability as an investment. Joining us in this workshop were three key members from “DevOps X”: Jim, the CTO; Carla, handling business development; and Simon, the Development Team Lead. Our role, from the Design Sprint Academy, was to steer the workshop as facilitators.

Mini Problem Framing Workshop Agenda

‍

1. Superhero Icebreaker

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. Understanding 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 as a DevOps provider, 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.

The "DevOpsX" business need:

We need stakeholder’s buy-in for implementing DevOps within their organization, through our unique program focused on upskilling the development teams.

‍

3. Understanding the context

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 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. Understanding the business goals

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 heat map 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. Defining their Client (the CEO)

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.

‍

7. Understanding how their Client (the CEO) solves the problem 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.

‍

Conclusion

Not all ventures are destined for success, and not every collaboration strikes the perfect chord. Realizing this sooner rather than later is for the best. The "DevOps X" found itself underprepared to fulfill its ambitious promise to their key client — the CEO of a major corporation seeking digital transformation and innovation.

In sum, engaging in a Problem Framing process, even through a brief workshop such as this, can shed light on a crucial aspect: the alignment of your aspirations with your actual capabilities. It also offers enhanced visibility into the operational and problem-solving methodologies of your customers, users, or partners.

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.

Typically, we schedule our Problem Framing workshops a couple of weeks — usually two to three — ahead of any Design Sprint. This timing is crucial for us. It gives us that sweet spot to make sure we're zeroing in on the real issue at hand. Plus, it's the perfect window for putting together a top-notch sprint team, focusing in on who we're really doing this for (our target user), and, crucially, making sure we've got all the right people on board, the key stakeholders.

We also slot in these Problem Framing sessions as a key step in the Innovation Accelerator, specifically in the Explore phase. Here, it's all about getting down to brass tacks with the stakeholders, really getting a grip on what they're gunning for and their business goals. This step is a game-changer for pinpointing those growth opportunities that sync up perfectly with their objectives. It's what keeps the accelerator ticking over, constantly delivering value.