JTBD vs User Stories: When to Use Each (With Examples)

JTBD (Jobs to Be Done) discovers the underlying need: why users want progress. User stories describe features to build: “As a [user], I want [feature], so that [benefit].” Use JTBD for product strategy and discovery. Use user stories for sprint planning and development. They work together, not against each other.

Product teams often debate whether to use JTBD or user stories, as if they’re interchangeable. They aren’t. JTBD operates at the strategy level: what problem are we solving and for whom? User stories operate at the execution level: what should we build this sprint?

Using user stories for strategy leads to feature factories. Using JTBD for sprint planning creates confusion. Each framework has a specific job (pun intended), and knowing which one to reach for at each stage of product development makes both more effective.

For a complete introduction to the JTBD framework, see our Jobs to Be Done guide.

JTBD vs User Stories: Quick Comparison

	JTBD	User Stories
Level	Strategy and discovery	Execution and delivery
Question answered	What problem should we solve?	What should we build?
Format	”When [situation], I want to [motivation], so I can [outcome]"	"As a [user], I want [feature], so that [benefit]“
Product-agnostic?	Yes: describes the need, not the solution	No: describes a specific feature
Time horizon	Months to years	Days to weeks
Who writes them	Product managers, researchers	Product + engineering together
Validated by	Customer interviews, switching research	Acceptance criteria, QA
Risk addressed	Building the wrong thing	Building the thing wrong

What JTBD Does That User Stories Can’t

1. Reveals the Actual Need Behind Feature Requests

Users ask for features. They rarely explain the underlying need. A customer who asks for “a Gantt chart view” might actually need: “When stakeholders ask me for a project timeline, I want to show them something visual they can understand in 10 seconds, so I can get alignment without scheduling a 30-minute meeting.”

The JTBD reveals that the customer needs quick visual communication of project status. A Gantt chart is one solution. A progress dashboard, a timeline view, or an auto-generated status email might all solve the same job better.

User stories would capture the request: “As a project manager, I want a Gantt chart view, so that I can show stakeholders the timeline.” This builds exactly what was asked for, which might not be what’s actually needed.

2. Identifies Competitors You Didn’t Know You Had

JTBD looks at alternatives from the customer’s perspective. For the job “communicate project status to stakeholders,” your competitors aren’t just other PM tools. They include:

Email updates written manually
PowerPoint slides
Slack messages with screenshots
Walking over to someone’s desk
Doing nothing and hoping nobody asks

User stories don’t surface these alternatives because they’re focused on features within your product.

3. Stays Relevant Longer

A JTBD like “When I need to coordinate work across five time zones, I want everyone to know who’s doing what without requiring synchronous meetings” will remain valid for years. The underlying need doesn’t change even as solutions evolve.

User stories expire: “As a user, I want to see teammates’ local times in the sidebar.” Once built, the story is done. If the solution doesn’t actually solve the job, you won’t know until you hear about it in churn interviews.

What User Stories Do That JTBD Can’t

1. Provide Buildable Specifications

JTBD tells you the “what” and “why.” It doesn’t tell engineers what to build. “When I need to communicate project status” doesn’t translate into a sprint task.

User stories bridge this gap:

“As a PM, I want to generate a one-page project status report with a click, so that I can send stakeholders a weekly update without manually compiling data.”
“As a PM, I want to set up automated weekly status emails to stakeholders, so that they stay informed without me remembering to send updates.”

These are buildable. Designers can create mockups. Engineers can estimate effort. QA can write acceptance criteria.

2. Enable Estimation and Planning

Scrum and kanban workflows need stories with clear scope. “As a user, I want to filter the dashboard by date range” can be estimated at 3 story points. “When I need to understand our business performance over time” cannot be estimated because it’s not a specific unit of work.

3. Create Accountability and Traceability

User stories connect directly to code commits, pull requests, and test cases. You can trace from a customer need to JTBD to user story to code to production. JTBD alone doesn’t create this traceability because it operates at a higher level of abstraction.

How to Use Them Together: The Workflow

The most effective product teams use JTBD and user stories at different stages of the same process.

Stage 1: Discovery (JTBD)

Run customer interviews to identify the top 3-5 jobs your product needs to serve. Write JTBD statements for each. Prioritize based on frequency, urgency, and how poorly current alternatives serve the job.

