problem-framing-canvas

Purpose

Guide product managers through the MITRE Problem Framing Canvas process by asking structured questions across three phases: Look Inward (examine your own assumptions and biases), Look Outward (understand who experiences the problem and who doesn't), and Reframe (synthesize insights into an actionable problem statement and "How Might We" question). Use this to ensure you're solving the right problem before jumping to solutions—avoiding confirmation bias, overlooked stakeholders, and solution-first thinking.

This is not a solution brainstorm—it's a problem framing tool that broadens perspective, challenges assumptions, and produces a clear, equity-driven problem statement.

Key Concepts

What is the MITRE Problem Framing Canvas?

The Problem Framing Canvas (MITRE Innovation Toolkit, v3) is a structured framework that helps teams explore a problem space comprehensively before proposing solutions. It's partitioned into three areas:

1. Look Inward — Examine your own assumptions, biases, and how you might be part of the problem
2. Look Outward — Understand who experiences the problem, who benefits from it, and who's been left out
3. Reframe — Synthesize insights into a clear, actionable problem statement and "How Might We" question

Canvas Structure

┌─────────────────────────────────────────────────────────────────┐
│ LOOK INWARD                                                     │
│ - What is the problem? (symptoms)                              │
│ - Why haven't we solved it? (new, hard, low priority, etc.)   │
│ - How are we part of the problem? (assumptions, biases)       │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ LOOK OUTWARD                                                    │
│ - Who experiences the problem? When/where/consequences?        │
│ - Who else has it? Who doesn't have it?                       │
│ - Who's been left out?                                        │
│ - Who benefits when problem exists/doesn't exist?             │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│ REFRAME                                                         │
│ - Stated another way, the problem is: [restatement]           │
│ - How might we [action] as we aim to [objective]?             │
└─────────────────────────────────────────────────────────────────┘

Why This Works

• Broadens perspective: Forces you to look beyond your own assumptions
• Equity-driven: Centers marginalized voices and asks "who's been left out?"
• Challenges biases: Requires explicit examination of assumptions before framing problem
• Actionable output: Produces HMW statement ready for solution exploration

Anti-Patterns (What This Is NOT)

• Not a solution brainstorm: Canvas frames the problem; solutions come later
• Not a feature request list: Focuses on underlying problems, not surface symptoms
• Not a one-person exercise: Requires diverse perspectives to challenge groupthink

When to Use This

• Starting discovery for a new initiative
• Reframing an existing problem (suspect you're solving the wrong thing)
• Challenging assumptions before building solutions
• Aligning cross-functional teams on problem definition

When NOT to Use This

• When the problem is already well-understood and validated
• For tactical bug fixes or technical debt (no deep framing needed)
• When stakeholders have already committed to a solution (address alignment first)

Facilitation Source of Truth

Use workshop-facilitation as the default interaction protocol for this skill.

It defines:

• session heads-up + entry mode (Guided, Context dump, Best guess)
• one-question turns with plain-language prompts
• progress labels (for example, Context Qx/8 and Scoring Qx/5)
• interruption handling and pause/resume behavior
• numbered recommendations at decision points
• quick-select numbered response options for regular questions (include Other (specify) when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

Application

Use template.md for the full fill-in structure.

This interactive skill follows a three-phase process, asking adaptive questions in each phase.

Step 0: Gather Context (Before Questions)

Agent suggests:

Before we frame your problem, let's gather context:

Problem Context:

• Initial problem statement or stakeholder request
• Symptoms you've observed (support tickets, churn data, user complaints)
• Existing research (user interviews, surveys, analytics)
• Assumptions you're making about the problem

Stakeholder Context:

• Who's affected by this problem? (users, customers, internal teams)
• Who's asking for this to be solved? (execs, sales, customers)
• Who might have been overlooked?

You can paste this content directly, or describe the problem briefly.

Phase 1: Look Inward

Goal: Examine your own assumptions, biases, and how you might be part of the problem.

Question 1: What is the problem? (Describe symptoms)

Agent asks: "What is the problem as you currently understand it? Describe the symptoms."

Offer 4 enumerated options:

1. Customer pain point — "Customers struggle with [specific task/outcome]" (e.g., "Customers can't find features they need")
2. Business metric problem — "We're seeing [metric decline]" (e.g., "Churn increased 15% last quarter")
3. Stakeholder request — "Stakeholders say we need [feature/change]" (e.g., "Sales team says we need better reporting")
4. Observed behavior — "We've noticed [pattern/trend]" (e.g., "Users abandon onboarding at step 3")

Or describe your problem/symptoms.

User response: [Selection or custom]

Agent extracts:

• Problem (initial framing): [Description from user]

Question 2: Why haven't we solved it?

Agent asks: "Why hasn't this problem been solved yet?"

Offer 6 enumerated options (can select multiple):

1. It's new — "Problem recently emerged"
2. It's hard — "Technically complex or resource-intensive"
3. It's low priority — "Other initiatives took precedence"
4. Lack of resources — "Not enough budget, people, or time"
5. Lack of authority — "Can't make the decision or get buy-in"
6. A systemic inequity — "Problem disproportionately affects marginalized groups, overlooked"

Or describe your own reason.

User response: [Selection or custom]

Agent captures:

• Barriers to solving: [List of reasons]

Question 3: How are we part of the problem? (Assumptions & biases)

Agent asks: "How might you (or your team) be part of the problem? What assumptions or biases are you bringing?"

Offer 4 enumerated options:

1. Assuming we know what customers want — "We haven't validated with real users" (Confirmation bias)
2. Optimizing for ourselves, not users — "Building what's easy for us, not what's valuable for them" (Internal bias)
3. Overlooking specific user segments — "Focused on majority users, ignored edge cases or marginalized groups" (Survivorship bias)
4. Solution-first thinking — "Jumped to 'we need [feature X]' before understanding root problem" (Premature convergence)

Or describe your specific assumptions/biases.

User response: [Selection or custom]

Agent captures:

• Assumptions to challenge: [List of biases]

Phase 2: Look Outward

Goal: Understand who experiences the problem, who benefits from it, and who's been left out.

Question 4: Who experiences the problem? (When, where, consequences)

Agent asks: "Who experiences this problem? When and where do they experience it? What consequences do they face?"

**Agent prompts user to de