JTBD vs. User Stories: When to Use Which

A False Competition That Is Costing Product Teams Time

Every few years, the product management community invents a new thing that is going to replace user stories. Design thinking replaced them. Now JTBD is replacing them. Except user stories keep showing up in sprint planning, and the teams that abandoned them for something more sophisticated often find themselves arguing about what a feature should do without any shared language to resolve the argument.

The “JTBD vs. user stories” debate is mostly a false competition. It is generated by the same impulse that produces “design thinking vs. JTBD” debates: the belief that frameworks are substitutes for each other, when most of the time they are tools that operate at different stages of the same process.

The real question is not which one to use. The real question is: what decision are you trying to make, and which tool produces the inputs that decision requires?

User stories answer: what should this feature do for this type of user in this situation? They are precision instruments for specifying interactions between a user and a product. They operate at the implementation level.

JTBD answers: what goal is the customer trying to accomplish, independent of any specific product or solution? It operates at the strategy level — defining the problem space before any specific solution has been designed.

Using user stories without JTBD means specifying interactions without knowing whether those interactions serve a genuinely underserved need. Using JTBD without user stories means generating high-level strategic direction without the operational translation that development teams need to build things.

The organizations that produce the best products use both. This article explains exactly where each belongs in the product development process and how they connect.

What User Stories Are Actually For

The Origin and Intent of User Stories

User stories emerged from Extreme Programming and agile development in the late 1990s. Their original purpose was modest and practical: replace heavyweight requirements documents with lightweight, human-readable specifications that could fit on an index card. The standard format — “As a [type of user], I want [some goal] so that [some reason]” — was designed to keep the development team focused on user outcomes rather than technical implementation details.

Ron Jeffries, one of the originators, later reflected that user stories were always meant to be conversations, not specifications. The card was a placeholder for a conversation between the product owner and the development team about what the feature needed to do. The acceptance criteria were the real specification.

Over time, user stories became the de facto unit of work in agile development — and in that process, they accumulated more weight than they were designed to carry. They are now used simultaneously as conversation prompts, backlog items, sprint planning units, and requirements documentation. That versatility creates the impression that user stories are a complete framework for product management. They are not.

What User Stories Do Well

User stories are excellent tools for:

Specifying interactions. “As a fleet manager, I want to filter vehicle alerts by severity so that I can prioritize urgent issues without getting distracted by routine maintenance notifications.” This is a clear, testable specification of a specific interaction. It tells the development team exactly what to build and gives QA a test condition.

Maintaining development focus. The format forces product owners to articulate what type of user benefits, what the feature does, and why it matters — at least at a high level. This is more useful than a technical specification that describes what the system does without reference to who benefits.

Decomposing work. User stories are well-sized for sprint planning. A story that can be completed in two to five days, tested against acceptance criteria, and demonstrated at the sprint review is a productive unit of work. The agile process is designed around this unit.

Building shared understanding in the team. Because user stories are written in plain language, they can be understood by designers, engineers, and QA — not just product managers. This shared language reduces the translation loss that happens when requirements documents are handed over to development teams.

What User Stories Do Poorly

User stories are poor tools for:

Strategic prioritization. “We have 47 user stories in the backlog. Which ones matter most?” User stories do not contain the information needed to answer this question. They describe what users want, but not how important the underlying need is, how poorly current solutions address it, or how large a segment of customers shares the need.

Market definition. User stories take the product as given. They operate within the frame of “a user interacting with our product.” They cannot tell you whether you are building the right product for the right market or optimizing a solution that addresses the wrong job.

Competitive analysis. User stories describe interactions with your product. They do not help you understand what alternatives users are comparing your product against or why a user might choose a competitor’s approach.

Long-term strategy. User stories are inherently tactical and short-horizon. A well-managed backlog might plan three sprints ahead. User stories do not help you answer “where should we be in three years?”

What JTBD Is Actually For

The Strategic Layer

JTBD operates at a different level of abstraction than user stories. Where user stories ask “what should the product do for this user in this context?”, JTBD asks “what is this user trying to accomplish in their life or work, independent of any product?”

This shift in question produces a fundamentally different type of output. A JTBD analysis produces:

• A job statement that defines the market in terms of customer goals rather than product categories
• A job map that decomposes the goal into its functional process steps
• Desired outcome statements that capture what success looks like at each step of the job
• Quantitative opportunity scores that show which outcomes are most underserved

None of these outputs tell you what the product should do in a specific interaction. All of them tell you which customer needs are most worth addressing — which is the prior question.

JTBD as the Strategic Input to User Stories

The productive relationship between JTBD and user stories is sequential: JTBD defines the problem space; user stories specify the solution space.

When you know — from a quantitative JTBD study — that “minimize the time it takes to confirm that the load is within safe limits before transport begins” is a high-opportunity outcome (important to 84% of customers, satisfactorily addressed for only 31% of them), you have a precise brief for a feature or product improvement. You can write user stories directly against that outcome: “As a crane operator, I want to see a real-time load confirmation indicator in the cab display so that I do not need to exit the cab to visually inspect the load before each lift.”

Without the JTBD backstory, that user story competes with 47 others in the backlog with no principled way to rank it. With the JTBD backstory, it is clearly tied to a high-opportunity outcome for a large, underserved segment.

The Framework Comparison: Side by Side

Scope and Abstraction Level

JTBD: Strategy level. Asks about the goal independent of any product. Can cover a job that multiple products and technologies address. Scope is the customer’s goal, not a feature or product.

