How a 2-Hour Problem Framing Workshop Creates More Alignment Than a Week of Meetings
by Dana Vetan
Problem Framing isn’t just a buzzword; it’s a game-changer for teams that want to focus on solving the right problems. Think of it as the flashlight that cuts through the fog of unclear goals, misaligned teams, and wasted efforts. It ensures you’re actually making progress where it matters most.
Here’s the best part: you don’t need weeks or months to get a taste of its potential. Our 2-hour mini Problem Framing workshop offers a fast but powerful introduction to a transformative process. In just two hours, you’ll experience the clarity, alignment, and focus that Problem Framing can spark for your team and stakeholders.
What’s the Mini Problem Framing Workshop All About?
This workshop is about one thing: turning abstract ideas into actionable clarity. Whether you’re pitching a new concept or trying to align your team, it gives you a structured framework to identify what really matters. By the end, you’ll have a clear, persuasive concept that connects with your goals and resonates with stakeholders.
It’s not just for innovation managers or product leaders—it’s for anyone who wants to solve problems effectively and get results.
What Happens in the 2 Hours?
We’ve designed the session to be compact and impactful. Here’s how it all breaks down:
1. Understanding the Team’s Needs (First Hour)
We begin by laying a solid foundation. What’s the context? What’s your business need? What are your goals? These questions might seem basic, but trust me, they’re crucial to making sure everyone’s pulling in the same direction.
2. Stepping Into the Customer’s Shoes (Second Hour)
Next, we shift your team’s perspective. Who is the customer or end-user? How are they currently tackling their challenges? Where are the gaps or opportunities? By the end, you’ll have a clearer picture of how to deliver real impact.
Disclaimer ?? This mini-workshop is a condensed introduction to the Problem Framing framework. Think of it as a sneak peek into how Problem Framing can drive alignment and clarity. To dive deeper and master the full process, check out our Problem Framing on-demand course at www.problem-framing.com.
The Context
A DevOps-focused organization approached us, eager to expand their services to a bigger player in the market. We’ll call them “DevOps X.”
They were wrestling with all sorts of questions: Were their solutions genuinely aligned with their client’s needs? Did their business model reflect these demands?
They had high hopes for their DevOps training program—a solution designed to equip employees with DevOps skills and knowledge. Yet they were stumbling when it came to tailoring this program to the unique needs of their prospective client.
Our Approach
Instead of a typical meeting, we decided to conduct a Mini Problem Framing workshop. Why? To give “DevOps X” a sharper view of their business requirements and help them decide whether a business model overhaul might be necessary. We had just a few hours at our diposal, so the goal was to maximize impact with minimal prep time.
We split our workshop evenly across two focal points:
Using our problem framing approach, we designed a mini workshop agenda with a crystal-clear objective: uncover the real business opportunity and assess if it’s worth investing in.
Who joined us? Three key people from “DevOps X”:
Our team from the Design Sprint Academy served as facilitators.
Workshop Agenda
1. Superhero (10 min)
Why: Reveal strengths and highlight commonalities. How:
This playful icebreaker prompts the team to adopt a positive, forward-thinking mindset. It also uncovers who’s visionary, who’s driven by interpersonal connections, and who excels at structure and execution.
2. What Is the Business Need? (10 min)
We needed a clear snapshot of their current business challenge as a DevOps provider. So, each member of “DevOps X” answered this question on sticky notes: “What is your business need?”
As expected, their perspectives varied.
Jim (CTO) wrote down more philosophical ideas—“digital transformation, beyond buzzwords,” “hope,” and “transformation enablement.”
Carla (Business Development) listed ideas like “making boring companies savvier,” “organizational healing,” and “delivering value by saving customers time and money.”
Simon (Development Team Lead) focused on “enabling development teams to own their work,” “upskilling developers,” and “saving money by making DevOps roles redundant.”
To make sense of these differences, we arranged their responses on an Abstract-Concrete axis. Within three minutes, we had a mix of big-picture visions and ultra-specific ones. We then grouped the more concrete answers, ending up with a single business need statement everyone agreed on:
“We need stakeholder buy-in for implementing DevOps within their organization, through our unique program focused on upskilling the development teams.”
3. What Have We Tried? (30 min)
Why: Surface past efforts, successes, and obstacles.
How: Brainstorm individually (9 min). // Sort into a grid: Actions, Successes, Barriers (20 min).
With clarity on the present, we looked to the past to avoid previous mistakes and highlight any wins or red flags. We asked the group to consider:
Everyone wrote their insights on sticky notes—one idea per note—and posted them under Actions, Successes, or Barriers. This mini-report helped us understand what worked, what didn’t, and what pitfalls might crop up again.
4. What Do You Want to Achieve? (10 min)
Why: Align on a clear, tangible vision for the future.
How: Brainstorm individually (3 min). // Use abstraction laddering to refine (6 min). // Vote on top goals (1 min).
After covering the pressing needs and the lessons from the past, we turned to the future. Each person silently answered:
“What do you want to achieve?”
The responses ranged from broad (“holistic approach,” “powered by people,” “digital transformation cartel,” “break the consultancy model”) to precise (“aligned marketing strategy,” “reach C-level executives,” “integrated suite of DevOps Org products,” “understand internal marketing channels”).
Again, we mapped these on an Abstract-Concrete scale, then let participants vote on the most critical goals. This dot-voting created a “heat map” of priorities, guiding us—both facilitators and the “DevOps X” team—toward a more defined direction.
10 min Break (Yes, even a 2-hour workshop needs a moment to reset!)
5. Who Is Affected by the Problem? (15 min)
Why: Build empathy for the customer and clarify assumptions.
How: Brainstorm demographics, challenges, behaviors, goals (5 min). // Use a proto-persona template to map assumptions vs. facts (10 min).
Then came the trickier part: truly understanding the client. In our experience, people often think they know their customers—but once you start digging, biases and assumptions crop up quickly. Our goal was to find out how much “DevOps X” really knew and, crucially, what they didn’t know.
We used a Proto-Persona template focused on the CEO of a co-operative organization managing 20 different verticals. They have more than a decade of experience and have been wrestling with digital transformation for at least five years. Each participant brainstormed for a few minutes, listing facts or assumptions about:
Once we mapped out what the group believed to be true, we labeled any guesses with an “A” for assumption. The end result? A “proto-persona” that was about 70% assumption, bringing to light how many unknowns they were still working with.
6. How Are They Achieving Their Goals Today? (15 min)
Why: Uncover pain points and opportunities in the customer journey.
How: Walk through the customer’s journey step by step. // Mark barriers and challenges with sticky notes.
Acknowledging that we were dealing with limited facts, we moved on to mapping the CEO’s journey in pursuit of digital transformation. Carla, the BD lead, shared her latest insights from a recent client meeting. We stuck a note on the board for each step in the CEO’s process, noting every barrier or complaint on pink sticky notes.
Within 10 minutes, we had a visual of the CEO’s journey—complete with high-traffic “pain points.” The group had a collective aha! moment, realizing how many issues the CEO faced and how few of them “DevOps X” was fully equipped to solve.
7. HMWs (10 min)
Why: Turn fresh insights into actionable opportunities.
How: Review customer pain points and your own goals (1 min). // Brainstorm HMW (How Might We) questions (5 min). // Revise and vote on the most impactful concepts (4 min).
Our final step was to merge everything: the DevOps X need for stakeholder buy-in and the CEO’s needs around digital transformation. Using HMW (“How Might We”) questions, the team converted their insights into opportunities:
“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?”
Excitement spiked with all the new possibilities and future solutions. Yet it also triggered an important reality check: these challenges were often larger than “DevOps X” could handle alone. They required more capabilities, time, or resources—resources that weren’t immediately feasible. As a result, the CEO of “DevOps X” decided to pause and reconsider the investment for now, opting to position it as a more long-term strategic move rather than an immediate undertaking.
Closing Thoughts
Here’s the bottom line: not every idea will pan out—and that’s perfectly okay. Catching this early saves everyone time, money, and stress. By the workshop’s end, “DevOps X” realized they weren’t fully prepared to deliver on the promises they were hoping to make.
Even a short session in Problem Framing can reveal whether your ambitions line up with your actual capabilities. It also gives you a front-row seat to how your clients or partners operate and tackle their own problems.
Hopefully, you’ll use this approach for effective decision-making sessions with key stakeholders in your organization. But keep in mind: a 2-hour session is no substitute for a 1-day Framing Workshop with substantial user research and real data. Look at it more as the start of a deeper conversation.
We typically schedule our Problem Framing workshops a couple of weeks—two to three—before any Design Sprint. This timing is strategic. It helps us zero in on the right problem, assemble a well-rounded sprint team, clarify the target user, and secure buy-in from essential stakeholders.
We also integrate these Problem Framing sessions into our design sprint hackathons. By working closely with sponsors and senior leaders, we ensure the hackathon tackles problems that align with both strategic business goals and real-world needs. Identifying and prioritizing early opportunities lays the groundwork for more innovative outcomes.
Curious to learn more about Problem Framing? Join our free webinar on January 29th, 5:00 PM CET.