Job Stories
Job stories are an alternative to user stories, formalized by Paul Adams and Alan Klement at Intercom around 2013. The format: 'When [situation], I want to [motivation], so I can [expected outcome].' Compare to the classic user story ('As a [persona], I want [feature], so that [benefit]'), and the difference is sharp: job stories drop the persona (which encourages stereotyping) and start with the situation (which forces the team to identify the trigger that pulls users to act). The format pairs naturally with Jobs-To-Be-Done thinking: people don't buy products, they hire them to make progress in a specific situation.
The Trap
The trap is that job stories LOOK like user stories with extra words. Teams convert their user stories to job-story format mechanically — 'As a marketing manager I want to schedule social posts' becomes 'When I'm a marketing manager scheduling social posts, I want to schedule a post, so I can have a scheduled post.' Useless. The whole point of job stories is the situation — and most teams skip past it because identifying real situations requires customer interviews, not personas. A job story without a real, observed situation is just bad copy. Second trap: collecting 200 job stories with no prioritization. Job stories tell you the WHAT, not the WHEN — pair them with RICE/Kano or you'll have a beautiful catalog and no roadmap.
What to Do
Run a customer interview series before writing job stories — at least 8-12 interviews per major product area. Listen specifically for situations: 'Last Tuesday, when X happened, I tried to...' That's a real situation. Convert each into a job story: 'When [exact situation from the interview], I want to [verb-driven motivation], so I can [measurable outcome].' Use the situation field as the prioritization filter — features that don't address an observed situation get killed. Re-interview every 6 months; situations evolve as the market evolves.
In Practice
Intercom's product team adopted job stories around 2013, with Alan Klement and Paul Adams publishing the format publicly. Klement argued that user stories had drifted from their original purpose — capturing user need — and become engineering-task descriptions. The Intercom team used job stories as the artifact that bridged customer interviews and sprint planning: every job story had to cite a real customer interview, with the interview transcript linked. This discipline meant Intercom's roadmap was traceable to specific customer situations, not to internal advocacy. Klement later expanded the framework into the Forces of Progress JTBD methodology. (Source: Alan Klement, 'Replacing The User Story With The Job Story,' 2013)
Pro Tips
- 01
Force every job story to start with 'When' — not 'As a.' The mechanical change exposes which stories don't have a real situation. If you can't write a 'when' clause without sounding generic, the job story is fake and the feature is speculation.
- 02
Pair job stories with retention data. The situations that recur most often in customer interviews should map to the actions most correlated with long-term retention. If they don't, either your retention model is wrong or the situations you're hearing aren't the ones that matter.
- 03
Write job stories at the situation level, not the feature level. 'When I want to undo something' is a job — not 'When I want to click the undo button.' Job stories that name buttons are user stories in disguise.
Myth vs Reality
Myth
“Job stories replace user stories”
Reality
Job stories live above user stories. The job story expresses the user's job-to-be-done; user stories express the team's implementation choices to enable that job. A job story might generate 5-10 user stories during sprint planning. Skipping the job-story layer makes engineering work feel arbitrary.
Myth
“Job stories are just user stories without personas”
Reality
The persona drop is a side effect; the headline change is starting with the situation. Personas hide demographic stereotypes; situations expose behavioral triggers. A job story that just removes the persona without nailing the situation gets the worst of both worlds.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Which of these is the best-written job story for a calendar app feature?
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
Intercom
2013-present
Intercom's product organization replaced user stories with job stories company-wide around 2013. The change wasn't cosmetic: every feature proposal had to start with a situation drawn from a customer interview, not from a persona. PMs were required to cite the interview transcript and the recurring frequency of the situation. Features without traceable situations were rejected at planning. Within 18 months, Intercom's product team reported that the kill rate at planning rose from ~10% to ~35% — a third of proposed features didn't survive the situation-evidence requirement. Shipped features showed measurably higher adoption.
Pre-job-story plan-stage kill rate
~10%
Post-job-story plan-stage kill rate
~35%
Required artifact per story
Cited customer interview
Adoption of shipped features
Measurably higher
Job stories are a discipline, not a format. Their value comes from requiring evidence — a real situation from a real customer — before any feature gets resourced.
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Job Stories into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Job Stories into a live operating decision.
Use Job Stories as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.