Use Scenarios (Pragmatic Framework: Planning → Use Scenarios)
Rule: articulate problems from the persona's point of view. A use scenario
illustrates a market problem as a "story" that puts it in context (including current
results) — it is one component of requirements. See
../pm-copilot/references/framework.md. Personas should exist first (pm-personas).
Anatomy of a Problem Card
Map interrogatives to fields:
| Field |
Interrogative |
| [Problem Name] |
What problem |
| [Persona] |
Who has it |
| has [use scenario] |
Why it occurs |
| with [frequency] |
When it occurs |
Reframing sentence (great for turning a feature request into a problem):
[Persona] struggles with [problem] when [context] because [why it matters].
What vs. How — stay on the WHAT
| WHAT = the problem → PM → DEFINE |
HOW = the solution → Team → DESIGN/BUILD |
| Name, Persona, Use Scenario, Frequency, Market evidence, Impact |
Overview, flow chart, use cases, UI, prototypes, error conditions |
A use scenario ≠ a use case. A use scenario tells the problem story; a use case
enumerates every interaction in the functional spec (the team's job).
Three considerations when articulating a problem
- Avoid ambiguous terms — do not use: flexible, adaptable, user-friendly, TBD,
adequate, rapidly/quickly/fast, fault tolerant, scalable, ASAP,
maximize/minimize/optimize (any "-ize" word), and/or, etc. Replace each with a
concrete, observable statement.
- Edge cases ("what if?") — will your persona actually do it? Don't design for
situations that won't happen.
- Who is significant? — the U-curve: the vocal extremes (novices + experts) are
where we listen; the proficient majority is where we should listen. Write for
the majority.
Interview the user (batch questions)
- Which persona and which market problem is this scenario for?
- Walk me through a real situation where this happens — what triggers it, what do they
do today, and what's the current (bad) result?
- How often does it occur (frequency)?
- What evidence shows this is real (counts across inputs) and how bad is it (impact)?
Artifact template
# Use Scenarios — <Product / Release>
**Company:** <company> · **Feature / Product:** <feature / product name>
**Author:** <author> · **Date created:** <date> · **Version:** 1.0
## Scenario 1 — <Problem Name>
**Problem Card**
- **Problem Name:** <what>
- **Persona:** <who>
- **Use Scenario:** <why — the situation that causes the problem>
- **Frequency:** <when / how often>
**Day in the life**
<A short first-person narrative: the persona's context, the trigger, what they do today,
and the frustrating current result. Concrete and specific — no ambiguous terms.>
**Market evidence:** <# of documented occurrences across inputs>
**Impact:** <1–5 on the impact scale (or 99999 if contractual)>
## Scenario 2 — <Problem Name>
…
Deliver the artifact
Follow ../pm-copilot/references/artifact-output.md: confirm inputs, ask Markdown
or .docx, write the .md, convert to .docx on request via your environment's native document-creation capability. Then offer the next stage: roll these scenarios into prioritized
pm-requirements or a full pm-prd.
1---2name: pm-use-scenarios3description: Write Pragmatic Institute use scenarios — short stories that put a market problem in context from the persona's point of view (a component of requirements). Use when the PM asks for "use scenarios", "a day in the life", "user story context", "problem statements", or needs to reframe a feature request as a real problem so development understands the WHAT (not the HOW). Produces a Use Scenarios document as a Markdown or Word .docx artifact.4---56# Use Scenarios (Pragmatic Framework: Planning → Use Scenarios)78**Rule:** *articulate problems from the persona's point of view.* A use scenario9illustrates a market problem as a "story" that puts it in context (including current10results) — it is one component of requirements. See11`../pm-copilot/references/framework.md`. Personas should exist first (`pm-personas`).1213## Anatomy of a Problem Card14Map interrogatives to fields:1516| Field | Interrogative |17| :--- | :--- |18| **[Problem Name]** | *What* problem |19| **[Persona]** | *Who* has it |20| **has [use scenario]** | *Why* it occurs |21| **with [frequency]** | *When* it occurs |2223Reframing sentence (great for turning a feature request into a problem):24> **[Persona]** struggles with **[problem]** when **[context]** because **[why it matters]**.2526## What vs. How — stay on the WHAT27| WHAT = the problem → **PM → DEFINE** | HOW = the solution → **Team → DESIGN/BUILD** |28| :--- | :--- |29| Name, Persona, Use Scenario, Frequency, Market evidence, Impact | Overview, flow chart, use cases, UI, prototypes, error conditions |3031A use scenario ≠ a use case. A use scenario tells the problem story; a use case32enumerates every interaction in the functional spec (the team's job).3334## Three considerations when articulating a problem351. **Avoid ambiguous terms** — do not use: *flexible, adaptable, user-friendly, TBD,36 adequate, rapidly/quickly/fast, fault tolerant, scalable, ASAP,37 maximize/minimize/optimize (any "-ize" word), and/or, etc.* Replace each with a38 concrete, observable statement.392. **Edge cases ("what if?")** — will your persona *actually* do it? Don't design for40 situations that won't happen.413. **Who is significant?** — the U-curve: the vocal extremes (novices + experts) are42 *where we listen*; the proficient majority is *where we should listen.* Write for43 the majority.4445## Interview the user (batch questions)461. Which persona and which market problem is this scenario for?472. Walk me through a real situation where this happens — what triggers it, what do they48 do today, and what's the current (bad) result?493. How often does it occur (frequency)?504. What evidence shows this is real (counts across inputs) and how bad is it (impact)?5152## Artifact template53```markdown54# Use Scenarios — <Product / Release>5556**Company:** <company> · **Feature / Product:** <feature / product name>57**Author:** <author> · **Date created:** <date> · **Version:** 1.05859## Scenario 1 — <Problem Name>60**Problem Card**61- **Problem Name:** <what>62- **Persona:** <who>63- **Use Scenario:** <why — the situation that causes the problem>64- **Frequency:** <when / how often>6566**Day in the life**67<A short first-person narrative: the persona's context, the trigger, what they do today,68and the frustrating current result. Concrete and specific — no ambiguous terms.>6970**Market evidence:** <# of documented occurrences across inputs>71**Impact:** <1–5 on the impact scale (or 99999 if contractual)>7273## Scenario 2 — <Problem Name>74…75```7677## Deliver the artifact78Follow `../pm-copilot/references/artifact-output.md`: confirm inputs, **ask Markdown79or .docx**, write the `.md`, convert to `.docx` on request via your environment's native document-creation capability. Then offer the next stage: roll these scenarios into prioritized80**`pm-requirements`** or a full **`pm-prd`**.
julianoczkowski