Problem Framing
Transform feature requests into specific, bounded problem statements by moving upstream from solutions to struggles.
Core Principle
Never accept a feature request at face value. The request "build a calendar" is a solution. The problem might be "users can't find available time slots for appointments." Framing reveals the actual struggle so the solution can be shaped appropriately.
The Framing Workflow
- •Receive the request - Note it's likely in solution-space
- •Ask "Why?" - Uncover the underlying struggle
- •Identify the struggling moment - When/where does the pain occur?
- •Bound the problem - What's in scope, what's explicitly out?
- •Validate - Does the framed problem match real user behavior?
Framing Questions
Moving from Solution to Problem
| Request Type | Framing Question |
|---|---|
| "Build X feature" | "What struggle does X solve? When does that pain occur?" |
| "Add Y capability" | "What can't users do today? What workaround do they use?" |
| "Improve Z" | "What specifically is broken? Who experiences it?" |
The Five Whys (Adapted)
Don't literally ask "why" five times. Instead:
- •"What prompted this request?"
- •"What happens if we don't build this?"
- •"What workaround exists today?"
- •"When exactly does the user feel this pain?"
- •"What would 'solved' look like for the user?"
Bounding Questions
- •"If we could only solve ONE aspect, which matters most?"
- •"What's the minimum viable outcome?"
- •"What should explicitly NOT be solved in this cycle?"
From Request to Framed Problem
Bad (Solution-space):
"Build a newsletter builder"
Better (Problem-space, but vague):
"Users need to communicate with their audience"
Good (Framed Problem):
"Project managers need to send monthly status updates to stakeholders. Currently they copy-paste into email, losing formatting and spending 2+ hours per update. They need to select from past content and send consistent, branded updates in under 15 minutes."
Output: Framed Problem Statement
Generate a Framed Problem Statement with these elements:
## Framed Problem Statement **Who**: [Specific user role/persona] **Struggle**: [The specific moment of friction or pain] **Current Workaround**: [How they cope today, and what it costs them] **Desired Outcome**: [What "solved" looks like, in user terms] **Boundaries**: - In scope: [What this problem includes] - Out of scope: [What this problem explicitly excludes] **Validation**: [Evidence this is a real problem - user quotes, data, observed behavior]
Anti-Patterns
| Anti-Pattern | Why It Fails | Instead |
|---|---|---|
| Accepting requests verbatim | Commits to a solution before understanding the problem | Ask "what struggle does this solve?" |
| Framing too broadly | "Users need better communication" gives no direction | Specify who, when, what pain |
| Skipping validation | Assumes the stated problem is the real problem | Ask "have you observed this?" |
| Solution leakage | "Users need a calendar..." still contains solution | Remove all nouns that are features |
Success Criteria
A well-framed problem:
- • Contains no feature nouns (calendar, dashboard, widget)
- • Specifies a user role, not "users" generically
- • Describes a moment of struggle, not a capability gap
- • Has explicit boundaries (in/out of scope)
- • Can be validated against real user behavior
- • Allows multiple possible solutions
Handoff to Shaping
Once the problem is framed, use the shape-up-pitch skill to shape a bounded solution and create a pitch for the betting table.