From nw
Provides JTBD core theory: job dimensions, story format/template, 8-step universal job map, outcomes, forces of progress. Frames jobs over user stories for product discovery.
npx claudepluginhub nwave-ai/nwave --plugin nwThis skill uses the workspace's default tool permissions.
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.
Writes JTBD job stories and maps customer jobs across functional, social, emotional dimensions. Use for defining user needs, JTBD research, and reframing features around outcomes.
Applies JTBD framework to analyze requirements, uncovering functional, emotional, and social customer jobs for reframing features as outcomes and prioritizing motivations.
Applies Jobs-to-be-Done framework to map customer triggers, functional/emotional/social jobs, hiring/firing criteria, and outcome metrics for product development.
Share bugs, ideas, or general feedback.
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.
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.
Emotional: How the customer wants to feel (or avoid feeling). Internal, personal, often unarticulated.
Social: How the customer wants to be perceived. Identity, status, professional reputation.
| 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 stories emphasize situation and motivation rather than persona and action.
When [situation/context],
I want to [motivation/capability],
so I can [expected outcome/benefit].
## 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
| 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 |
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.
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)
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:
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, validate inputs | "How do users confirm they have everything?" |
| 5. Execute | Perform the core task | "What is the primary action sequence?" |
| 6. Monitor | Check progress, verify results | "How do users know if things are working?" |
| 7. Modify | Adjust, handle exceptions, course-correct | "What do users do when something goes wrong?" |
| 8. Conclude | Finalize, clean up, assess outcome | "How do users wrap up and assess success?" |
Steps 1-4 (Define through Confirm) are where most missing requirements hide. Teams jump straight to Execute without considering the full journey.
Express customer needs as measurable, solution-free metrics. Used in opportunity scoring (see jtbd-opportunity-scoring skill).
[Direction] + the [metric] + [object of control] + [contextual clarifier]
Direction: "Minimize" or "Maximize". Metric: time, likelihood, number, or frequency.
For a switch to happen, Push + Pull must exceed Anxiety + Habit. Teams often focus only on Pull (making product attractive) while ignoring Anxiety and Habit reduction.
PROGRESS (switching happens)
^
|
Push of ----+---- Pull of New
Current | Solution
Situation |
|
NO PROGRESS (staying put)
^
|
Anxiety ----+---- Habit of
of New | Present
Solution |
## Forces Analysis: [Feature/Decision]
### Demand-Generating
- **Push**: [Current frustrations driving change]
- **Pull**: [Attractions of the new solution]
### Demand-Reducing
- **Anxiety**: [Fears about the new approach]
- **Habit**: [Inertia of the current approach]
### Assessment
- Switch likelihood: [High/Medium/Low]
- Key blocker: [Strongest demand-reducing force]
- Key enabler: [Strongest demand-generating force]
- Design implication: [What the product must do to tip the balance]
jtbd-interviews skilljtbd-opportunity-scoring skilljtbd-bdd-integration skillpersona-jtbd-analysis skilljtbd-workflow-selection skill