Guide the upstream work of negotiating from feature requests to specific user struggles. Use when stakeholders request features ("build a calendar"), when scope seems unbounded, when you need to define the real problem before solutioning, or when asked to "frame this problem", "what's the real ask", "negotiate scope", or "move upstream". This skill transforms vague requests into bounded problem statements.
Transform feature requests into specific, bounded problem statements by moving upstream from solutions to struggles.
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.
| 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?" |
Don't literally ask "why" five times. Instead:
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."
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-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 |
A well-framed problem:
Once the problem is framed, use the shape-up-pitch skill to shape a bounded solution and create a pitch for the betting table.
Category:business