Guides teams through Look Inward (examine biases and assumptions), Look Outward (understand who experiences the problem and who's been left out), and Reframe (synthesize into actionable problem statement and \"How Might We\" question)
Surfaces overlooked stakeholders, marginalized voices, and who benefits from the problem existing, ensuring equity-driven framing
Confirm successful installation by checking the skill directory location:
.cursor/skills/problem-framing-canvas
Restart Cursor to activate problem-framing-canvas. Access via /problem-framing-canvas in your agent's command palette.
β
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
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:
Look Inward β Examine your own assumptions, biases, and how you might be part of the problem
Look Outward β Understand who experiences the problem, who benefits from it, and who's been left out
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)
Adaptation: Use personas from context (proto-personas, JTBD, customer research)
User response: [Detailed description]
Agent captures:
Who experiences it: [Personas/segments]
When/where: [Context]
Consequences: [Impact]
Question 5: Who else has this problem? Who doesn't have it?
Agent asks:
"Who else has this problem? (Colleagues, competitors, other domains?) And who doesn't have it?"
Agent prompts:
Who else has it: Other companies, industries, or domains with similar problems
How do they deal with it: Workarounds, solutions, or adaptations
Who doesn't have it: Users/companies that avoid the problem (what's different about them?)
User response: [Detailed description]
Agent captures:
Who else has it: [Examples]
Who doesn't have it: [Counter-examples]
Question 6: Who's been left out? Who benefits?
Agent asks:
"Who's been left out of the conversation so far? And who benefits when this problem exists or doesn't exist?"
Agent prompts:
Who's been left out: Marginalized voices, edge cases, overlooked stakeholders
Who benefits when problem exists: Who gains from the status quo?
Who benefits when problem doesn't exist: Who loses if problem is solved?
Example:
"Who benefits when onboarding is broken?" β "Sales team doesn't have to support complex workflows; engineering doesn't have to build guided flows"
"Who's been left out?" β "Non-technical users, international customers (onboarding in English only)"
User response: [Detailed description]
Agent captures:
Who's been left out: [List]
Who benefits (problem exists): [List]
Who benefits (problem solved): [List]
Phase 3: Reframe
Goal: Synthesize insights into a clear, actionable problem statement and "How Might We" question.
Question 7: Restate the problem
Agent says:
"Based on everything we've explored, let's restate the problem in a new way."
Agent generates a refined problem statement using insights from Phases 1-2:
Template:
"The problem is: [Who] struggles to [accomplish what] because [root cause], which leads to [consequence]. This affects [specific segments] and has been overlooked because [bias/assumption from Phase 1]."
Example (SaaS onboarding):
"The problem is: Non-technical small business owners struggle to activate our product during onboarding because we use jargon-heavy UI and lack guided workflows, which leads to 60% abandonment within 24 hours. This disproportionately affects solopreneurs without technical support, and has been overlooked because our team optimizes for enterprise users who have IT departments."
Agent asks:
"Does this restatement capture the core problem? Should we refine it?"
User response: [Approve or modify]
Question 8: Create "How Might We" statement
Agent says:
"Now let's make it actionable with a 'How Might We' statement."
Template:
"How might we [action that addresses the problem] as we aim to [objective/desired condition]?"
Example (SaaS onboarding):
"How might we guide non-technical users through onboarding with plain-language prompts as we aim to increase activation from 40% to 70%?"
Agent asks:
"Does this HMW statement set up the right solution space? Should we adjust?"
User response: [Approve or modify]
Output: Problem Framing Canvas + HMW Statement
After completing the flow, the agent outputs:
# Problem Framing Canvas: [Problem Name]**Date:** [Today's date]
---## Phase 1: Look Inward### What is the problem? (Symptoms)[Description from Q1]
### Why haven't we solved it?- [Barrier 1 from Q2]
- [Barrier 2]
- [Barrier 3]
### How are we part of the problem? (Assumptions & biases)- [Assumption 1 from Q3]
- [Assumption 2]
- [Assumption 3]
**Which of these might be redesigned, reframed, or removed?**[Reflection on biases to challenge]
---## Phase 2: Look Outward### Who experiences the problem?**Who:** [Personas/segments from Q4]
**When/Where:** [Context]
**Consequences:** [Impact on users]
**Lived experience varies:** [How different users experience it differently]
### Who else has this problem?**Who else:** [Examples from Q5]
**How they deal with it:** [Workarounds]
### Who doesn't have it?[Counter-examples from Q5]
### Who's been left out?[Marginalized voices from Q6]
### Who benefits?**When problem exists:** [Beneficiaries of status quo]
**When problem doesn't exist:** [Who loses if solved]
---## Phase 3: Reframe### Stated another way, the problem is:[Refined problem statement from Q7]
### How Might We...**How might we** [action from Q8] **as we aim to** [objective from Q8]?
---## Next Steps1.**Validate with users:** Use `skills/discovery-interview-prep/SKILL.md` to test reframed problem with customers
2.**Generate solutions:** Use `skills/opportunity-solution-tree/SKILL.md` to explore solution space
3.**Create problem statement:** Use `skills/problem-statement/SKILL.md` to formalize for PRD/roadmap
4.**Identify opportunities:** Use HMW statement to brainstorm solution ideas
---**Ready to explore solutions? Let me know if you'd like to refine the problem framing or move to solution generation.**
Examples
See examples/sample.md for full problem framing examples.
Mini example excerpt:
**Look Inward:
β
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
βΊAccess to product documentation and roadmap tools (Jira, Notion, etc.)
βΊUnderstanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
βΊStakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
β Not validating competitive researchβverify facts before sharing
β Accepting user stories without involving engineering team
β Over-relying on frameworks without qualitative judgment
β Not customizing outputs to company culture and communication style
β Skipping stakeholder validation of generated requirements
Best Practices
β Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
β Don't
βDon't publish competitive analysis without fact-checking
βDon't finalize user stories without engineering review
βDon't make prioritization decisions solely on AI scoring
βDon't skip customer validation of generated requirements
βDon't ignore company-specific context and culture
π‘ Pro Tips
β Provide context: company goals, constraints, customer feedback
β Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
β Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
β Use skill for 70% generation + 30% customization to company needs
When to Use This
β Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
β Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates