What is Problem Framing?

February 22, 2023
Dana Vetan

Problem Framing is the structured work that happens before you start building — making sure the team is solving the right problem, with the right stakeholders aligned, before time, budget, or engineering resources are committed. This article explains what it is, when to use it, and how it works.

Read this if your team keeps solving problems that don't stick, or if stakeholders can't agree on what to prioritize.

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.

What is Problem Framing?

Most teams don't have a shortage of ideas. They have a shortage of clarity about which problem is actually worth solving.

That's the gap Problem Framing fills. It's not a brainstorm, and it's not a kickoff meeting. A kickoff is about starting something new. Problem Framing is about making sure you start working on the right thing. It exists for a specific kind of situation: when the problem is complicated enough that there are multiple plausible directions and no obvious way to choose between them — or when the problem is so complex it needs to be broken into smaller, testable chunks before anyone can act on it.

The output isn't a solution. It's a well-defined problem statement — or several, each functioning as a hypothesis to be tested — and a room full of senior leaders who have reached genuine alignment on what matters most.

Why problem framing matters

Misaligned priorities. Stakeholders with competing views. Teams working hard in different directions. These aren't just communication problems — they're symptoms of a decision that was never properly made at the start.

Without clarity at the top, everything downstream becomes harder: roadmaps, prioritization, sprint planning, budgets. The work continues, but it's operating without a reliable foundation.

Problem Framing addresses this directly by:

  • Aligning senior decision-makers who see the problem differently — giving them a structured process to reach a shared position rather than a negotiated compromise
  • Connecting business objectives with real customer needs before any solution work begins
  • Producing a clear, agreed problem statement that teams can actually act on

Need to run decision-making like a pro?

Join the Problem Framing Course

Learn the Problem Framing method that helps teams make calls, set priorities, and get stakeholders on the same page—in one day.

Do you need problem framing?

Not every challenge requires Problem Framing. It's a tool for specific situations, not a standing ritual.

Use it when:

  • The problem is unclear or contested among stakeholders
  • There are too many possible directions and no agreed criteria for choosing
  • The team is stuck — meetings multiply, but decisions don't get made
  • A complex challenge needs to be broken into smaller, independently testable problems
  • Leadership needs to align before a significant investment is approved

‍

❌ Don't use it when the problem is already well-defined, the direction is set, and stakeholders are genuinely aligned. In that case, you need execution — not another workshop.

‍

The 2x2 above maps the four situations teams find themselves in. The goal of Problem Framing is to move teams from the bottom two quadrants — where decisions are driven by the loudest voice or disconnected from user reality — into the top right: where a real business problem meets validated user insight.

  1. HIPPO Guesswork — Wrong problem, stakeholder-driven. The highest-paid person in the room decides the direction without evidence. Months later, the product misses.
  2. Misplaced Empathy — Wrong problem, user-driven. The team is laser-focused on users but can't connect customer needs to business value. By the time the misalignment is visible, too much has been built to stop.
  3. Ivory Tower — Right problem, no user input. Business metrics point in the right direction, but without user validation, the solution falls flat in the market.
  4. Sweet Spot — Right problem, user-centric. Business priorities and user insights converge. This is where Problem Framing aims to take you.

‍

Why do teams skip problem framing?

Despite the cost of skipping it, most teams do. The reasons are predictable — and worth naming:

"We already know what the problem is."

Treating the symptom isn't the same as solving the core problem. Obvious symptoms often mask deeper causes that only surface when you slow down enough to look.

"It's uncomfortable and it's hard work."

Sitting with ambiguity, questioning long-held assumptions, and making real decisions without certainty is genuinely difficult. But the discomfort is where the clarity comes from.

"I need to meet my deadlines."

Meeting short-term delivery targets by skipping problem definition almost always creates longer delays downstream — when the thing that was built turns out not to solve the right problem.

"My calendar is full. I feel busy."

Being busy and being effective are different things. Problem Framing requires slowing down in a specific, structured way — not to create process for its own sake, but to make the acceleration that follows more reliable.

