| name | itk-problem-framing |
| description | Explore a problem space and formulate a robust problem statement to ensure you’re solving the right problem. |
| intent | Establish consensus about the team’s purpose Gain a sense of what “done” will look like Define the scope of a team’s initial activities and goals Reduce the likelihood of working at cross purposes |
| type | component |
| phase | define |
| outcome | define |
| difficulty | beginner |
| group_size | 2+ people |
| time_required | 45+ minutes |
| best_for | ["Early discovery when the problem space is ambiguous and stakeholders disagree on what to build first","Reframing a vague executive mandate or feature request into a validated, solvable problem statement","Kicking off a new initiative where the team risks jumping to solutions before understanding root causes","Aligning cross-functional partners with conflicting priorities around a shared definition of the problem","Periodic checkpoints to verify the team is still solving the right problem as understanding evolves"] |
| sources | ["MITRE Innovation Toolkit (ITK)","https://itk.mitre.org/toolkit-tools/problem-framing/"] |
Problem Framing
What Is It
Explore a problem space and formulate a robust problem statement to ensure you’re solving the right problem.
Why Use It
Establish consensus about the team’s purpose Gain a sense of what “done” will look like Define the scope of a team’s initial activities and goals Reduce the likelihood of working at cross purposes
When to Use It
When starting a project, revising it periodically to track your progress.
How to Do It
- Use the canvas by yourself or in a group. Doing some quick research to collect any necessary information, statistics, or data may be helpful prior to or during the activity.
- Begin in the upper left corner and capture some words about the problem area.
- Work through the remaining boxes on the canvas and return to the first box throughout the process as your understanding of the problem develops. Feel free to skip any questions that do not seem to apply.
- Use your inputs to build a problem statement in the bottom box and turn it into an actionable “How might we…” question.
Key Concepts
Problem Statement — A concise, evidence-grounded articulation of who experiences what difficulty and why it matters. It anchors scope and gives the team a shared definition of success before any solution work begins.
How Might We (HMW) — An open-ended, action-oriented question reframing the problem as an opportunity for ideation. It must be narrow enough to be actionable but broad enough not to presuppose a single solution.
Problem Space vs. Solution Space — The discipline of fully understanding the problem (users, context, constraints, stakes) before designing solutions. Conflating the two leads to premature commitment to features that don't address the real need.
Framing Canvas — A structured set of prompts—problem area, affected populations, current state, desired outcome—that forces explicit articulation of assumptions. Iterating across boxes surfaces gaps and biases in the team's understanding.
Equity Lens — Deliberately considering non-primary and marginalized stakeholders who may be impacted by the problem or solution. It counters insular team thinking and the tendency to optimize only for the dominant user segment.
Assumption Surfacing — Making implicit beliefs about users, causes, and constraints explicit so they can be tested. Unexamined assumptions baked into a problem statement propagate into the roadmap as untested risk.
PM Applications
- Drafting the problem statement and 'goals' sections of a PRD so engineering and design start from a shared, evidence-backed definition rather than a feature spec.
