Dean Peters 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.
- Translating a vague leadership ask into a crisp problem statement before committing it to an OKR or quarterly roadmap theme.
- Opening a discovery sprint by aligning the team on the problem space before generating solution hypotheses or prototypes.
- Producing 'How might we' questions that seed design studio sessions, brainstorming, or backlog generation for an epic.
- Preparing a stakeholder briefing or steering-committee deck that frames the problem and scope to align partners with conflicting priorities.
- Running a checkpoint during roadmap reviews to confirm in-flight initiatives still map to the originally framed problem, not scope creep.
Benefits
- You can’t waste time on this tool! It could be a 30-second exercise if team is on same page. If it takes longer than 30 seconds, that is time worth spending.
Common Pitfalls
- Writing a problem statement that smuggles in a predetermined solution ('users need a dashboard') which forecloses ideation and biases the team toward a feature they already wanted to build.
- Filling the canvas with team assumptions and no external research or user evidence, producing a confident statement that's wrong about who's affected and why.
- Framing the problem in a closed, insular team without bringing in stakeholders or affected populations, so non-primary users and downstream impacts get missed entirely.
- Writing 'How might we' questions that are too broad ('How might we delight users') to be actionable or too narrow that they merely restate a feature.
- Treating the canvas as a one-time kickoff artifact and never revisiting it, so the team keeps executing against a problem definition that has since drifted or been invalidated.
- Rushing to consensus on the first plausible framing to avoid uncomfortable disagreement, locking in a shallow problem definition that resurfaces as rework mid-build.
Combine With
Lotus Blossom beforehand to brainstorm problem areas, Lotus Blossom afterwards to brainstorm possible solutions Stakeholder Identification Canvas to better understand who does/doesn’t benefit TRIZ Prism to solve the specific problem you come up with in the Problem Framing canvas
Assets
- PDF: Download
- Markdown Template: template.md
Metadata
| Field | Value |
|---|---|
| ITK Phase | DEFINE |
| Difficulty | Beginner |
| Group Size | 2+ people |
| Time Required | 45+ minutes |
| Source | itk.mitre.org |