The path to meaningful outcomes isn't paved with shortcuts. It's built on the willingness to do the hard work of defining the problem before touching the solution.

What is Problem Framing?

Problem Framing is a structured process to uncover, define, and prioritize challenges. It connects business objectives with customer needs and helps leaders align on a clear direction before diving into execution.

In design thinking, there is an "understand" phase. Problem Framing is the recipe that makes that phase actionable. It's not a vague exploration — it's a step-by-step process with clear inputs, structured exercises, and a defined output: a problem statement your stakeholders have agreed to act on.

At its core, Problem Framing combines product discovery with a strategic decision-making process.

How Problem Framing works: the three phases

Phase 1: Discovery (1–3 weeks)

This is where you systematically explore data, uncover opportunities, and define what's actually worth solving. It involves:

  • Identifying a range of potential opportunities — prioritizing those with the highest impact across both business objectives and user needs
  • Defining your Minimum Viable Customer Segment — getting precise about who you're solving for, their jobs-to-be-done, pain points, and decision triggers
  • Validating with existing data — gathering proof before making assumptions. Most organizations already have relevant research, customer feedback, or analytics. If gaps remain, targeted qualitative interviews fill them.

By the end of Discovery, you have a structured, data-backed view of which opportunities are worth pursuing — and which to discard.

Phase 2: Workshop Preparation

This is where insights from Discovery get shaped into materials that drive decisions, not just presentations.

Two things matter here:

  • Getting the right stakeholders in the room — every major technical, strategic, and financial decision-maker needs to be present. Alignment is significantly harder to achieve when key people hear the same data at different times.
  • Making data visual and tangible — customer journey maps, personas, and pain point visualizations shift the conversation from opinion to evidence. When stakeholders can see and interact with data, they engage with it rather than argue past it.

‍

Phase 3: Workshop Facilitation

This is where everything comes together.

Problem Framing is not about brainstorming—it’s about making decisions.

Too many workshops fail because they rush into solutions or rely on open-ended discussions that go nowhere. This process ensures that every decision is grounded in business needs, customer insights, and structured facilitation.

The workshop follows a four-phase process that balances divergence and convergence, business priorities and user needs:

01. Contextualize the Problem — Stakeholders share their understanding of the current situation before any prioritization begins. People buy into decisions they helped shape.

02. Justify the Business Need — Stakeholders diverge on their vision of the future, then converge on shared goals and measurable success criteria. Abstract ambition becomes concrete, quantifiable direction.

03. Understand the Customer — Data isn't just presented — it's experienced. Customer journey maps and personas are used interactively, so decisions are evidence-based rather than assumption-driven.

04. Define the Problem Statement — With shared understanding of both business goals and customer needs, stakeholders connect the dots: where do priorities align? What is the clearest, most actionable way to define the challenge?

The output is a well-defined problem statement — or multiple statements functioning as hypotheses — that every key decision-maker has agreed to.

‍

👉 Learn more about this structured approach in this free lesson from our Problem Framing Masterclass:

‍

When to Use Problem Framing: Four Key Scenarios

Knowing when to use Problem Framing is just as important as knowing how to use it. Whether you’re launching a new product, prioritizing features, or trying to align your team, Problem Framing can make the difference between floundering and flourishing.

‍

01. Launching a New Value Proposition

You've researched the market and identified an opportunity — but you're struggling to get stakeholder buy-in on the direction. Problem Framing involves stakeholders in the prioritization process from the start, ensuring alignment before validation begins rather than after.

How Problem Framing helps:

  • Involves stakeholders in prioritizing opportunities that align with business goals—so you don’t have an uphill battle with them later.
  • Forces you to find proof that the problem really exists for your customers—so you’re not building based on assumptions.
  • Ensures early stakeholder buy-in on the problem statement—so all key decision-makers are on the same page from the start.

‍

‍02. Agile Development & Feature Prioritization

Sprints are running, but priorities keep shifting. Stakeholders push for competing features, and without a shared decision-making framework, everything feels urgent and nothing feels strategic. Problem Framing establishes that framework — so prioritization is based on evidence, not the loudest request.

