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.