User Stories: Implementation level. Asks about a specific interaction between a specific user and a specific product. Scope is a single feature or workflow within an existing product.

Time Horizon

JTBD: Long-term. Because jobs are stable — they change very slowly over time — a JTBD analysis remains valid for years. The job of “restore blood flow to a blocked coronary artery” has been the same job for decades; the solutions have changed completely. Strategy built around the job outlasts any product generation.

User Stories: Short-term. A user story that does not get built in the current quarter is often obsolete by the time it is revisited. Product interactions change as the product evolves; old user stories may no longer reflect the current product context.

What They Measure and Produce

JTBD: Produces qualitative job maps (from interviews), quantitative opportunity scores (from surveys), and strategic recommendations (from analysis). The output is decision-grade input to product strategy.

User Stories: Produces interaction specifications with acceptance criteria. The output is implementation-grade input to development teams.

Who Uses Them

JTBD: Primarily product strategy, marketing, and senior product management. In our client engagements, the JTBD/ODI process typically involves VPs, product directors, and strategy leads — not individual contributors.

User Stories: Primarily product managers (as authors), development teams (as consumers), and QA (as verifiers). They operate at the team level, not the organizational level.

The Combination: A Practical Architecture

Layer 1: Job Definition and Market Strategy (JTBD)

At the highest level, JTBD defines the market in job terms and establishes the strategic direction. This layer answers: what job are we in the market to help customers do? Which outcomes related to that job are most underserved? Which customer segments have the largest unmet needs?

This work is done periodically — before major product planning cycles — not in every sprint. It requires the full ODI process: qualitative interviews for outcome discovery, quantitative surveys for opportunity scoring, cluster analysis for segmentation. The output feeds the product strategy layer.

Layer 2: Opportunity Prioritization (JTBD Outputs)

The second layer takes the quantitative outputs from the JTBD study and translates them into product strategy decisions. Which outcomes will we prioritize? Which market segments will we target? What product improvements or new products will address the highest-opportunity outcomes?

This work is done at the product strategy level, typically in quarterly or annual planning cycles. It connects JTBD research to the product roadmap. See also how this connects to product requirements informed by JTBD.

Layer 3: Feature Definition (User Stories)

At the implementation layer, user stories translate strategic product decisions into specific interactions. Given that we have decided to address outcome X for segment Y, what should the product do in practice? How should the interaction work? What are the acceptance criteria?

This work is done at the team level, in sprint planning and backlog refinement. User stories at this layer are annotated with the JTBD outcomes they address, creating a traceable link from implementation to strategy.

Layer 4: Validation and Learning

After features are shipped, validation closes the loop: are customers using the feature in the way the user story anticipated? Has the opportunity score for the underlying outcome improved? Are new outcomes becoming apparent through usage data?

This layer uses user analytics, customer interviews, and periodic re-measurement of outcome satisfaction. It feeds back into both the user story layer (are we building the right interactions?) and the JTBD layer (are our opportunity scores still current?).

Product teams that use only user stories are building within a box they never examine. Teams that use only JTBD have a map but no construction crew. The architecture that works is one where JTBD defines the terrain and user stories direct the building. They are not in competition — they are different tools for different altitudes.

When to Use JTBD Without User Stories

There are situations where JTBD analysis is the right tool and user stories are irrelevant:

Market definition. When you are deciding whether to enter a new market or exit an existing one, JTBD research gives you the data to make that call. User stories assume you are already in the market.

Platform strategy. When you are deciding what type of product to build — not what features to add to an existing one — JTBD defines the opportunity space. User stories presuppose a product.

Competitive strategy. When you need to understand why customers choose competitors over your product, JTBD research (particularly the forces of progress and opportunity segment analysis) gives you the answer. User stories do not contain competitive information.

Portfolio prioritization. When you have multiple product lines and need to decide where to invest R&D, JTBD opportunity scores across different jobs give you a principled basis for comparison. User story backlogs are too product-specific to support cross-portfolio comparison.

When to Use User Stories Without JTBD

Mature product teams in stable markets. If you have deep, validated JTBD research from a recent engagement, and you are working within a well-defined feature set, user stories are the right operational tool. You do not need to re-justify the strategic layer every sprint.

Specific interaction design. When the strategic direction is clear and the question is “how exactly should this work?”, user stories and acceptance criteria are the precision tools for that level of specification.

Bug fixes and technical debt. User stories are appropriate for specifying the resolution of known issues. JTBD is not the right tool for managing a bug backlog.

Speed-critical situations. When you need to ship something quickly — a regulatory change, a critical customer-reported issue, a competitive response — user stories let you specify and build without the overhead of strategic research.

A Practical Integration: The “Outcome-Story” Format

Some teams find it useful to bridge the two frameworks with a modified user story format that includes the JTBD context:

Standard user story format: “As a [user type], I want [feature] so that [benefit].”

Outcome-story format: “In the context of [job step], when [situation], [user type] needs to [outcome]. We will address this by: [feature description]. Acceptance criteria: [specific testable conditions].”

The “outcome-story” format retains the interaction specification of a user story while explicitly connecting it to the JTBD outcome it addresses. It is more verbose, which makes it better suited for high-stakes features where the connection to strategic research needs to be documented than for routine sprint items.

Practical Decision Guide: Which Tool to Reach For

For a deeper look at how this connects to broader ODI product management practices, including how opportunity scores translate to roadmap decisions, that is the logical next step.

Frequently Asked Questions