Job Stories

---

Origins

The Job Story format was introduced by Paul Adams and Alan Klement in 2013 while working at Intercom.¹ Klement's frustration was specific: the canonical user story format — "As a <persona>, I want <feature>, so that <benefit>" — kept producing thin, persona-bound stories that missed the actual situation in which users needed the product. He proposed an alternative that put context, not identity, at the center of the story.

Job Stories are deeply connected to the Jobs-To-Be-Done theory developed by Clayton Christensen and Bob Moesta — the idea that users "hire" products to do jobs in specific contexts, and that understanding the job matters more than understanding the user demographic.²

The Format

A Job Story has three parts:

When [situation], I want [motivation], so I can [expected outcome].

For example:

When I have just received a payment notification at the end of the month, I want to see my running total against my savings goal, so I can decide whether to celebrate or cut back.

Compare with the equivalent user story:

As a budget-conscious user, I want to see my running total against my savings goal, so that I can track my progress.

The Job Story version captures the moment — the trigger, the emotional state, the decision being made. The user story version, by contrast, names a persona ("budget-conscious") that could describe almost anyone in almost any moment. The Job Story is more specific because it locates the user in a situation.

Why It Matters: Context Over Identity

The case for Job Stories rests on a single observation: the same person uses a product differently in different situations. A "budget-conscious user" behaves one way after receiving an unexpected bill and another way at the end of a successful month. Persona-based stories abstract away that difference. Context-based stories preserve it.

This matters because design decisions are almost always context-dependent. The notification that helps in one situation distracts in another. The default that suits a casual user fails the power user mid-task. Job Stories make those situational distinctions visible in the story itself.

The Three Slots

When (the situation)

The trigger or context in which the need arises. Specific, observable, and ideally tied to something the product can detect or respond to. Vague Whens — "When I'm using the app" — produce vague stories. Sharp Whens — "When I'm about to submit a multi-thousand-dollar transfer" — produce sharp ones.

I want (the motivation)

What the user wants to do or experience in that situation. Phrased in terms of the user's intent, not the system's behavior. "I want to be sure I haven't typed the wrong amount" is a motivation. "I want a confirmation dialog" is a solution disguised as one.

So I can (the outcome)

The deeper goal — what success looks like for the user beyond the immediate motivation. This often reveals the emotional or strategic weight of the moment, and helps the team understand which trade-offs are acceptable.

Job Stories and User Stories Together

Job Stories are not a replacement for user stories so much as an alternative lens. Many teams use both — user stories for routine, persona-aligned work, and Job Stories when the situation is genuinely the driving factor. The two formats can also be mixed within a backlog without confusion.

The deeper question is which format better captures the thing the team needs to remember. If the answer is "this is what role-X needs in general", the user story format suits. If the answer is "this only matters in this particular moment", the Job Story is sharper.

Common Failure Modes

• Generic Whens. "When I'm using the app" is not a situation. Push for the specific moment.
• Solution-shaped motivations. "I want a button that..." reveals an implementation hiding inside the motivation slot. Pull it back to intent.
• Persona smuggling. "When I'm a power user..." reintroduces the very persona-thinking Job Stories were meant to escape. The When should describe a situation, not an identity.
• Job Story as the only format. Some work — internal tooling, technical capabilities, infrastructure — is hard to express as a Job Story and fits user stories or other formats better.

Coaching Tips

Try Job Stories on one story first.

Don't rewrite the whole backlog. Pick one user story, re-cast it as a Job Story, and compare what each surfaces.

Sharpen the When.

If the When could be anyone at any time, it isn't doing work. Push until the situation is specific enough to imagine.

Keep motivations solution-free.

"I want a checkbox" is a solution. "I want to feel safe before confirming" is a motivation. The latter leaves the design space open.

Use Job Stories alongside JTBD interviews.

The format pairs naturally with the Jobs-To-Be-Done interview technique. The interview produces the raw material; the Job Story captures it.

Mix freely with user stories.

There is no purity prize. Use whichever format more clearly captures the thing the team needs to remember.

Watch for outcome inflation.

"So I can be a better person" is too abstract. The outcome should be specific enough to influence design choices.

Summary

Job Stories are a small change in syntax that produces a measurable shift in thinking. By making the situation the first thing the team writes, they force a level of context-awareness that persona-based stories tend to skip. The trick is to use the format where it earns its keep — when the moment is the thing that matters — and not to wedge every backlog item into it as a matter of fashion.

Back to Story Crafting