MCPInstall

user-story-mapping

Create a user story map that lays out activities, steps, tasks, and release slices. Use when planning a workflow, backlog, or MVP around the user journey.

Installs
2.7K
Last 24h
+10
Trending rank
#8697
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/deanpeters/product-manager-skills --skill user-story-mapping
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads user-story-mapping automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Purpose

Visualize the user journey by creating a hierarchical map that breaks down high-level activities into steps and tasks, organized left-to-right as a narrative flow. Use this to build shared understanding across product, design, and engineering, prioritize features based on user workflows, and identify gaps or opportunities in the user experience.

This is not a backlog—it's a strategic artifact that shows how users accomplish their goals, which then informs what to build.

Input

Works best with: The product or user workflow being mapped. Also useful: The primary user, the end-to-end narrative as you understand it, existing backlog items to place, and release goals.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

Arriving empty-handed? That works too. The skill asks whose journey you're mapping and what they're trying to get done, then builds backbone → tasks → slices.

Example invocation: Story map for our expense-reporting flow, from receipt capture to reimbursement, with an MVP slice for the pilot.

Key Concepts

The Jeff Patton Story Mapping Framework

Invented by Jeff Patton, story mapping organizes work into a 2D structure:

Horizontal axis (left-to-right): User journey over time

  • Backbone: High-level activities the user performs
  • Steps: Specific actions within each activity
  • Tasks: Detailed work required to complete each step

Vertical axis (top-to-bottom): Priority and releases

  • Top rows: Essential tasks (MVP / Release 1)
  • Lower rows: Nice-to-have tasks (Future releases)

Story Map Structure

