Job Stories: The JTBD Format for Writing a Product Backlog
A job story describes a person's situation, motivation, and desired outcome. How to write one, how it differs from a user story, and when to use it.
What is a job story?
It is a product story that comes from the Jobs to be Done framework. It has three parts:
- Situation: the trigger, the moment, or the context in which the need appears.
- Motivation: what the person wants to achieve.
- Outcome: the progress they are looking for, not the feature they will use.
The format comes from Intercom. Its product team created it around 2013 to understand the motivations behind what people do, without relying on personas or roles. Paul Adams told the story in 2016 and explained that the name came later from Alan Klement (Intercom, “How we accidentally invented Job Stories”).
How is it different from a user story?
The difference is the starting point. A user story begins with who acts. A job story begins with when it happens.
| Element | User story | Job story |
|---|---|---|
| Starting point | “As a [role]…” | “When [situation]…” |
| Focus | A feature | The job the person wants to do |
| Typical origin | A requirements list | Observation of real situations |
| Question it answers | What should the system do? | Why and when does someone need it? |
Mountain Goat Software puts it this way: a user story depends on who performs the function, while a job story focuses on the job that story has to get done. His example compares “When an order is submitted…” with “As a customer…”. The first version applies to anyone who buys and says when the warning appears; the second never says when, so the team could satisfy it with an FAQ entry (Mountain Goat Software).
Why should a designer care?
Because the situation forces you to design for a specific moment. The same feature can answer several situations, and each one calls for a different solution. The JTBDUX Protocol guide insists that the situation is the most important part of the format, and recommends writing one per story so you don’t mix scenarios (JTBDUX Protocol, “The Job Story”).
This helps you in three ways:
- You spot that two different user stories are really the same situation.
- You see what happens before and after the screen you are designing.
- You discuss the problem with product before you discuss the button.
The job story also leaves the solution out on purpose. That gives you room to propose two or three different paths and compare which one handles the situation best, instead of arriving with a screen already decided.
How do you write a good job story?
- Observe a real situation. An interview or an observation session gives you the trigger. If the situation comes from your imagination, the story will be generic.
- Write the situation in detail. “When I’m on my phone and have to pay a bill” says more than “When the user wants to pay”.
- Describe the motivation as a reason. It has to be something the person wants, not a feature. “I want to confirm the payment went through” is a motivation; “I want to see a confirm button” is not.
- Define an outcome with progress. “So I can get on with my day without worrying” describes progress. “So I can pay” repeats the function.
- Split large stories. If one situation covers several scenarios, separate them.
Example
Illustrative example: a banking app team has a backlog item that reads “As a user, I want to see my transactions.” Rewritten as a job story, it becomes: “When I see a charge I don’t recognize on my phone, I want to understand where it comes from, so I can decide whether to dispute it before another one is charged.” With that sentence, the team stops debating a list of transactions. It discusses how to show the charge, which details are enough, and what action should appear next to it.
When NOT to use them
- When the team only needs a technical task. A refactor or a migration has no user situation to describe.
- When who acts matters. If your users differ a lot from each other, understanding who each one is still matters. Job stories fit best in products whose users have similar needs.
- When your team already works with user stories. You don’t have to switch everything. Mountain Goat Software suggests mixing both formats in the same backlog and writing a job story whenever you catch yourself drafting several stories in a row that start with “As a user.”
- When the situation is not validated. A job story written without research is a user story with better wording.
Common mistakes
- Writing the motivation as a feature: “I want a date filter.”
- Using the outcome to repeat the action: “so I can search.”
- Writing generic situations like “when I use the app.”
- Keeping one story that mixes two different situations.
- Using the format as a substitute for user interviews.
How to start tomorrow
Open your backlog and pick three user stories that say “user” and use a generic verb. For each one, ask: when does this happen, what was the person doing just before, and what were they trying to achieve? Rewrite them with the template. If you can’t answer one of those questions, you have a research gap, not a design gap. To see how this connects with other artifacts, look at use cases and the existing user flows in the wiki.