plugins/nw/skills/nw-jtbd-analysis/SKILL.md
JTBD methodology for extracting real jobs behind feature requests — job statements, abstraction layers, first-principles extraction, ODI outcome statements, and opportunity scoring
npx skillsauth add nwave-ai/nwave nw-jtbd-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A job is the progress a person is trying to make in a particular circumstance. Jobs are stable over time — technology changes, jobs don't. People hire products to make progress; they fire them when they fail.
The trap: Feature requests describe a proposed solution, not the underlying job. Always extract the job first.
When [situation/trigger], I want to [motivation/action], so I can [expected outcome]
Examples (good):
| Type | Question | Example | |------|----------|---------| | Functional | What task is the user trying to accomplish? | Find someone with complementary expertise | | Emotional | How does the user want to feel? | Feel confident approaching strangers | | Social | How does the user want to be perceived? | Appear professional and well-connected |
Jobs usually live at strategic or physical level, not tactical.
| Layer | Question | Example | |-------|----------|---------| | Tactical | How do we improve this interaction? | Better drag-and-drop for notes | | Operational | Why does this workflow exist? | Why do we need a facilitator? | | Strategic | What decision is being pursued? | How do we reduce direction uncertainty? | | Physical | What's the irreducible function? | Input → Synthesis → Convergence |
Navigation rules:
When a feature request is presented as a job, apply this:
Identify the Activity — What visible action is the user performing?
Reject the Activity as the Job — Does anyone wake up wanting to do this activity?
Strip to Irreducible Function — What remains if all tools and methods are removed?
Disruption check: Is there a higher-level job that would make this entire job unnecessary?
Format: [Direction] + [Metric] + [Object] + [Context]
Direction: Always "Minimize" (95% of time). "Maximize" only when more is genuinely better.
Metrics priority:
the time it takes to — speed/efficiency (preferred)the likelihood of — avoiding occurrencesthe likelihood that — avoiding resultsthe number of — quantity reductionthe effort required to — easeGood vs bad examples:
| Bad | Problem | Good | |-----|---------|------| | "I want easy video calls" | Ambiguous + solution | "Minimize the time it takes to start a conversation with a specific person" | | "Manage my network effectively" | Vague verb + ambiguous | "Minimize the time it takes to identify who can help with a specific need" | | "Use breakout rooms to talk privately" | Solution embedded | "Minimize the likelihood of conversations being overheard by unintended parties" | | "Don't miss important people" | Negative framing | "Minimize the likelihood of failing to connect with relevant attendees" |
Forbidden words: easy, reliable, good, better, effective, efficient, manage, handle, deal with. Forbidden patterns: solution references ("using AI", "via the app"), compound statements with "and"/"or", demographics.
Formula: Score = Importance + Max(0, Importance - Satisfaction)
Where Importance and Satisfaction are surveyed 1-10.
| Score | Interpretation | |-------|---------------| | > 12 | Under-served — high opportunity | | 10-12 | Appropriately served — maintain | | < 10 | Over-served — do not invest |
Output format per opportunity:
| Outcome | Importance | Satisfaction | Score | Status |
|---------|------------|--------------|-------|--------|
| Minimize time to find relevant attendees | 9.2 | 4.1 | 14.3 | Under-served |
Produce docs/feature/{feature-id}/diverge/job-analysis.md with:
Gate: Job must be at strategic or physical abstraction level. Tactical-level jobs are not acceptable input for brainstorming — elevate first.
testing
Acceptance test creation methodology for the DISTILL wave. Domain knowledge for the acceptance designer agent: port-to-port principle, prior wave reading, wave-decision reconciliation, graceful degradation, and document back-propagation.
development
Cross-agent collaboration protocols, workflow handoff patterns, and commit message formats for TDD/Mikado/refactoring workflows
development
Creates a phased roadmap.json for a feature goal with acceptance criteria and TDD steps. Use when planning implementation steps before execution.
testing
Acceptance test creation methodology for the DISTILL wave. Domain knowledge for the acceptance designer agent: port-to-port principle, prior wave reading, wave-decision reconciliation, graceful degradation, and document back-propagation.