job-story-mapper

Job Story Mapper Skill

Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.

Jobs-to-be-Done Fundamentals

A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.

Three dimensions of every job:

• Functional job: The practical task ("get from A to B")
• Emotional job: How they want to feel ("feel confident I made the right choice")
• Social job: How they want to be perceived ("look like a competent professional to my team")

Great products address all three. Most roadmaps only address the functional one.

---

Job Story Format

Template:

> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].

Not a user story:

User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."

Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."

The situation is the most important part. "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."

---

Mapping Process

Step 1: Identify the main job

One sentence: What is the core job your product is hired for?

> "Help [user type] [accomplish outcome] when [context]."

Step 2: Break into job steps

What are all the sub-tasks within the main job?

(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)

Step 3: Identify pain points per step

Where does the job fall down today? Where do customers use workarounds?

Step 4: Write job stories for each pain point

One job story per distinct situation-motivation pair.

Step 5: Map to product opportunities

Which job stories are underserved? Which have existing solutions? Where is your differentiation?

---

Output Format

Job Story Map — [Product/Feature Area] — [Date]

Core Job Statement:

> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].

---

Job Map:

| Step | Sub-Job | Current Solution | Pain Points | Underserved? |

|---|---|---|---|---|

| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |

| Locate | | | | |

| Prepare | | | | |

| Confirm | | | | |

| Execute | | | | |

| Monitor | | | | |

| Modify | | | | |

| Conclude | | | | |

---

Job Stories (prioritised by underservice):

Job Story 1 — [Situation label]

> When [specific situation], I want to [motivation], so I can [outcome].

Functional dimension: [What they need to get done]

Emotional dimension: [How they want to feel]

Social dimension: [How they want to be perceived]

Current workaround: [What they do today]

Pain intensity: [High / Medium / Low]

Frequency: [How often this situation occurs]

Product opportunity: [What we could build to address this]

---

Repeat for each major job story.

Opportunity Scoring:

Rate each job story on:

• Importance to customer (1–10)
• Satisfaction with current solution (1–10)
• Opportunity score = Importance + max(Importance – Satisfaction, 0)
• Prioritise: Opportunity score > 10

---

Scoring Rubric (0–40)

Score any output of this skill before handing it over; 32+ is ship-quality.

| Dimension | 0 | 5 | 10 |

|---|---|---|---|

| Situation specificity | "When" clauses are roles or generic desires ("as a user who wants to manage work") | Situations name a task but not a moment — no trigger, time, or emotional context | Every situation is a concrete, recognisable moment ("a tenant texts me at 11pm") that makes the motivation self-evident |

| Dimensional completeness | Only the functional job mapped; emotional and social fields empty or absent | All three fields filled, but emotional/social entries just restate the functional job in feeling-words | Functional, emotional, and social dimensions each carry distinct content, and at least one non-functional dimension shapes the opportunity analysis |

| Workaround grounding | No current workarounds identified; jobs float free of what customers do today | Workarounds named but treated as trivia — nothing inferred from them | Every high-opportunity story names its workaround and reads it as evidence of what the job is worth (time spent, money paid, delay tolerated) |

| Scoring & prioritisation discipline | No opportunity scores, or scores invented without the Importance/Satisfaction inputs | Scores computed correctly but treated as the build order — no feasibility or strategic-fit check | Arithmetic is shown and consistent, borderline scores are not rounded up, and high scores the roadmap can't serve are flagged as strategy questions rather than queued |

Quality Checks

• [ ] Job stories use the "When / I want to / So I can" format (not user story format)
• [ ] Situation is specific (not "as a user" — a real moment or trigger)
• [ ] All three dimensions covered: functional, emotional, social
• [ ] Opportunity score calculated for each job story
• [ ] Current workaround identified for each high-opportunity story
• [ ] Product opportunity is distinct from "build the feature" (it's an outcome)

Required Inputs

Ask the user for these if not provided:

• Product or feature area to map (e.g. onboarding, checkout, dashboard)
• User type or persona (who are we mapping jobs for?)
• Source material (user interview notes, support tickets, discovery findings, or describe from memory)
• Scope (full product job map vs. a single feature area)

Anti-Patterns

• [ ] Do not write job stories that describe a feature rather than a situation-motivation pair
• [ ] Do not skip the social and emotional dimensions — mapping only functional jobs misses the most defensible differentiation opportunities
• [ ] Do not define situations too broadly ("as a user who wants to manage their work") — the situation must be a specific moment or trigger
• [ ] Do not conflate opportunity scoring with priority — a high opportunity score still requires feasibility and strategic fit assessment
• [ ] Do not produce a job map without identifying current workarounds — the workaround reveals what the job is worth to the customer

Guidelines

• Never write a job story for a feature — write it for the situation that makes the feature valuable
• If you can't identify the situation, you don't understand the job yet — go back to user research
• Social and emotional jobs are harder to surface but often the most defensible differentiators
• Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"