Job Stories vs User Stories: Which Format Should Your Team Use?
A practical comparison of job stories and user stories — the two dominant formats for capturing what software needs to do. Includes when each format wins, how to convert one to the other, and how to source job stories directly from customer interviews.
Job Stories vs User Stories: Which Format Should Your Team Use?
User stories ("As a user, I want X, so that Y") describe a feature from the perspective of a persona. Job stories ("When [situation], I want to [motivation], so I can [outcome]") describe the job a user is trying to get done in a specific situation. User stories optimize for assigning work to engineers; job stories optimize for understanding why customers hire your product. Most teams should use both: user stories in the backlog, job stories upstream in research and discovery — sourced directly from customer interviews using a platform like Koji.
If your team has a backlog, you almost certainly write user stories. If your team has ever struggled to articulate why a feature exists, the answer is usually that the team is missing job stories. The two formats are not competing. They serve different points in the product lifecycle, and the teams shipping the most successful products in 2026 use both deliberately.
This guide explains both formats, when to use each, the trade-offs, and how to mine job stories from customer conversations at scale.
What Is a User Story?
User stories were popularized by Mike Cohn and the Extreme Programming community in the early 2000s. The canonical template:
As a [persona], I want [capability], so that [benefit].
Examples:
- As a project manager, I want to assign tasks to team members, so that everyone knows what they are responsible for.
- As a shopper, I want to save items to a wishlist, so that I can purchase them later.
User stories are units of work. They describe one feature in one sentence, get estimated by an engineer, and end up on a sprint board. They are intentionally lightweight — the goal is "just enough" detail to start a conversation.
What user stories do well
- Backlog management. Each story is roughly one sprint of work, easy to estimate.
- Cross-functional alignment. Designers, engineers, and PMs all parse the same sentence the same way.
- Acceptance criteria. Each story can be paired with concrete test cases.
Where user stories break down
User stories silently assume you already know the answer. The format encodes the persona ("a shopper"), the solution ("save items to a wishlist"), and the outcome ("purchase later") in a single sentence. If the persona is wrong, the solution is wrong, or both — you do not find out from the story.
What Is a Job Story?
Job stories were introduced by Paul Adams and Alan Klement at Intercom in 2013, drawing on Clayton Christensen's Jobs to Be Done framework. The template:
When [situation], I want to [motivation], so I can [outcome].
Examples:
- When I am closing out the workday and a teammate is blocked on me, I want to drop a quick async update without scheduling a meeting, so I can leave on time and unblock them by morning.
- When my groceries are on the conveyor belt and the line is forming behind me, I want to pay without unlocking my phone, so I can keep moving and avoid holding up other shoppers.
Notice what is missing: the persona. Job stories assume the situation matters more than who you are. Two engineers in different roles may share the same job story if they are in the same situation. Conversely, the same engineer may have entirely different job stories at different moments of their day.
What job stories do well
- Capturing context. The "when" anchors the story in a real situation, not an abstract role.
- Surface motivation, not solution. Job stories describe what the user wants to get done, not what feature they want.
- Test for switching. A great job story explains why someone would switch from their current solution.
- Translate cleanly into research questions. If you cannot describe the situation precisely, you are not ready to design.
Where job stories break down
Job stories are not designed for the backlog. They are too contextual to estimate directly. You translate them into user stories or design tasks once the team has converged on the right solution.
Side-by-Side Comparison
| Dimension | User Story | Job Story |
|---|---|---|
| Format | "As a [persona], I want [feature], so that [benefit]" | "When [situation], I want to [motivation], so I can [outcome]" |
| Center of gravity | The persona | The situation |
| Includes the solution? | Often yes | Almost never |
| Best for | Backlog management | Discovery, research, positioning |
| Origin | Mike Cohn, XP, ~2001 | Paul Adams, Intercom, 2013 |
| Encodes assumptions? | Yes, silently | Surfaces them |
| Typical owner | Engineering / product | Research / strategy |
When to Use Each Format
Use job stories when…
- You are running customer discovery and do not yet know the right solution
- You are positioning a product against alternatives (job stories make competitors visible)
- You are debating "should we build X" — job stories force you to articulate the situation
- You are writing landing-page copy or sales messaging — job stories are the source of high-converting copy
- You are scoping a research study — see research questions for how a job story translates into one
Use user stories when…
- You have decided what to build and need to break the work into sprints
- You are writing acceptance criteria
- You are planning sprints with engineering
- You need a shared format with non-product stakeholders who already speak user-story
The right answer for almost every product team is "both, in sequence." Discover with job stories. Build with user stories.
How to Convert Between Formats
Job story → user story
A job story describes a job. A single job can be solved many ways. Translation requires a design decision:
- Job story: When my groceries are on the conveyor belt and the line is forming behind me, I want to pay without unlocking my phone, so I can keep moving and avoid holding up other shoppers.
- User story 1: As a shopper, I want to tap-to-pay with a wearable, so I can pay quickly.
- User story 2: As a shopper, I want a face-unlock payment shortcut, so I can pay quickly.
- User story 3: As a shopper, I want to authorize payment in advance, so I can skip auth at checkout.
The job story is one. The user stories are many. The choice between them is a product decision — and that is the point. Job stories preserve the design space; user stories close it.
User story → job story
Often harder, because the user story has already collapsed the situation. To recover the job story, ask:
- What situation triggers this need?
- What is the user actually trying to accomplish?
- What would they do if this feature did not exist?
If you cannot answer those questions, you are working from an assumed user story rather than a researched one.
Where Customer Interviews Fit
Both formats are only as good as the source material. A user story written from a stakeholder request and a user story sourced from a customer conversation look identical on the page — but only one of them reflects reality.
The single most reliable way to write good job stories is to listen to customers describe specific situations. The classic Bob Moesta interview format from JTBD asks:
- "Tell me about the last time you [hired the product]. Walk me through the day."
- "What was happening when you first realised you needed something different?"
- "What did you try first that did not work?"
- "What pushed you to actually make the switch?"
Each answer surfaces situational triggers, motivations, and outcomes — the raw material of a job story.
This is where Koji is purpose-built to help. Running 30-50 customer interviews using these questions traditionally takes a senior researcher 4-6 weeks. Koji's AI moderator can run the same interviews at the same depth, in parallel, while you sleep:
- Voice or text — let the customer choose, capture the same conversational nuance either way
- AI follow-up probing that asks "what specifically pushed you?" automatically when the answer is vague
- Six structured question types — open-ended for the narrative, scale for severity, ranking for prioritising the situations
- Automatic thematic analysis that surfaces the most common situations across all conversations — your top job stories, written for you
- Insights chat so you can ask "what was the most common trigger for switching?" in plain English
A common Koji workflow: import a customer list, send a personalised AI interview to every customer using personalised links, wait 48-72 hours, read the auto-generated research report, and write your job stories straight from the themes section.
Job Stories in Practice
A few patterns successful teams use:
Lead with the situation, not the persona
If your job story starts with "as a marketing manager," you have a user story. If it starts with "when our newsletter is about to go out and our designer is on PTO," you have a job story.
Include the alternative, not just the desired outcome
The strongest job stories implicitly answer "what would you do otherwise?" That makes the competitive set visible — including non-software competitors (a spreadsheet, a colleague, doing nothing).
Keep them short
If a job story is more than three sentences, you are mixing situations. Split it.
Source them, do not invent them
A job story from a real customer conversation is research. A job story written from a brainstorming session is a hypothesis. Treat them differently. Run the interviews.
Aggregate them
A single job story is anecdotal. Twenty-plus job stories about the same situation are a roadmap signal. Use thematic analysis or Koji's automatic clustering to find which job stories represent the most common situations.
Common Mistakes
- Treating user stories as research output. They are work units. The research lives upstream in interviews and job stories.
- Inventing job stories. Job stories are observed, not designed. Invented ones encode the same biases as user stories.
- Skipping the situation. "I want to pay quickly" is not a job story. "When the line is forming behind me at checkout, I want to pay quickly, so I can keep moving" is.
- Including the solution. The motivation is what the user wants done; the solution is your job to design.
- Not refreshing job stories. Situations evolve. The job stories that drove the 2024 roadmap may not match 2026 reality. Re-interview annually.
The Bottom Line
User stories make the backlog tractable. Job stories make the backlog correct. The teams shipping the products customers actually pull on use both — discovering with job stories, delivering with user stories.
The real bottleneck for most teams is not the format. It is the volume of real customer conversations they have access to. Modern AI research platforms have made it possible to run thirty real conversations in the time it used to take to schedule one. If your job stories are still being written from internal speculation, the upstream fix is more conversations, not better templates.
Related Resources
- Structured Questions in AI Interviews — The six question types Koji uses to capture both narrative job stories and quantitative validation in a single interview
- Jobs to Be Done Framework — The strategic framework that birthed job stories
- Jobs to Be Done Interviews — How to run JTBD-style customer interviews
- Switch Interviews: The JTBD Method for Understanding Why Customers Buy — The Bob Moesta technique for sourcing job stories
- How to Conduct User Interviews — The complete step-by-step interview guide
- Customer Discovery Interviews — Running discovery interviews to source new job stories
- Continuous Discovery: Weekly Customer Interviews — How leading teams keep their job stories fresh
Related Articles
Writing a Research Question
Learn how to frame a clear, focused research question that sets the foundation for a successful study.
Structured Questions in AI Interviews
Mix quantitative data collection — scales, ratings, multiple choice, ranking — with AI-powered conversational follow-up in a single interview.
Switch Interviews: The JTBD Method for Understanding Why Customers Buy (and Leave)
Switch interviews uncover the four forces of progress that cause customers to switch from one product to another. Learn the Bob Moesta playbook and how to run switch interviews with AI at scale.
How to Conduct User Interviews: The Complete Step-by-Step Guide
A complete step-by-step guide to planning, conducting, and analyzing user interviews—covering discussion guide writing, participant recruitment, facilitation techniques, sample size, and modern AI-powered approaches.
The Complete Guide to Thematic Analysis
Learn how to systematically analyze qualitative data using Braun and Clarke's six-phase thematic analysis framework.
Jobs-to-Be-Done Interview Guide
Learn the JTBD interview methodology to uncover why customers switch products and what progress they're trying to make.
Jobs to Be Done Framework: The Complete Guide
The definitive guide to the Jobs to Be Done (JTBD) framework — its history, two schools of thought, how to write JTBD statements, famous examples, how to conduct JTBD research, and how AI interviews enable JTBD at scale.
Customer Discovery Interviews: The Complete Guide
Learn how to conduct customer discovery interviews to validate your product ideas before building. Covers Steve Blank methodology, question frameworks, sample sizes, and common mistakes.
Continuous Discovery: How to Run Weekly Customer Interviews Without Burning Out
Continuous discovery is the practice of conducting customer interviews every week as part of your normal workflow. This guide explains how to build an always-on research practice that actually scales.