samarv 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.