How Problem Framing helps:

  • Brings all stakeholders together at the same table—so instead of reacting, they align on what truly matters.
  • Uses data to drive decisions—so prioritization isn’t based on opinion or gut feeling, but on real customer needs.
  • Creates a clear, structured prioritization process—so teams focus on impactful features, not just the loudest requests.

With Problem Framing, you stop chasing and start leading—prioritizing with clarity.

‍

03. Fixing the Innovation Funnel

Ideas are plentiful, but most don't get built — because leadership can't agree on which ones tie to the right business problems. Problem Framing creates a systematic way to evaluate and filter ideas against shared criteria, turning an idea graveyard into a strategic pipeline.

How Problem Framing helps:

  • Creates a systematic way to prioritize and filter ideas—so resources are focused on high-impact opportunities, not just the loudest voices.
  • Aligns leadership on decision criteria—so innovation isn’t stalled by competing perspectives.
  • Ensures ideas are tied to real business problems—so leadership sees a clear case for investment.

With Problem Framing, you don’t just collect ideas—you build a strategic pipeline that turns innovation into real business impact.

‍

04. Before Running Design Sprints

‍Design Sprints are a powerful tool for rapidly prototyping and testing ideas, but here’s the catch: design sprints are a problem solving method, they are not a problem definition one. Before you dive into solution mode, you need to ensure that you’re solving the right problem—and that’s where Problem Framing comes in.

You’ve gathered a cross-functional team, you’re ready to prototype, but you’re not entirely sure if everyone agrees on what the real challenge is. Maybe stakeholders have different definitions of success, or the problem space feels too broad. Without alignment, even the best-designed sprint can miss the mark.

How Problem Framing Helps:

  • Clarifies the problem space before the sprint begins—so your team focuses on the most meaningful challenges.
  • Aligns stakeholders on key objectives and success metrics—ensuring everyone is on the same page.
  • Identifies assumptions and gaps early on—so the sprint team isn’t blindsided mid-process.

With Problem Framing, you set the foundation for a Design Sprint that’s not just fast, but effective—delivering solutions that solve the right problems.

These scenarios show that Problem Framing isn’t just a one-time process—it’s a versatile tool that can be applied across different stages of product development, innovation, and team alignment. Whether you’re refining a value proposition, navigating Agile chaos, managing an innovation pipeline, or prepping for a Design Sprint, Problem Framing ensures you’re always solving the right problem—the first time.

05. Before AI Initiatives

In 2026, the most common reason teams come to us isn't a design sprint or an innovation funnel. It's an AI mandate.

The pattern is consistent. Leadership has decided AI matters. Budget has been approved unusually fast. A list of 20 or 30 AI ideas exists — some bottom-up from employees who spotted repetitive tasks, some top-down from the board, some inspired by what competitors are doing. The team is now expected to deliver. What's missing is a way to compare the ideas, decide which ones are worth pursuing, and commit resources without months of internal politics.

This is exactly where Problem Framing earns its place — but with one important distinction. There are now two methods, working at two different altitudes.

How Problem Framing helps:

  • Clarifies the strategic problem before the AI portfolio gets built — so the team isn't responding to a vague mandate with a list of disconnected pilots
  • Aligns senior leadership on which business problem AI is actually solving — separating "we should do AI" from "we should solve X, and AI might be the right approach"
  • Sets the boundary conditions for the AI work that follows — defining what's in scope, what isn't, and what success looks like in business terms

Problem Framing at this level decides whether AI is the right direction for a problem. Once that's settled, AI Problem Framing takes over — running cross-functional teams through which specific use cases to pursue, and which to drop. Both methods build on the same foundation. They run at different altitudes, with different people in the room, producing different decisions.

If you're at the strategic-investment stage — should we be putting AI resources here at all — Problem Framing is the right starting point. If you've already committed to AI as a direction and you're staring at a list of use cases trying to compare them, you're past Problem Framing. Read Problem Framing vs AI Problem Framing to see exactly when each one applies.

