Help us improve
Share bugs, ideas, or general feedback.
From sage
Systematically uncovers customer jobs, pains, and gains using the Jobs-to-be-Done framework. Produces structured JTBD analyses with job performer definitions, job process maps, pains/gains, and desired outcome statements. Use when the user mentions jobs to be done, JTBD, customer jobs, unmet needs, pains and gains, value proposition canvas, switch interviews, outcome-driven innovation, desired outcomes, or asks why customers hire or fire a product. Also triggers when the user wants to understand what job a product solves, conduct customer discovery, reposition a product around needs, define unmet needs for a roadmap, analyze competitors through a jobs lens, or create messaging grounded in customer objectives. Do NOT use for general market sizing, feature prioritization without a customer-needs lens, or persona creation based on demographics alone.
npx claudepluginhub xoai/sage --plugin sageHow this skill is triggered — by the user, by Claude, or both
Slash command
/sage:jtbdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a structured JTBD analysis: job performer, main job, circumstances, job process map, pains/gains, and (optionally) desired outcome statements.
Applies the Jobs-to-be-Done framework to uncover customer jobs, pains, and gains, producing structured analyses with job performer definitions, process maps, and outcome statements.
Analyzes customer research or product context to uncover functional, social, and emotional jobs to be done. Identifies pains, gains, prioritizes jobs, and suggests product implications.
Uncover customer jobs, pains, and gains using a structured JTBD framework. Use when clarifying unmet needs, repositioning a product, or improving discovery and messaging.
Share bugs, ideas, or general feedback.
Produce a structured JTBD analysis: job performer, main job, circumstances, job process map, pains/gains, and (optionally) desired outcome statements.
Copy this checklist and track progress:
JTBD Analysis Progress:
- [ ] Step 0: Check product context
- [ ] Step 1: Define job performer and context
- [ ] Step 2: Formulate the main job statement
- [ ] Step 3: Map the job process
- [ ] Step 4: Capture needs (pains/gains)
- [ ] Step 5: Quality check
- [ ] Step 6: Prioritize and identify implications
Before starting the analysis, read context.md.
[TODO] markers: All sections are filled in. Use this context to ground the entire analysis — it defines the product, segment, known insights, and scope. Proceed to Step 1.[TODO] markers in some sections: Those sections are not yet filled in. Before proceeding, ask the user to provide the missing information. Present all missing sections in a single message — don't ask one at a time.After context is established, verify each section is specific enough to ground the analysis. A product description of "B2B SaaS" alone is too thin — it should say what the product does, for whom, and what stage it's at. If any section is present but too vague to be useful, ask the user to elaborate on those specific sections before proceeding.
If context.md provided a target segment and existing knowledge, use that as a starting point — refine and deepen it, don't repeat it. If working assumptions were listed, treat them as hypotheses to pressure-test throughout the analysis, not facts to build on.
Identify who executes the job. Distinguish from the buyer — they have different needs.
Capture:
If the user hasn't done research, recommend methods from references/research-methods.md.
A job can be framed as a task to accomplish (Ulwick: "restore blood flow in a blocked artery") or as a transformation the performer seeks (Klement: "become someone who can grow my company beyond 5 employees"). Both are valid — task framing works well for functional analysis; transformation framing reveals deeper emotional motivations and helps with messaging. Use whichever fits the situation, or both.
Format: verb + object + clarifier
A well-formed job is solution-agnostic, stable over time, and has a clear "done" state.
Use "Why?" to move up in abstraction, "How?" to move down:
Also capture related jobs (adjacent objectives) and emotional/social jobs (how the performer wants to feel and be perceived). Formulation rules: see references/quality-checks.md.
Break the main job into stages. Use this universal scaffold and adapt:
For each stage, note what the performer is trying to accomplish and where friction exists. The map organizes where to probe for needs in Step 4.
Walk through each stage of the job map and capture what goes wrong and what ideal looks like.
Default: Pains and Gains (from the Value Proposition Canvas)
Use this for most analyses — it's accessible, workshop-friendly, and sufficient for early discovery and roadmap input.
Use template.md for the full fill-in structure. See examples/sample.md for worked examples.
Also analyze: The Four Forces of Progress (from Moesta)
Pains and gains capture what's wrong and what's desired, but they miss what blocks people from switching. The four forces determine whether someone actually acts:
People switch only when (Push + Pull) > (Anxiety + Habit). In practice, reducing anxiety often unlocks more demand than adding features. Casper disrupted mattresses not by building a better mattress, but by eliminating the anxiety of buying one (100-day returns, no showroom pressure, bed-in-a-box delivery).
For each force, probe functional, emotional, and social dimensions. See references/forces-and-timeline.md for detail and interview questions.
For higher rigor: Desired Outcome Statements (from Ulwick's ODI)
Use when needs must be quantitatively prioritizable — roadmap trade-offs, surveys, competitive scoring.
Format: direction + measure + object + clarifier
Attach outcomes to job map stages. A thorough pass yields 50–150; a lightweight pass yields 15–30. See references/quality-checks.md for formulation rules.
Before presenting results, validate against this checklist. If issues are found, fix and re-check.
Quality Validation:
- [ ] Job performer is defined and distinguished from buyer
- [ ] Main job follows verb + object + clarifier, no embedded solutions
- [ ] Emotional/social jobs are separate from functional jobs
- [ ] A struggling moment is identified — not just generic circumstances
- [ ] Current solutions documented including workarounds and non-obvious competitors
- [ ] Pains are specific (numbers, frequencies, consequences) — not "tools are bad"
- [ ] Gains are measurable or observable — not "better UX"
- [ ] No statement confuses a job with a solution (supply-side test: would an engineer write this, or a customer?)
- [ ] Forces of progress analyzed — especially anxiety and habit blocking the switch
- [ ] Needs are prioritized, not just listed
- [ ] Analysis is consistent with scope and constraints from context.md (if provided)
- [ ] Working assumptions from context.md are explicitly confirmed, challenged, or refined
If the analysis was built from assumptions rather than research, flag this explicitly. See references/pitfalls.md for common mistakes.
Rank pains by intensity (acute + frequent → highest priority). Separate must-have gains from nice-to-haves. Identify which forces of progress represent the biggest levers — often, reducing anxiety or breaking habit unlocks more demand than amplifying push or pull.
If using desired outcome statements, apply opportunity scoring: Opportunity = Importance + max(Importance − Satisfaction, 0). Scores above 12 are significant; above 15 are critical.
Check whether different performer segments have different unmet needs. Then surface implications for product strategy, messaging, and competitive positioning. For go-to-market implications, map findings to the buying timeline (First Thought → Passive Looking → Active Looking → Deciding → Onboarding → Ongoing Use) — see references/forces-and-timeline.md.
Frame value in terms of progress, not just outcomes. Progress is continuous — customers evaluate whether things are getting better at every touchpoint, not just at the end. A product that delivers an ongoing feeling of progress retains customers; one that delivers only a final outcome gets churned.
These are reminders, not explanations — apply them as quality filters throughout the workflow.
Bundled files (one level deep — read as needed):
Theoretical foundations: Christensen (Competing Against Luck), Ulwick (Jobs to be Done: Theory to Practice), Kalbach (The Jobs to be Done Playbook), Moesta (Demand-Side Sales 101), Klement (When Coffee and Kale Compete), Osterwalder (Value Proposition Design).