When to use Problem Framing, Foundation Sprints, and Design Sprints

Why method choice matters more than method skill

The most common mistake teams make is not running a workshop badly. It is running the wrong workshop.

A team with a vague problem runs a Design Sprint and produces a beautifully prototyped solution to a problem nobody validated. A team with three competing solutions runs Problem Framing and spends a day on alignment when the real disagreement was about approach. A team with a fully validated direction runs a Foundation Sprint and rehashes a strategy decision that was already made.

None of these failures are about facilitation quality. They are about method-fit. Picking the right method for the moment is the highest-leverage decision in any structured collaborative work. This article is the field guide for making that choice well.

The three methods covered here — Problem Framing, the Foundation Sprint, and the Design Sprint — are not competing approaches. They solve different parts of the same larger challenge: moving from uncertainty to validated direction without wasting time, money, or organizational political capital.

What is Problem Framing?

Problem Framing is a one-day decision-making workshop that helps senior decision-makers align on the right problem to solve before any solution work begins. It is upstream of everything else.

Core principle: Start the right way.

What it produces: A validated problem statement — grounded in real data and insights, not assumptions. The problem statement specifies who is experiencing the problem, what the problem actually is, when or where it occurs, and why it is worth solving.

Duration: One day for the workshop itself. Two to three weeks of preparation beforehand to gather and visualize the data that the workshop runs on.

Who is in the room: Senior decision-makers and stakeholders — the people with authority over the direction the work will take. Subject matter experts are typically not in the workshop itself; their insights are gathered ahead of time and visualized for the room. The workshop's job is to make decisions, not to surface new technical input.

When to use it: When the problem is unclear, complex, or contested. When stakeholders disagree about priorities. When the team is at the start of a major initiative and needs to set direction before commitments are made. When existing strategy work has produced a vague mandate and the team needs to translate it into something specific.

The preparation phase is often what makes or breaks a Problem Framing engagement. The workshop itself runs on the data brought into it. If the room arrives with weak insights, the decisions made on top of those insights will be weak. The two to three weeks of upstream work — user interviews, ethnographic research, internal data, competitive landscape, customer journey maps — is not optional. It is the workshop.

What is the Foundation Sprint?

The Foundation Sprint is a two-day structured workshop developed by Jake Knapp and John Zeratsky, introduced in their book Click. It helps teams stress-test early ideas and produce a testable hypothesis before committing significant resources to building.

Core principle: Get started, not perfect.

What it produces: A founding hypothesis — a clear, testable statement of who the customer is, what core problem is being solved, the proposed approach, and what makes it different from alternatives. Jake Knapp himself describes this as a best-guess hypothesis. The honesty of that framing matters: a Foundation Sprint produces an informed direction worth testing, not a validated answer.

Duration: Two days, with minimal preparation required — though preparation does help. If a Problem Framing session has been done first, the Foundation Sprint can skip the brief problem-alignment portion and move faster into approach exploration.

Who is in the room: A mix of strategic decision-makers and hands-on subject matter experts. This is the key team-composition difference from Problem Framing. The Foundation Sprint is making decisions about approach — which means the room needs both the authority to set direction and the technical depth to know what is feasible.

When to use it: When the problem is clear but the right approach is uncertain. When the team has one preferred solution in mind and needs to challenge that thinking before committing. When the team is at risk of rushing into execution with unexamined assumptions. When multiple approaches are on the table and a structured way to compare them is needed.

The Foundation Sprint looks deceptively simple from the outside. The actual day-two work — generating multiple approaches, evaluating them through different lenses, selecting a primary direction with a backup plan, and forming a testable hypothesis — is intellectually demanding. Teams often underestimate how hard this thinking is until they are in it.

What is the Design Sprint?

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

Core principle: Fail fast, learn fast.

What it produces: A high-fidelity prototype and direct customer feedback on it — enough evidence to make a build-iterate-kill decision with confidence.

Duration: Four days. Day one for problem deep-dive and sprint focus. Day two for individual ideation and concept selection. Day three for prototyping. Day four for user testing.

Who is in the room: A cross-functional team of hands-on subject matter experts — the people who can actually create solutions. Designers, engineers, AI specialists, domain experts, customer-facing staff. A decider needs to be in the room (or have a clear delegate) for the day-two convergence decision, but the bulk of the team is hands-on builders, not strategic leaders.

When to use it: When the problem is clear and the team is ready to test how to solve it. When customer validation is required to de-risk an investment decision. When the team needs to compress months of build-test-iterate cycles into a single week. When new ground is being explored and there is genuine uncertainty about what the right solution looks like.

The Design Sprint deliberately layers on top of clarity that exists somewhere upstream. It does not redefine the problem. The day-one mapping and expert input are about adding texture and constraint awareness to a problem the team already understands — not about discovering the problem from scratch. Teams that arrive at a Design Sprint without that upstream clarity often spend days one and two doing Problem Framing work badly, and end up with weaker prototypes as a result.

What do the three methods have in common?

The differences between these methods are real, but they share a deeper set of traits that separate all three from how organizations usually make decisions.

They are all fast. Traditional decision-making in large organizations runs on endless meetings and slow consensus. These methods compress the work into focused, time-boxed bursts — a day, two days, or a week. The compression is what makes them work.

They are all highly collaborative. Each one requires cross-functional participation. None of them work as solo or hierarchical exercises. The point is to bring people who would normally not work together into the same room, working on the same problem, at the same moment.

They all produce shared clarity. The output is not a slide deck someone reads later. The participants leave the room with the same understanding of what was decided, why, and what comes next. This is the antidote to the most common failure mode in enterprise decision-making: meetings that end with people walking out with different understandings of what just happened.

They all produce actionable outcomes. No method produces "let's schedule another meeting" as its output. Problem Framing produces a problem statement. Foundation Sprint produces a hypothesis. Design Sprint produces a tested prototype. Each is a tangible artifact the team can act on immediately.

They are all user-centered. Problem Framing relies on real customer data to define the right problem. Foundation Sprint develops hypotheses centered on real users. Design Sprint tests with real customers at the end. The user is in the room — directly or through their data — in every method.

These commonalities matter when choosing between methods. The decision is rarely whether to use a structured method versus traditional meetings. The structured method will outperform almost every time. The decision is which structured method fits the moment.

What is the decision logic for choosing between them?

The simplest way to choose:

• Problem unclear or contested? → Problem Framing.
• Problem clear, approach uncertain or unchallenged? → Foundation Sprint.
• Problem clear, solution uncertain, ready to test with users? → Design Sprint.

‍

The full decision logic, with the edge cases:

Choose Problem Framing when:

• A major project or initiative is being launched and direction is not yet set.
• Stakeholders disagree about what the priority is, what success looks like, or which customer matters most.
• The team has a vague mandate ("do something with AI," "explore opportunities in segment X," "figure out our digital strategy") and needs to translate it into a specific problem worth solving.
• A previous attempt at a solution failed, and the team suspects they were solving the wrong problem.
• High stakes are involved and the cost of working on the wrong problem is significant.

‍

Choose the Foundation Sprint when:

• The problem is clear, but the right approach is uncertain.
• The team is gravitating toward one solution and that thinking has not been challenged.
• Multiple plausible approaches exist and a structured comparison is needed.
• The team is about to commit serious resources to building and wants a final sense-check before committing.
• A solution has already been chosen by leadership but the team has not pressure-tested whether it is the right one. The Foundation Sprint is a graceful way to introduce that challenge.

‍

Choose the Design Sprint when:

• The problem is clear and the team is ready to explore how to solve it.
• Customer validation is required before development.
• A specific solution direction has been chosen and needs to be tested with users before build.
• The team needs to compress what would normally be a months-long build-test-iterate loop into a single week.
• Risk reduction before development is the primary goal.

‍

Run them in sequence when:

• The challenge is significant enough to justify the full pipeline. Problem Framing → Foundation Sprint → Design Sprint is the full path: align on the right problem, choose the right approach, build and test the right solution. Each stage de-risks the next.
• A team has a solution and needs to validate both the strategic direction and the customer fit. Foundation Sprint → Design Sprint is the right combination here: pressure-test the approach, then prototype and validate with users.
• A previous Design Sprint produced a prototype that did not test well, and the team suspects the upstream framing was wrong. Problem Framing as a recovery move makes sense.

‍

‍

How are they different in team composition?

This is one of the most consequential differences and one of the most commonly missed.

Problem Framing

Decision-makers, not builders. The room is senior leaders and key stakeholders — the people with authority over direction. Subject matter experts and technical specialists do not attend the workshop itself. Their insights are gathered in the preparation phase and visualized into the materials the workshop runs on. Bringing technical experts into the workshop dilutes the dynamic; the room ends up debating implementation details when the work is to make strategic decisions.

Foundation Sprint

Mixed strategic and technical. Both decision-makers and hands-on experts are in the room. The Foundation Sprint is making decisions about approach, which requires the authority to commit and the technical depth to know what is feasible. A Foundation Sprint without technical depth produces visionary hypotheses that cannot be built. A Foundation Sprint without decision-makers produces clever ideas that cannot be acted on.

Design Sprint

Mostly hands-on builders, one decider. The team is the people who can build and test the solution — designers, engineers, AI specialists, domain experts. A decider is essential for the day-two convergence, but the bulk of the team is doing the actual making. Strategic leaders sitting in for the full sprint typically slow the work down without contributing what the sprint specifically needs.

Where to start

If you are choosing a method for a specific upcoming engagement, the question is not which method is best. It is which uncertainty are you currently sitting on?

If you are uncertain about what problem to solve, Problem Framing is the move. The cost of starting building work on the wrong problem is the most expensive failure in this stack — measured in months of effort and stakeholder credibility.

If you are uncertain about which approach to take, the Foundation Sprint is the move. The cost of committing to the wrong approach without challenging it is the second most expensive failure — weeks to months of build work pointed in a direction that did not need to be the chosen one.

If you are uncertain about whether your solution actually works for users, the Design Sprint is the move. The cost of skipping this stage is shipping a product no one adopts.

The three methods are not interchangeable. Each one is the right answer to a specific kind of uncertainty. Picking well is the most important decision you make before the workshop starts.

‍