Jobs-to-be-Done vs User Stories: Which to Use When

One-line version: Jobs-to-be-Done tells you what outcome is worth building and why; user stories tell you what increment to ship next. They sit at different altitudes — strategy versus delivery — so the real question isn't "which one," it's "am I at the right altitude for the decision in front of me?"

The two get pitted against each other because both can be written as a single sentence about a user wanting something. But a Jobs-to-be-Done statement and a user story answer completely different questions, and treating them as interchangeable is how teams end up with a tidy, well-groomed backlog that ships the wrong product.

At a glance

The clearest tell: a job is stable and solution-free ("help me feel settled fast in a new city"), while a user story is disposable and solution-bound ("as a new user, I want to import my contacts"). One survives three product pivots; the other is closed and forgotten in two weeks.

What JTBD is best for

JTBD earns its keep before you've committed to building anything:

• Deciding whether a problem is worth solving at all. The job exists whether or not your product does. Naming it tells you the size of the prize.
• Understanding switching behavior — why customers fire their old solution and hire yours (or yours and hire a competitor's). This is the milkshake study's whole point.
• Exploring a new product line where no roadmap, no persona, and no feature set exist yet.
• Aligning a leadership team on the "why" behind a bet, where a list of features would just trigger feature-by-feature debate.

If the argument in the room is "should we even be doing this?", you're in JTBD territory. For a fuller treatment, see the Jobs-to-be-Done framework explained.

What user stories are best for

User stories earn their keep after the bet is made and you're slicing delivery:

• Breaking agreed work into shippable increments small enough to finish in a sprint and test against reality.
• Creating a shared, lightweight contract between product, design, and engineering on the next thing to ship.
• Sequencing and estimating — stories are the unit most agile tooling, planning, and velocity tracking are built around.
• Closing the loop — each story has an acceptance criterion, so "done" is unambiguous.

If the argument in the room is "how do we break this down and what's first?", you're in user-story territory.

The Job-to-Story Ladder

The reason these two get confused is that nobody shows the rung between them. Here it is — a three-layer ladder that takes one customer truth from strategy all the way to a sprint ticket:

The Job-to-Story Ladder is the named test: a healthy backlog can trace every user story back up to a job. If a story has no rung above it, you're building a feature nobody hired you for. If a job has no rungs below it, you have strategy with no delivery. Walk the ladder in both directions during backlog refinement — top-down to check coverage, bottom-up to check justification.

The middle rung — the job story — is the piece most teams skip. Popularized by Intercom's Alan Klement, it keeps JTBD's focus on situation and outcome while being concrete enough to design against, without prematurely committing to a persona or a feature the way a user story does.

The decision rule, on a real bet

Take Spotify's continued push into audiobooks through 2026. Imagine the team weighing two roadmap directions: deepen audiobook discovery, or build better in-listening controls.

• At the JTBD altitude, the question is which job is underserved. "When I have dead commute time, help me make progress on books I never finish" is a different job from "when I'm browsing, help me find my next great listen." Research — not a backlog — decides which job the audiobook business is losing customers on. That's a JTBD decision, and writing it as user stories too early would smuggle in a solution before the bet is chosen.
• Once the bet is chosen — say, "win the in-listening job" — user stories take over: autoplay-next-chapter, a sleep timer that bookmarks your place, variable playback speed. Each is a shippable increment with a clear acceptance test, and each traces cleanly back up the ladder to the chosen job.

The rule: if you're choosing between outcomes, use JTBD. If you've chosen the outcome and are choosing increments, use user stories. The moment you catch yourself writing user stories to justify a direction rather than to deliver a chosen one, stop and climb back up the ladder.

Edge cases and combined use

• B2B with many stakeholders: the job belongs to the buyer's organization; user stories often split across multiple personas (admin, end user, approver). Use JTBD to keep the stories anchored to one shared outcome instead of drifting into per-role wish lists.
• Platform / API products: the "user" is a developer and the job is "ship my own feature faster." Job stories travel better than persona-based user stories here, because the persona is thin but the situation is rich.
• Bug-fix and tech-debt work: neither framework fits cleanly — these are constraints on delivering the job, not jobs themselves. Don't force a job story onto a security patch.

For the layered relationship between JTBD, personas, and user stories together, see JTBD vs personas — personas describe who, JTBD describes what progress, and user stories describe what to build. Used together, the three answer who/why/what without overlap.

Related

• Jobs-to-be-Done framework explained — the full JTBD method, with worked examples
• JTBD vs personas — the other half of the customer-research picture
• RICE prioritization framework — once you have stories, RICE helps you sequence them
• Jobs-to-be-Done in the framework library

Want to model a customer's job on your phone? Framework for iPhone & iPad — fill in any framework with AI assistance.

Sources

• Clayton Christensen et al. — "Know Your Customers' Jobs to Be Done," Harvard Business Review (2016)
• Alan Klement / Intercom — "Using Job Stories to Design Features"
• Mike Cohn / Mountain Goat Software — "User Stories"
• Spotify Newsroom — Audiobooks