Segment → Persona → Narrative (User's goal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5]
     ↓              ↓              ↓              ↓              ↓
  [Step 1.1]     [Step 2.1]     [Step 3.1]     [Step 4.1]     [Step 5.1]
  [Step 1.2]     [Step 2.2]     [Step 3.2]     [Step 4.2]     [Step 5.2]
  [Step 1.3]     [Step 2.3]     [Step 3.3]     [Step 4.3]     [Step 5.3]
     ↓              ↓              ↓              ↓              ↓
  [Task 1.1.1]   [Task 2.1.1]   [Task 3.1.1]   [Task 4.1.1]   [Task 5.1.1]
  [Task 1.1.2]   [Task 2.1.2]   [Task 3.1.2]   [Task 4.1.2]   [Task 5.1.2]
  [Task 1.1.3]   [Task 2.1.3]   [Task 3.1.3]   [Task 4.1.3]   [Task 5.1.3]
  ...            ...            ...            ...            ...

Why This Works

  • User-centric: Organizes work around user goals, not engineering modules
  • Shared understanding: Product, design, engineering all see the same journey
  • Prioritization clarity: Top tasks = MVP, lower tasks = future iterations
  • Gap identification: Missing steps or tasks become obvious
  • Release planning: Draw horizontal "release lines" to define scope

Anti-Patterns (What This Is NOT)

  • Not a Gantt chart: This isn't project management—it's user journey visualization
  • Not a feature list: Activities aren't features—they're user behaviors
  • Not static: Story maps evolve as you learn more about users

When to Use This

  • Kicking off a new product or major feature
  • Aligning stakeholders on user workflow
  • Prioritizing backlog based on user needs
  • Identifying MVP vs. future releases
  • Onboarding new team members to the product vision

When NOT to Use This

  • For trivial features (don't map what you already understand)
  • When user workflows are constantly changing (map stabilizes workflows)
  • As a replacement for user stories (the map informs stories, doesn't replace them)

Application

Step 1: Define the Context

Use template.md for the full fill-in structure.

Segment

Who are you building for?

### Segment:
- [Specify the target segment, e.g., "Small business owners using DIY accounting software"]

Quality checks:

  • Specific: Not "users" but "enterprise IT admins" or "freelance designers"

Persona

Provide details about the persona within this segment (reference skills/proto-persona/SKILL.md).

### Persona:
- [Describe the persona: demographics, behaviors, pains, goals]

Example:

  • "Sarah, 35-year-old freelance graphic designer, manages 5-10 client projects at once, struggles with invoicing and payment tracking, wants to spend less time on admin and more time designing"

Step 2: Define the Narrative

What is the user trying to accomplish? Frame this as a Jobs-to-be-Done statement (reference skills/jobs-to-be-done/SKILL.md).

### Narrative:
- [Concise narrative of the persona's objective, e.g., "Complete a client project from kickoff to final payment"]

Quality checks:

  • Outcome-focused: Not "use the product" but "deliver a client project on time and get paid"
  • One sentence: If it takes more than one sentence, the scope may be too broad

Step 3: Identify Activities (Backbone)

List 3-5 high-level activities the persona engages in to fulfill the narrative. These form the backbone of your map.

### Activities:
1. [Activity 1, e.g., "Negotiate project scope and pricing"]
2. [Activity 2, e.g., "Execute design work"]
3. [Activity 3, e.g., "Deliver final assets to client"]
4. [Activity 4, e.g., "Send invoice and receive payment"]
5. [Activity 5, optional]

Quality checks:

  • Sequential: Activities happen in order (left-to-right)
  • User actions: Describe what the user does, not what the product provides
  • 3-5 activities: Too few = oversimplified, too many = overwhelming

Step 4: Break Activities into Steps

For each activity, list 3-5 steps that detail how the activity is carried out.

### Steps:

**For Activity 1: [Activity Name]**
- Step 1: [Detail step 1, e.g., "Review client brief"]
- Step 2: [Detail step 2, e.g., "Draft project proposal"]
- Step 3: [Detail step 3, e.g., "Negotiate timeline and budget"]
- Step 4: [Optional step 4]
- Step 5: [Optional step 5]

**For Activity 2: [Activity Name]**
- Step 1: [Detail step 1]
- Step 2: [Detail step 2]
...

Quality checks:

  • Actionable: Each step is something the user does
  • Observable: You could watch someone perform this step
  • Logical sequence: Steps follow a natural order

Step 5: Break Steps into Tasks

For each step, list 5-7 tasks that must be completed.

### Tasks:

**For Activity 1, Step 1: [Step Name]**
- Task 1: [Detail task 1, e.g., "Read client brief document"]
- Task 2: [Detail task 2, e.g., "Identify key deliverables"]
- Task 3: [Detail task 3, e.g., "Note budget constraints"]
- Task 4: [Detail task 4, e.g., "Clarify timeline expectations"]
- Task 5: [Detail task 5, e.g., "List open questions for client"]
- Task 6: [Optional task 6]
- Task 7: [Optional task 7]

**For Activity 1, Step 2: [Step Name]**
- Task 1: [Detail task 1]
...

Quality checks:

  • Granular: Tasks are small, specific actions
  • User-facing or behind-the-scenes: Include both (e.g., "Send email" and "Receive confirmation")
  • Prioritizable: You'll prioritize tasks vertically (top = essential, bottom = nice-to-have)

Step 6: Prioritize Vertically

Arrange tasks top-to-bottom by priority:

  • Top rows: MVP / Release 1 (must-have)
  • Middle rows: Release 2 (important but not critical)
  • Bottom rows: Future / Nice-to-have

Draw horizontal "release lines" to demarcate scope.


Step 7: Identify Gaps and Opportunities

Review the map and ask:

  • Are there missing steps or tasks?
  • Are there pain points we're not addressing?
  • Are there opportunities to delight users?
  • Do all activities flow logically?

Examples

See examples/sample.md for a full story map example.


Common Pitfalls

Pitfall 1: Activities Are Features, Not User Behaviors

Symptom: "Activity 1: Use the dashboard. Activity 2: Generate reports."

Consequence: You've mapped the product, not the user journey.

Fix: Reframe as user actions: "Activity 1: Monitor project progress. Activity 2: Summarize work for stakeholders."


Pitfall 2: Too Many Activities

Symptom: 10+ activities across the backbone

Consequence: Map becomes overwhelming and loses focus.

Fix: Consolidate. If you have 10 activities, you're likely mixing activities with steps. Aim for 3-5 high-level activities.


Pitfall 3: Tasks Are Too Vague

Symptom: "Task 1: Do the thing"

Consequence: Can't prioritize or estimate vague tasks.

Fix: Be specific: "Task 1: Enter client email address in the 'Bill To' field."


Pitfall 4: Ignoring Vertical Prioritization

Symptom: All tasks at the same level—no MVP vs. future releases defined

Consequence: No clarity on what to build first.

Fix: Explicitly prioritize. Draw release lines. Force hard choices about what's MVP.


Pitfall 5: Mapping in Isolation

Symptom: PM creates the map alone, then presents it to the team

Consequence: No shared ownership or understanding.

Fix: Map collaboratively. Run a story mapping workshop with product, design, and engineering.


References

Related Skills

  • skills/proto-persona/SKILL.md — Defines the persona for the story map
  • skills/jobs-to-be-done/SKILL.md — Informs the narrative and activities
  • skills/user-story/SKILL.md — Tasks from the map become user stories
  • skills/problem-statement/SKILL.md — Problem statement frames the narrative

External Frameworks

  • Jeff Patton, User Story Mapping (2014) — Origin of the story mapping technique
  • Teresa Torres, Continuous Discovery Habits (2021) — Opportunity solution trees (complementary to story maps)

Dean's Work

  • User Story Mapping Prompt (adapted from Jeff Patton's methodology)

Provenance

  • Adapted from prompts/user-story-mapping.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: user-story-mapping.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md, skills/user-story/SKILL.md, skills/problem-statement/SKILL.md

FAQ

What does the user-story-mapping skill do?

Create a user story map that lays out activities, steps, tasks, and release slices. Use when planning a workflow, backlog, or MVP around the user journey.

How do I install user-story-mapping?

Run npx skills add https://github.com/deanpeters/product-manager-skills --skill user-story-mapping in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/user-story-mapping/ (personal) or .claude/skills/user-story-mapping/ (project).

Which AI agents can use user-story-mapping?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is user-story-mapping safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains user-story-mapping?

It is published by deanpeters in deanpeters/product-manager-skills. It has 2,665 recorded installs.

More from deanpeters/product-manager-skills

View all →

prd-development

deanpeters/product-manager-skills

Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.

Docs & Writing4.7K installs

user-story

deanpeters/product-manager-skills

Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.

4.2K installs

roadmap-planning

deanpeters/product-manager-skills

Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.

company-research

deanpeters/product-manager-skills

Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.

discovery-process

deanpeters/product-manager-skills

Run a full discovery cycle from problem hypothesis to validated solution. Use when a team needs a structured path through framing, interviews, synthesis, and experiments.

3.2K installs

jobs-to-be-done

deanpeters/product-manager-skills

Uncover customer jobs, pains, and gains in a structured JTBD format. Use when clarifying unmet needs, repositioning a product, or improving discovery and messaging.

3.1K installs

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.