/nw-jtbd-core

name: nw-jtbd-core
description: Core JTBD theory and job story format - job dimensions, job story template, job stories vs user stories, 8-step universal job map, outcome statements, and forces of progress
user-invocable: false
disable-model-invocation: true

JTBD Core Theory

Jobs-to-be-Done reframes product development around the progress customers seek rather than products they buy. Customers "hire" products to accomplish specific jobs. The job exists independently of any solution.

The Three Job Dimensions

Every job has three dimensions. Capture all three during discovery -- functional jobs surface first, but emotional and social jobs drive switching decisions.

**Functional**: Practical task to accomplish. Measurable, concrete, articulated first.

• "Deploy a new feature to production without downtime"
• "Identify the root cause of a performance regression"

**Emotional**: How the customer wants to feel (or avoid feeling). Internal, personal, often unarticulated.

• "Feel confident that my changes will not break production"
• "Feel in control of the project timeline despite changing requirements"

**Social**: How the customer wants to be perceived. Identity, status, professional reputation.

• "Be seen as a technically competent lead who makes sound decisions"
• "Demonstrate to stakeholders that the team delivers measurable value"

Discovery Questions by Dimension

| Dimension | Questions | |-----------|-----------| | Functional | "What were you trying to accomplish?" / "Walk me through what you did." | | Emotional | "How did that make you feel?" / "What were you worried about?" | | Social | "Who else was involved or affected?" / "What would others think?" |

Job Story Format

Job stories emphasize situation and motivation rather than persona and action.

When [situation/context],
I want to [motivation/capability],
so I can [expected outcome/benefit].

Writing Tips

1. **Refine situation with context**: "When I am nearly done with a document" beats "When I want to save a document" 2. **Focus on job, not task**: Job is the higher-level goal; task is one possible way to achieve it 3. **Specify motivation, not implementation**: "I want to be confident my work is saved" not "I want a save button" 4. **Leave design space open**: Job stories do not prescribe solutions 5. **Reveal the forces**: Story should hint at push (frustration), pull (desire), anxiety (risk), habit (comfort)

Worked Example

## Job Story: Confident Production Deployment

**When** I am about to deploy a feature that touches payment processing,
**I want to** validate that all critical paths are covered by tests,
**so I can** deploy with confidence that revenue-generating flows will not break.

### Functional Job
Verify test coverage for critical business paths before deployment.

### Emotional Job
Feel confident and in control during high-stakes deployments.

### Social Job
Be trusted by the team as someone who ships reliably without causing incidents.

### Forces Analysis
- **Push**: Recent deployment broke checkout flow, causing revenue loss
- **Pull**: Automated coverage report would eliminate manual checking
- **Anxiety**: Will the coverage tool flag false negatives?
- **Habit**: Currently eyeballing test files manually before each deploy

Job Stories vs User Stories

| Aspect | User Story | Job Story | |--------|-----------|-----------| | Format | As a [persona], I want to [action], so that [benefit] | When [situation], I want to [motivation], so I can [outcome] | | Focus | Who the user is | What situation triggers the need | | Anchoring | Identity/role | Context/circumstance | | Grouping | Users grouped by role | Users grouped by situation | | Design driver | Persona characteristics | Causality and context |

When to Use Each

**Use job stories when**: defining product strategy | discovering new opportunities | early-stage requirements without established personas | same job applies across multiple roles

**Use user stories when**: detailed implementation planning with known personas | clear scope boundaries needed | tracking sprint backlog | stakeholders think in user profiles

**Use both together**: Job stories for strategic discovery, user stories for implementation. Job story reveals the *why*; user story captures the *what to build*.

The Translation Pipeline

Job Statement (strategic, solution-agnostic)
    |
    v
Job Story (contextual, situation-driven)
    |
    v
User Story (implementable, persona-driven)
    |
    v
Acceptance Criteria (testable conditions)
    |
    v
BDD Scenario (automatable Given-When-Then)

Example Translation

**Job Statement**: "Help me manage deployment risk when releasing new features"

**Job Story**: "When I am about to deploy a feature that touches payment processing, I want to validate that all critical paths are covered by tests, so I can deploy with confidence."

**User Story**: "As a developer deploying to production, I want to see a test coverage report for critical paths before deployment, so that I can verify all revenue-critical flows are tested."

**Acceptance Criteria**:

• Test coverage for payment processing module is at least 90%
• Coverage report highlights any critical paths with less than 80% coverage
• Deployment is blocked if any critical path has zero test coverage

The 8-Step Universal Job Map

All jobs follow this universal structure (Ulwick). Walk all 8 steps to surface requirements that feature-driven thinking misses.

| Step | Description | Discovery Question | |------|-------------|-------------------| | 1. **Define** | Determine goals, plan approach, assess resources | "What information do users need before starting?" | | 2. **Locate** | Gather necessary inputs, materials, information | "Where do users find the data/resources they need?" | | 3. **Prepare** | Set up environment, organize inputs | "What setup or configuration is required?" | | 4. **Confirm** | Verify readiness,