Output: “When our sales team closes a deal, the handoff to customer success is chaotic. The CS team doesn’t know what was promised, what the timeline is, or who the key contacts are. Every onboarding starts with a 45-minute call that shouldn’t be necessary.”

JTBD: When a deal closes and I’m the CS lead taking over the account, I want to immediately see everything sales promised and every stakeholder I need to know, so I can start onboarding on day one without a redundant information-gathering call.

Stage 2: Solution Design (Bridge)

Brainstorm solutions to the job. Evaluate each against the JTBD criteria. Pick the approach that best serves the job.

Solutions considered:

Automated handoff document generated from CRM data
Shared workspace between sales and CS
Standardized handoff checklist in the CRM

Selected: Automated handoff document, because it eliminates manual work entirely.

Stage 3: Execution (User Stories)

Break the chosen solution into user stories that engineering can build.

“As a CS manager, I want a deal handoff summary auto-generated when a deal closes, so that I can review account context without scheduling a call with sales.”
“As a CS manager, I want to see the customer’s stated goals, timeline, and key contacts in the handoff summary, so that I can personalize the onboarding plan.”
“As a sales rep, I want to review and annotate the auto-generated handoff before it goes to CS, so that I can add context that isn’t captured in CRM fields.”
“As a CS manager, I want to flag missing information in the handoff and notify the sales rep, so that gaps get filled before the onboarding kickoff.”

Each story is estimable, buildable, and testable. Each traces back to the original JTBD.

Stage 4: Validation (Back to JTBD)

After shipping, measure whether the job is being done better. Not “did users click the button” but “did the handoff call time decrease? Did CS satisfaction improve? Did time-to-first-value for new customers improve?”

This loop prevents the feature factory problem. You don’t just ship and move on. You validate against the original job.

Common Mistakes

Mistake 1: Writing JTBD That Are Actually User Stories

Wrong: “When I open the app, I want to see a dashboard, so I can check my metrics.”

This is a user story dressed up in JTBD format. The real JTBD: “When my manager asks how the product is performing, I want to give a confident answer in 30 seconds, so I look prepared and in control.”

Mistake 2: Writing User Stories Without JTBD Context

Wrong: “As a user, I want to export data to CSV.”

Without JTBD context, this story will be built exactly as written. But why does the user want CSV export? Maybe the job is: “When I need to combine our product data with data from two other tools, I want to get everything into one place, so I can build the custom report my VP requested.”

The real solution might be a direct integration with their reporting tool, not a CSV export.

Mistake 3: Using JTBD in Sprint Planning

JTBD statements are too abstract for sprint planning. “When I need to understand our competitive landscape” is not something you can assign to an engineer for a two-week sprint. Translate the JTBD into user stories first, then plan sprints.

Frequently Asked Questions

Can a single JTBD generate multiple user stories?

Yes, and it usually should. A single job like “confidently communicate project status to stakeholders” might generate 5-10 user stories: auto-generated reports, customizable dashboards, scheduled email digests, and mobile-friendly status views. The JTBD ensures all these stories serve a coherent purpose rather than being disconnected features.

Should user stories always reference a JTBD?

Ideally, yes. Every user story should trace back to a job. This prevents feature creep and keeps the team aligned on outcomes. In practice, some stories (bug fixes, tech debt, compliance requirements) don’t map cleanly to a JTBD, and that’s fine. But any new feature should have a clear job it’s serving.

How do you prioritize user stories using JTBD?

Rank your JTBDs by impact and frequency. The job that affects the most users with the highest friction gets priority. Then within that job, prioritize user stories by how much of the job they address. A story that solves 80% of the job is more valuable than one that adds a nice-to-have edge case.

Do agile teams need to change their process to use JTBD?

No. JTBD fits on top of agile, not instead of it. Use JTBD during product discovery (before the sprint). Use user stories during sprint planning and execution. The only change is adding a discovery phase where you identify and validate jobs before writing stories. Most mature agile teams already do some form of discovery.

What’s the relationship between JTBD, user stories, and personas?

Personas describe who the user is. JTBD describes what they’re trying to accomplish. User stories describe what to build. They work at different levels: personas provide context, JTBD provides direction, user stories provide specification. For more on how JTBD and personas compare, read our JTBD vs user personas guide.

Use Both, at the Right Time

The debate between JTBD and user stories is a false dichotomy. Use JTBD to discover what’s worth building. Use user stories to build it well. The teams that combine both frameworks consistently build products that solve real problems, because they start with the need and end with the code.