job-stories

Job Stories - Creating User-Centered Product Requirements

Skill Overview

The Job Stories skill helps product teams create structured user requirements using the format “When [situation], I want to [motivation], so I can [outcome],” accompanied by detailed acceptance criteria. This keeps product development focused on real user contexts rather than abstract role definitions.

Use Cases

1. Product Requirements Writing and Backlog Management

When product managers need to turn user research findings, customer feedback, or business goals into clear, actionable requirements, Job Stories provide a standardized format. By clarifying the user’s situation, motivation, and desired outcome, teams can avoid vague requirement descriptions and create a more targeted product backlog. This is especially suitable for Agile development and Scrum teams during sprint planning.

2. Translating User Research into Feature Requirements

After UX researchers and designers complete user interviews, usability tests, or field studies, they often face the challenge of translating research findings into requirements that engineering teams can act on. The Job Stories framework directly connects user research insights with feature planning, ensuring that every feature has clear user value and contextual support, while avoiding the trap of developing features “just for the sake of having features.”

3. Migrating from Traditional User Stories to the JTBD Method

Many teams find that traditional user stories (“As a [role], I want [feature]...”) focus too much on roles rather than real usage contexts, causing requirements to become disconnected from users’ actual needs. Based on the Jobs-to-be-Done theory, Job Stories help teams shift their focus from “who the user is” to “what task the user wants to accomplish in a particular situation,” improving requirement accuracy and user value.

Core Features

1. Structured Job Story Generation

Based on the product name, feature description, and user context provided, automatically generate Job Stories that follow the standard “When–I want–So I can” format. Each story includes a clear title, a detailed description, and 6–8 observable, measurable acceptance criteria, ensuring that the development team clearly understands what “done” looks like. Links to design files such as Figma and Miro are supported, keeping requirements and design in sync.

2. Context-Based Requirement Analysis

Go beyond traditional role definitions to deeply analyze users’ actual motivations and desired outcomes in specific situations. By identifying the context that triggers a need, defining the underlying motivation driving user behavior, and clarifying the outcome users want to achieve, this approach helps product teams understand “why users need this feature,” rather than merely “what feature users need.” This context-driven analysis can uncover deeper user needs and opportunity areas.

3. Actionable Acceptance Criteria Creation

Generate detailed acceptance criteria for each Job Story, covering context recognition, system behavior, user feedback, outcome achievement, edge-case handling, and integration notifications. Acceptance criteria use observable, measurable language and avoid vague expressions such as “user-friendly” or “fast response.” Instead, they specify concrete metrics and behaviors, such as “loads within 2 seconds,” “displays a progress bar,” or “sends a notification when 80% of the budget is reached,” ensuring clear benchmarks for testing and acceptance.

Frequently Asked Questions

What is the difference between Job Stories and traditional user stories?

Traditional user stories use the format “As a [role], I want [feature], so that [value].” They focus on the user’s role and feature requirements, which can easily cause requirements to become disconnected from actual usage scenarios. Job Stories use the format “When [situation], I want [motivation], so I can [outcome].” They focus on the user’s real motivation and desired outcome in a specific situation. Based on the Jobs-to-be-Done theory, they more accurately reflect users’ actual needs and behavioral drivers.

For example, a traditional story might say, “As an administrator, I want to export data,” while a Job Story would say, “When I need to prepare the weekly report (situation), I want to quickly export last week’s data (motivation), so I can complete the analysis before Friday’s meeting (outcome).” The latter includes a specific usage context and time pressure, making it more useful for designing a feature that fits the user’s actual workflow.

How do you write effective acceptance criteria for Job Stories?

Effective acceptance criteria should be observable and measurable, avoiding vague descriptions. Consider six dimensions:

Context recognition: How does the system identify that the user is in this situation?

System behavior: What capabilities or support does the system need to provide?

User feedback: How does the user know the operation is being processed?

Outcome achievement: How can the user confirm that the goal has been achieved?

Edge-case handling: How are exceptional situations handled?

Integration notifications: How does the feature work with other systems or notifications?

Use specific metrics instead of vague descriptions—for example, “loads within 2 seconds” rather than “loads quickly,” and “displays a progress bar and estimated time remaining” rather than “provides feedback.” Refer to the example in the skill, “Track Weekly Snack Spending,” whose acceptance criteria include “display a weekly spending overview,” “show a progress bar representing 0–100% of the budget,” and “send a notification when 80% is reached.”

What types of product development are Job Stories suitable for?

Job Stories are especially suitable for the following scenarios:

B2B SaaS products: Users complete tasks in specific work situations, such as “When I prepare the quarterly report, I want to export data...”

Consumer applications: Users interact with products in everyday contexts, such as “When I commute, I want to read content offline...”

Feature optimization and iteration: Clarify the situations in which users encounter problems, such as “When my network connection is unstable, I want the system to retry automatically...”

New feature discovery: Extract situations and motivations from user research, such as “When I need to collaborate quickly, I want to edit in real time...”

For underlying technical components or purely internal systems, such as database migration scripts, Job Stories may be less suitable than traditional technical specifications. If a team frequently debates “who this feature is for” during requirement reviews, or discovers after development that “the user scenario does not match expectations,” the Job Stories framework can help improve requirement quality and product value.