These scenarios show that Problem Framing isn’t just a one-time process—it’s a versatile tool that can be applied across different stages of product development, innovation, and team alignment. Whether you’re refining a value proposition, navigating Agile chaos, managing an innovation pipeline, or prepping for a Design Sprint, Problem Framing ensures you’re always solving the right problem—the first time.

Learn more about AI Problem Framing

AI Problem Framing Stages

FAQs

What is the difference between Problem Framing and a kickoff meeting?

A kickoff meeting is about starting something — communicating scope, roles, and timelines for work that's already been decided. Problem Framing is about deciding what work is worth starting in the first place. They're not interchangeable, and one doesn't replace the other.

A kickoff assumes the problem is defined. Problem Framing is what you do when it isn't — or when senior leaders don't yet agree on what it is.

What is the difference between Problem Framing and design thinking?

Design Thinking is a complete framework for both defining and solving problems. It covers the full arc — from empathizing with users through ideating, prototyping, and testing — and it's designed for large, complex challenges that require multiple iterations over time. It's a marathon, not a sprint, with an extensive library of tools and methods to draw from at each phase.

Problem Framing lives inside design thinking. Specifically, it's the step-by-step process that makes the "Define" phase of design thinking actionable. Design thinking tells you to understand the problem before solving it. Problem Framing gives you the specific exercises, facilitation structure, and decision-making framework to actually do that — with senior stakeholders in the room, in a single day, with a committed output at the end.

Where design thinking is broad and iterative, Problem Framing is focused and decisive. It's not a replacement for design thinking — it's what makes the hardest part of design thinking concrete enough to act on.

Who should be in a Problem Framing workshop?

Senior decision-makers — people with real authority over the budget, direction, and resources involved in the challenge. Problem Framing works precisely because it gets these people in the same room at the same time, interacting with the same evidence. Without the right stakeholders present, decisions made in the workshop won't hold when they leave it.

What is the output of a Problem Framing workshop?

A clearly defined problem statement — or several, each functioning as a hypothesis to be validated. These aren't solutions; they're precise articulations of the challenge, grounded in both business priorities and user evidence, that every key stakeholder has agreed to act on. The problem statement then becomes the brief for whatever comes next: a Design Sprint, an experiment, a research phase, or a resource allocation decision.

How is Problem Framing different from a regular strategy meeting?

Strategy meetings are typically opinion-driven: stakeholders share views, debate priorities, and often leave without a binding decision. Problem Framing is evidence-driven and decision-oriented. It uses structured facilitation, visual data, and specific exercises designed to move a group from divergent perspectives to a single, agreed direction. The output isn't a list of next steps — it's a committed problem statement.

What comes after Problem Framing?

Typically one of three things: a Design Sprint to prototype and test solutions to the defined problem; a targeted research phase if the problem statement surfaces gaps in user understanding; or a direct go/no-go decision on whether the problem is worth solving at all.

Problem Framing occasionally produces that third outcome — the realization that the challenge isn't worth the investment — which is equally valuable, because it saves resources that would otherwise be spent in the wrong direction.

Does Problem Framing work for AI initiatives?

Yes — but at a specific altitude. Use Problem Framing when the question is whether AI is the right direction for a business problem at all, or which strategic problem AI investment should target. Once that's settled and the team is staring at a list of specific AI use cases trying to compare them, you've moved past Problem Framing.

At that point, AI Problem Framing is the right tool — same underlying philosophy, different altitude, different people in the room. The comparison between the two is laid out in this article.

What happens after AI Problem Framing?

AI Problem Framing produces a clear, prioritized AI use case — but a defined use case isn't a validated solution. Before engineering invests, the team still needs to know whether the proposed AI approach actually works in the specific workflow, with real users, against the constraints that exist today.

That's where the AI Workflow Sprint comes in: a short, structured engagement designed to validate the chosen AI solution before significant resources are committed.

The progression looks like this: Problem Framing decides where AI matters strategically, AI Problem Framing decides which use cases to build, AI Workflow Sprint validates that the chosen solution actually works in context.