Job Stories: Focus on Motivation, Not Persona

A Job Story shifts focus from *who* is doing something to *why*. It frames work around a situation, a motivation, and an outcome. Use it when a user's context is more important than their persona. The footgun is simply rephrasing a user story.
THE MENTAL MODEL: A Job Story reframes product requirements by focusing on the situation and motivation behind a user's need, rather than their identity. Instead of describing a persona, it describes a 'job' the user is trying to get done. The core idea is that users 'hire' a product to make progress in a specific circumstance. Job Stories aim to capture that circumstance and the desired progress.
HOW IT WORKS: Job Stories follow a simple template: 'When [a specific situation occurs], I want to [perform an action or achieve a goal], so I can [reach an expected outcome].' This structure contrasts with the traditional User Story template of 'As a [type of user], I want [some goal], so that [some reason].' The 'When' clause is the key differentiator, as it provides the context and causality that are often missing from a persona-driven story. It forces the team to think about the trigger for the action, not just the action itself.
WHEN TO USE IT: Job Stories are most effective when the user's role or persona is less important than their context. This is common in consumer products with a diverse user base where personas can be misleadingly generic. They are excellent for uncovering the root cause of a need. For example, a user's motivation to find a recipe might change dramatically depending on whether it's a Tuesday night or they're planning a dinner party.
WHEN NOT TO USE IT: Traditional User Stories can be more effective when specific user roles have distinct permissions and workflows. For a feature like 'approve a purchase order,' the role of 'manager' is critical information that a User Story captures perfectly ('As a manager, I want to approve POs...'). Trying to abstract this into a Job Story might obscure essential, role-based constraints and make the requirement less clear.
ONE CANONICAL EXAMPLE: Consider a music app feature. A User Story might be: 'As a user, I want to create a playlist so I can listen to my favorite songs.' A Job Story provides much richer detail: 'When I'm getting ready for a long run, I want to queue up a list of high-energy songs, so I can stay motivated without having to interact with my phone.' The Job Story reveals the context (running), the motivation (staying motivated), and a constraint (no interaction), leading to a better solution.
Read the original → mountaingoatsoftware.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.