Problem Framing is a structured one-day workshop that brings senior decision-makers together to align on what's actually worth solving — before committing time, budget, or engineering resources to solutions that don't solve the right problem. It was first taught at scale by Design Sprint Academy to Google's design and product teams in May 2018.

Why Google's Design Sprint Facilitators Needed Problem Framing

By 2018, Google had one of the most mature internal Design Sprint practices in the world. The Google Design team had their own facilitators, their own cadence, their own playbook. They had run more sprints than most organizations will ever attempt.

And yet the Head of Google's Design Sprint Academy reached out to us with a specific problem.

The sprints were running well. The process was sound. But the teams weren't always working on the right challenges. Design Sprints, it had become clear, are extraordinarily good at solving problems — but they don't tell you which problem to solve. That decision happens before the sprint. And without a structured way to make it, teams were entering sprint week with challenges that were too vague, too broad, or too solution-shaped to produce meaningful outcomes.

What Google needed wasn't better sprints. They needed better problem definition before the sprints started.

That's what Problem Framing is for.

San Francisco, May 18th, 2018

We ran a one-day Problem Framing training in San Francisco for over 60 product managers, strategists, and designers from Google Design. Because we made it a public event, the room also included practitioners from Adobe, PayPal, Boeing, Salesforce, and Nike — people who came from entirely different industries but recognized the same pattern in their own organizations.

That cross-company dynamic turned out to be one of the most valuable parts of the day. When a Boeing facilitator and a Salesforce product manager and a Google designer all describe the same failure mode — teams jumping to solutions before the problem is understood, stakeholders misaligned on what they're actually trying to solve, sprints producing prototypes that nobody funds — it stops feeling like a process problem and starts feeling like a human one.

The workshop objective was simple:

Learn how to love the problem first, so you can love the solution later.

The actual experience of doing that was harder than most people expected.

What the Room Revealed

The deck we used that day opened with a provocative question and moved quickly into frameworks — the Cynefin model for identifying problems worth sprinting on, cognitive bias mapping, stakeholder context analysis, user understanding, synthesis, and finally the craft of writing a problem statement that is specific enough to act on without pre-solving the problem.

The participants came in with their own questions, written on the slides before the session started. They wanted to know: how do you get stakeholders from design, development, business, and marketing to agree on a single problem statement? How do you push past the obvious "How Might We" into something that actually opens up the solution space? How do you socialize this way of thinking in organizations that are wired for solutions?

Those are the right questions. And working through them — really working through them, not just discussing them — was exhausting.

By the end of the day, the room was tired. Not in the way people are tired after a Design Sprint, where there's a prototype to show and a week of momentum to look back on. Tired in a quieter, heavier way. The kind of tired that comes from sustained focus, from resisting the pull toward answers, from holding a problem open long enough to actually understand it.

Several people said some version of the same thing: this is harder than I expected.

Hard Is the Point

That reaction is worth examining, because it reveals something important about why Problem Framing matters — and why so few organizations do it well.

Design Sprints are energizing. There's creative momentum, visible output, the satisfaction of watching something take shape. Problem Framing has none of that. There's no prototype at the end. No artifact to show a stakeholder. Just a problem statement — carefully constructed, hard-won — and a shared understanding of why it's the right one to solve.

That's not a bug in the method. That's the method.

Decisions are hard. Focus is hard. Choosing one direction over three plausible alternatives, with incomplete information and real organizational consequences, is genuinely difficult. No process can make that easy without also making it shallow.

What Problem Framing does is make the difficulty productive. It structures the hard work so that the discomfort serves a purpose — surfacing the real problem, eliminating the decoys, aligning the people who need to act on the outcome. The exhaustion at the end of a good Problem Framing session is the feeling of having done something that matters.

Most organizations skip this. Not because they don't understand its value, but because it's easier to start building. Easier to run the sprint. Easier to show momentum. The default is always toward action, toward something that looks like progress.

That default is exactly why so many innovation efforts fail quietly — not with a dramatic collapse, but with a slow fade as the solution that was built with energy and care turns out not to solve a problem anyone actually had.

The competitive edge isn't speed. It isn't creativity. It's the willingness to do the hard work of defining the problem before touching the solution. Almost everyone defaults to easy. Very few do the hard stuff.

Google's Design Sprint facilitators understood this. It's why they invited us. And it's what the room confirmed that day in San Francisco — that even for the most experienced practitioners, Problem Framing requires something that can't be shortcut: sustained, uncomfortable, focused thought.

What Problem Framing Taught at Google Looked Like

The one-day training moved through four phases:

Find and prioritize problems — using the Cynefin framework to distinguish complex problems (where the answer is genuinely unknown) from complicated ones (where experts can analyze a path forward). Design Sprints work best at the boundary between these two zones. Problem Framing helps teams identify which challenges actually belong there.

Understand context and users — mapping stakeholder dynamics, business constraints, and the real experience of the people the solution needs to serve. This is where cognitive biases — confirmation bias, status quo bias, overconfidence, anchoring — get named and examined, so they can be actively countered rather than quietly driving decisions.

Synthesize — moving from gathered research and observation to insight. The synthesis phase is where most teams struggle most, because it requires tolerating ambiguity long enough to see what the data is actually saying rather than what you hoped it would say.

Write the problem statement — the culmination of the day. A well-written problem statement is specific enough to guide a sprint, open enough to leave the solution space genuinely unexplored, and grounded in user reality rather than internal assumptions. Getting there takes everything that came before it.

This structure — understand, frame, synthesize, articulate — is what sits in front of every Design Sprint we run. It's what turns a sprint from an energetic creative exercise into a structured investment with a defensible outcome.

From Google to 5,000 Practitioners

The San Francisco training was the first time we taught Problem Framing at this scale. Google's team validated something we had seen in our own client work but hadn't yet systematized into a full training format: that the gap between knowing how to run a sprint and knowing which problem to run it on is real, consequential, and teachable.

Since that day, more than 5,000 practitioners across the globe have come through our Problem Framing training programs. The organizations have changed. The industries have changed. The problems have changed — and in 2026, many of them involve AI in ways that 2018 couldn't have anticipated.

What hasn't changed is the reaction at the end of a good Problem Framing session. The tiredness. The clarity. The sense of having made something hard, and having it be worth it.