home / skills / abhsin / designskills / problem-framing

problem-framing skill

This skill helps you transform fuzzy product ideas into validated problem statements, target users, and jobs-to-be-done for actionable design.

npx playbooks add skill abhsin/designskills --skill problem-framing

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

3.0 KB

---
name: problem-framing
description: Extract and structure fuzzy product ideas into validated problem statements, target users, and jobs-to-be-done. Use when a user has a raw idea, concept, or solution in mind but hasn't clearly articulated the problem, target user, or assumptions. This skill helps users communicate context to coding agents more effectively, reducing iteration cycles and "that's not what I meant" moments.
---

# Problem Framing

Transform raw product ideas into structured context that coding agents can execute on.

## Why This Exists

Extracts fuzzy product ideas from the user's head and structures them into clear problem statements, target users, and assumptions that coding agents can execute against.

## Workflow

### Step 1: Gather Raw Input

Ask the user to share their idea in any form—plain text, voice dump, bullet points, or existing notes. Accept whatever they have.

### Step 2: Run the Question Flow

Work through these questions conversationally. Skip or adapt based on what the user has already provided.

| Question | Purpose |
|----------|---------|
| What are you trying to build? | Get the raw idea out |
| Who specifically is this for? | Force specificity—"everyone" = no one |
| What problem does this solve for them? | Separate solution from problem |
| What are they doing today without this? | Reveals current alternatives, competition |
| When does this problem hit hardest? | Identifies trigger moments, urgency |
| What assumptions are you making? | Surfaces risks early |
| How will you know this worked? | Defines success criteria |

**Questioning style:**
- Ask one question at a time
- Probe vague answers ("Can you be more specific about who?")
- Reflect back what you hear to confirm understanding
- Don't overwhelm—adapt based on what's already clear

### Step 3: Generate Output

Once you have enough context, generate the structured output below. **Automatically save it to `design/01-problem-framing.md` using the Write tool** while continuing the conversation naturally.

## Output Format

```markdown
# Problem Framing: [Project Name]

## Problem Statement
[One clear sentence: WHO has WHAT problem WHEN]

## Target User
[Specific description—not "everyone" or "users"]

## Jobs to Be Done
- **Functional:** [What they're trying to accomplish]
- **Emotional:** [How they want to feel]
- **Social:** [How they want to be perceived]

## Current Alternatives
[What they do today without your solution]

## Trigger Moments
[When does this problem hit hardest?]

## Key Assumptions
- [Assumption 1]
- [Assumption 2]
- [Assumption 3]

## Success Criteria
- [How you'll measure if this works]

## Open Questions
- [Anything still unclear or needing validation]
```

## Handoff

After presenting the output, ask:
> "This captures your problem framing. Ready to move to `/user-modeling`, `/solution-scoping`, or `/prd-generation`, or want to refine anything first?"

**Note:** File is automatically saved to `design/01-problem-framing.md` for context preservation.

Overview

This skill extracts fuzzy product ideas and turns them into crisp, actionable problem statements, target user definitions, and jobs-to-be-done. It’s designed to be used when an idea exists but the problem, audience, or assumptions are unclear. The output is structured so coding and product teams can act with fewer clarifying questions and less rework.

How this skill works

You provide any form of raw input—notes, a voice dump, or a short pitch—and the skill runs a conversational question flow to clarify intent. It asks one focused question at a time, probes vague answers, and reflects back to confirm understanding. From the clarified context it produces a standardized problem-framing document that highlights the problem statement, target user, jobs-to-be-done, current alternatives, trigger moments, key assumptions, success criteria, and open questions. The result is a concise artifact you can share with coding agents or stakeholders to reduce misalignment.

When to use it

You have a raw idea but can’t clearly state the problem or who it’s for.
You want to hand context to a coding agent to build features with fewer iterations.
Early discovery sessions to quickly test whether an idea is worth scoping.
When prepping a brief for a designer, engineer, or product manager.
Before running user interviews or validation experiments.

Best practices

Share whatever raw material you have—drafts, voice notes, or bullet points—to speed clarification.
Answer questions specifically; avoid “everyone” or vague groups—name roles, environments, and constraints.
Be honest about assumptions and current workarounds; exposing risks early saves time.
Focus on measurable success criteria so engineering and analytics can validate outcomes.
Iterate the framing with short follow-up questions rather than trying to perfect it in one go.

Example use cases

Turn a founder’s 2-minute pitch into a single-sentence problem statement and clear target user.
Refine a feature idea into functional, emotional, and social jobs-to-be-done for product requirements.
Translate customer complaints into trigger moments and measurable success criteria for an experiment.
Document key assumptions and open questions before handing work to a development team.
Prepare a concise brief that reduces ‘that’s not what I meant’ iterations when working with coding agents.

FAQ

How detailed does my initial input need to be?

Any level of detail works—one sentence, a voice dump, or notes. The skill will ask follow-up questions to fill gaps.

Will this replace user research?

No. It structures hypotheses and assumptions for faster validation, but user research is still required to confirm them.

Can the output be used directly by engineers?

Yes. The output is formatted to provide clear problem context, success metrics, and assumptions so engineers and coding agents can start implementation with fewer clarifying cycles.