Should you run Problem Framing or a Design Sprint? Here's how to decide

^{Problem Framing is what you run when you don't yet know what problem to solve.
A Design Sprint is what you run when the problem is clear and you don't know how to solve it.}

The diagnostic: which situation are you in?

Before any comparison, the honest question is: what's actually unclear right now?

The two methods serve different uncertainties. Read both lists and note which one you find yourself nodding at.

You're in a Problem Framing situation if:

• Stakeholders disagree about what to prioritize. Not minor disagreement — real, persistent misalignment between functions, levels, or business units. Every meeting circles the same questions.
• The mandate you've been handed is vague. "Do something about retention." "Explore opportunities in this segment." "Modernize the customer experience." Real direction, not specific enough to act on.
• You have multiple plausible directions and no agreed way to choose. The team isn't stuck because there are no ideas. It's stuck because there are too many, and each one has a credible champion.
• A previous initiative produced a solution to the wrong problem. Money was spent, the launch fell flat, and in hindsight the team realizes they were solving something that wasn't the issue.
• A significant investment is about to be approved. And the people approving it don't yet share the same picture of what's being approved or why.

‍

If two or more of those describe your situation, the uncertainty is at the problem level. A Design Sprint won't help — it will produce a fast, beautifully prototyped solution to a question no one validated.

A real example of what this looks like: a long-established newspaper recognized it had to pivot to digital. Print circulation was declining, the readership was aging, the strategic direction was clear. What wasn't clear was where to start.

The leadership team had spent the previous six months in circular discussions — each member of the leadership team carrying a different picture of what "go digital" actually meant and what success would look like. They had already tried to act once: a seven-figure budget went into building an app, which attracted fewer than a thousand customers. After that, the team became cautious about committing budget to anything else, which produced a kind of pseudo-alignment where nothing got blocked but nothing moved either. Customer research existed — fifteen documents across PDFs, decks, and spreadsheets — but the volume made it impossible to act on. Every meeting reopened the same questions.

That's a textbook Problem Framing situation. Not because the team lacked talent, urgency, or research — they had all three. The problem was that none of the data, the urgency, or the strategic intent had been brought into a single decision-making moment with the right people in the room.

The fix was a one-and-a-half-day Problem Framing workshop. The preparation translated the fifteen documents into a four-meter visual customer journey map and an industry context map — evidence the leadership team could engage with, debate against, and align around. The workshop itself moved them through the business context first, then the customer reality, then the convergence: five clearly defined opportunities for the digital transition, each grounded in business goals and customer pain, each ready for an action plan.

A day and a half produced more progress than six months of meetings. The point of the example isn't that Problem Framing is magic — it's that the failure mode the team was in (smart people, real urgency, plenty of data, no alignment) is the exact failure mode Problem Framing is built to break.

You're in a Design Sprint situation if:

• The problem is clear, but the solution is uncertain. The team agrees on what's broken or what opportunity to chase. The disagreement is about how to solve it.
• You're about to commit serious build resources. Engineering, design, and product time is being lined up. Before that pipeline kicks in, you want evidence the direction works.
• You have a hypothesis, and you need to test it with real customers — fast. Not validated yet. Not signed off by your gut alone. Tested.
• A specific solution direction is on the table that nobody has stress-tested. Often handed down — "we're going to build an AI assistant" — and you want to validate before committing instead of after.
• You're trying to compress what would normally be a months-long build-test-iterate loop into one week.

‍

If two or more of those describe your situation, the uncertainty is at the solution level. Problem Framing won't help — it will spend a day re-litigating a question your team has already settled.

A real example of what this looks like: Juicero. Launched in 2016 with $120M in venture funding, it was a $400 wifi-connected press that squeezed juice from $5–$7 proprietary produce packs. The pitch identified a real problem: cutting, juicing, and cleaning up is a genuine pain, especially for the busy professionals the product targeted. The problem was framed correctly. The solution was the part nobody validated.

Bloomberg reporters eventually showed that the proprietary produce packs could be squeezed by hand and produced essentially the same juice. The company shut down four months later.

A four-day Design Sprint would have surfaced this. Five real customers, in a room with the prototype, asked to use it. The first user holds the proprietary pack, looks at the $400 device sitting next to it, and asks the question the founders never tested: "why wouldn't I just squeeze the pack myself?" Or they hold the pack next to a bag of pre-cut produce from any grocery store and notice the price difference. Or they ask why the device needs WiFi at all.

That's what testing with real users does. It surfaces the questions that look obvious in retrospect but are invisible inside a team that's spent two years building the thing. None of those questions require six months of research — they require a customer in the room, the prototype on the table, and the structured space to watch what happens when the two meet. That's the Design Sprint. A week to produce the moment that would have saved $120M.

What is Problem Framing?

Problem Framing is a one-day workshop for senior decision-makers to align on what's actually worth solving — before any time, budget, or engineering resources are committed.

Decision altitude: senior leadership level. Director, VP, or Head of with authority over budget and direction.

Use it when: Stakeholders are misaligned, the mandate is vague, and a meaningful commitment is about to be made on top of unclear ground.

Key characteristics:

• 6–8 senior decision-makers in the room — the people with real authority
• 2–3 weeks of preparation beforehand to gather and visualize evidence (research, customer data, market signals)
• Structured exercises that move a divided room from divergent perspectives to a single agreed direction
• Decision-driven, not brainstorm-driven

‍

The output: A clear, agreed problem statement — or several, each functioning as a hypothesis to be tested next.

For the full method, see What is Problem Framing?.

What is a Design Sprint?

A Design Sprint is a four-day structured process that takes a defined problem and produces a tested prototype with real customer feedback. It's the validation method.

Decision altitude: cross-functional team level. A mix of hands-on builders — designers, engineers, product, domain experts — with one Decider in the room for key convergence moments.

Use it when: The problem is clear, a solution direction needs to be validated before committing build resources, and customer evidence will materially change the call.

Key characteristics:

• A cross-functional team of 5–7 hands-on experts plus a Decider
• Four days (the original Google Ventures version was five)
• A defined sequence: understand and define, ideate and decide, prototype, test with real users
• Produces high-fidelity prototypes that are tested with five real customers in a single week

‍

The output: A tested prototype and direct customer feedback — enough evidence to make a confident build, iterate, or kill decision.

For the full method, see Is a Design Sprint right for your organization?

‍

Problem Framing vs Design Sprint — at a glance

The situations where teams typically hesitate

Most decisions between these two methods aren't actually difficult. The hard cases are predictable, and worth naming:

"We already have a solution in mind."

Then the question isn't which solution to build — it's whether this solution is the right one. That's a Design Sprint. The team enters with the proposed direction, and the four days either validate it (with the assumptions surfaced and tested), or they expose that a different direction tests better.

Walking into a Design Sprint with a pre-existing solution is one of the strongest use cases for the method.

"We've already done a Design Sprint and it didn't go anywhere."

Common pattern — but the right next move depends on why it didn't go anywhere. Two very different root causes show up most often:

The prototype tested well, but the work stalled afterward. Leadership didn't get behind it. Budget didn't materialize. The team's recommendation went into a drawer. This is almost always an upstream issue: senior decision-makers were never aligned on whether the underlying problem was worth solving in the first place, so when the moment came to commit resources, they didn't. Problem Framing as a recovery move makes sense — with the senior stakeholders in the room this time — before another sprint.

The prototype was invalidated, and the team felt deflated. Real users said no. The momentum died. Nobody scheduled the iteration sprint that was supposed to follow. This isn't a framing failure — it's a follow-through failure. The Design Sprint did its job: it killed a weak idea cheaply, before months of build work. The right next move is the iteration sprint the team avoided — sometimes a focused Design Sprint refresh on a sharper version of the same problem, sometimes a smaller validation cycle.

The diagnostic question: did the prototype validate or invalidate, and what happened next? If it validated and stalled, the issue is upstream alignment. If it invalidated and the team stopped, the issue is what happens after a sprint, not before it.

"Half the team thinks we need Problem Framing, the other half thinks we need a Design Sprint."

Diagnostic: that disagreement is itself the signal. If your senior people don't share the same view of what the actual problem is, you're not ready for a Design Sprint. Run Problem Framing first.

"We don't have time for both. Which one do we pick?"

If this is the question, the framing of the question is off — because they're not two halves of one process you're choosing between.

A Design Sprint isn't the automatic next step after Problem Framing. A Design Sprint is the right move when you have no clear idea how to solve a problem and the only way to find out is to prototype it and put it in front of real users — the answer comes in retrospect, after the test. That's a specific kind of uncertainty. Most Problem Framing outputs don't sit on that kind of uncertainty.

A Problem Framing day might produce a problem statement that points to a research phase. Or to a roadmap reprioritization. Or to a clear build decision the team can act on without further validation. Or to the conclusion that the problem isn't worth solving at all. None of those need a sprint.

The right way to think about it: pick the workshop that matches the uncertainty you actually have. If the problem is unclear, run Problem Framing — and let the output tell you what comes next. If the problem is clear and the solution is genuinely unknown until tested with users, run a Design Sprint. If you're staring at a budget and a deadline and trying to fit one of these in because everyone else does, neither of these is the right move yet.

"We're not sure the problem is big enough to justify a sprint."

That's exactly what Problem Framing is for. The honest output of a good framing day is sometimes "this isn't worth doing." Saving the cost of a sprint that shouldn't have run is a real outcome — and one that gets remembered.

The bottom line

The decision is simpler than it looks. Read your situation honestly, and pick the method that matches the uncertainty you actually have.

If the disagreement is about what to solve — Problem Framing.

If the disagreement is about whether the solution will work — Design Sprint.

If neither describes where you are right now — the right answer might be research, a roadmap conversation, or no workshop at all. Workshops aren't free, and the wrong one is more expensive than no workshop.