Pm use scenarios

Skill julianoczkowski/product-manager/skills/pm-use-scenarios

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.From its SKILL.md

Install

npx -y skills add julianoczkowski/product-manager --skill pm-use-scenarios

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

3.8 KB, 844 tokens by cl100k_base, as published. Nobody here has run it

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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 844 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

Use third-person for skill descriptionsin 54 of 1951, across 35 files
Start descriptions with Use whenin 43 of 1951, across 29 files
Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
Use active voicein 40 of 1951, across 36 files
Map file responsibilities before defining tasksin 36 of 1951, across 29 files
Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
Ask one question at a timein 35 of 1951
Offer execution options after saving the planin 33 of 1951, across 24 files
Include complete code in every stepin 33 of 1951, across 27 files
Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
Announce the skill usage at the startin 30 of 1951
Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

Articulate problems from the persona's point of view
Focus on the problem rather than the solution
Write for the proficient majority of users
Use the provided problem card template
Include persona, frequency, and impact in the scenario
Write a first-person narrative for the day in the life

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.