Job Stories

A job story is a requirement format from the JOBS-TO-BE-DONE world that describes a need as 'When [situation], I want to [motivation], so I can [expected outcome].' It's a deliberate alternative to the traditional agile user story ('As a [persona], I want [feature], so that [benefit]') — and the difference is the point: the user story leads with WHO (a persona, carrying assumptions about demographics and identity), while the job story leads with WHEN (the situation and context that actually triggers the need), stripping out the persona guesswork and anchoring the requirement to the moment and motivation.

The three parts and what each forces you to think about: the situation ('When I'm checking out on my phone with my hands full...') — context, trigger, and circumstance, which is where real needs live and which personas omit; the motivation ('...I want to pay without typing my card details...') — the actual goal in that moment, stated as intent not as a feature; and the expected outcome ('...so I can finish before my coffee gets cold / so I can trust the purchase went through') — the progress the person is trying to make, including the emotional and social dimensions JTBD emphasizes. Why teams adopt it (the case its advocates, notably Alan Klement and the early Intercom team, make): personas in user stories smuggle in unverified assumptions ('as a busy mom' imports a stereotype that may not drive the behavior at all), while situations are observable and shared across many different people (the same checkout-on-mobile situation is lived by people no persona would group together) — so job stories produce requirements organized around causal context rather than demographic correlation, which tends to surface better solutions and avoid building for a persona-fiction. How it's used: in product and UX requirements (replacing or supplementing user stories), in messaging and positioning (a job story is a compact statement of a use case the copy can speak to), and as a bridge from JTBD research (switch interviews and job mapping) into actionable build-and-market specs. The honest limits this entry should carry: job stories are a framing tool, not a research method — a well-written job story is only as true as the understanding of the job behind it (you can write a confident, fictional job story as easily as a fictional persona), so they're an output of real customer understanding, not a substitute for it; and the format debate (user stories versus job stories) is less important than whether the team actually understands the situation and motivation it's building for, by whichever format. The pragmatic stance: job stories are a sharp tool for keeping requirements anchored to context and intent, valuable wherever persona-laden stories have drifted into assumption — used well, with real job understanding behind them, not as a ritual that replaces one template with another.

Job stories matter most in product and UX requirements work where persona-based user stories have accumulated unexamined assumptions — and in the handoff from JTBD research to actionable specs, where the situation-motivation-outcome structure keeps the build anchored to the real moment of need. They matter in messaging too, as compact use-case statements copy can speak to. They matter less as a mandatory format swap (replacing 'As a user' templates with 'When' templates changes nothing if the job understanding behind them is still fictional). The discipline is using job stories to capture genuine situation-and-motivation understanding from real customer research, distinguishing the format (easy) from the insight it's meant to carry (the actual work), and treating them as a clarity tool rather than a ritual.

Job stories emerged around 2013 from the Jobs-to-Be-Done community - Alan Klement and the early Intercom team articulated them as a fix for the assumptions baked into persona-led agile user stories - reframing requirements around the triggering situation and motivation rather than a demographic actor; the format spread through product and UX practice as a JTBD-aligned alternative.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where job stories is a core concern: