jtbd-framing
The Jobs-to-be-Done framework as applied product methodology. Job statements, struggling moments, hire and fire criteria, the difference between feature-thinking and job-thinking. Honest about where JTBD adds clarity (discovery, prioritization, positioning) and where it becomes performative ritual (job-statement workshops that do not drive decisions, persona-theater disguised as JTBD). Triggers on jobs-to-be-done, JTBD, job statements, struggling moments, hire criteria, fire criteria, switch triggers, functional emotional social jobs, outcome-driven innovation. Also triggers when a team is ove
npx skills add rampstackco/claude-skills --skill jtbd-framing --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Guides product teams in using the JTBD framework to articulate what users are trying to accomplish (the job) through job statements, struggling moments, and hire/fire criteria, distinguishing between task-focused framing and actual decision-driving JTBD. Emphasizes three modes where JTBD adds value (discovery, prioritization, positioning) and warns against ritualistic usage (workshops, personas, mandatory framing).
How it works
Outlines concrete JTBD structures and principles:
- Defines job statements, struggling moments, and hire/fire criteria as the core inputs.
- Presents the canonical job statement structure: "When [situation], I want to [motivation], so I can [outcome]." with examples for Situation, Motivation, and Outcome.
- Describes the three dimensions of jobs (functional, emotional, social) and how to interrogate statements across those dimensions.
- Contrasts feature-request lists and persona-theater with job-framing, explaining how to evaluate whether JTBD grounding actually informs decisions.
- Provides guidance on applying JTBD to discovery, prioritization, and positioning, with cross-references to broader disciplines (discovery-research-synthesis, roadmap-planning, creative-direction).
- Lists common failure modes (workshops not driving decisions, generic job statements, conflating personas with jobs) and how to avoid them.
When to use it
States explicit usage triggers:
- During discovery to surface user motivations through struggling moments and hire/fire decisions.
- When replacing persona-driven prioritization with job-driven prioritization.
- When reframing positioning around the job users hire the product to do.
- For auditing existing JTBD work to ensure it drives decisions rather than remaining as artifacts.
What it can touch
Mentions the actionable artifacts and relationships:
- Job statements, struggling moments, hire and fire criteria as inputs for decisions.
- Output: product decisions grounded in user motivation.
- Interaction with broader disciplines: discovery-research-synthesis, roadmap-planning, creative-direction, brand-discovery.
Caveats
Highlights potential risks and limitations:
- JTBD can become ritual if workshops become deliverables without influencing decisions or if job statements replace analytical rigor.
- Over-reliance on JTBD framing without tying to roadmap or decision-making can lead to CV-like artifacts with little impact.
- Distinguishes between genuine JTBD contributions and performative usage (e.g., mandatory framing in meetings).
- Advocates grounding statements in specific moments and concrete struggling moments to avoid generic job statements.
# Jobs-to-be-Done Framing A senior product leader's playbook for the Jobs-to-be-Done framework as applied methodology. Job statements, struggling moments, hire and fire criteria, the difference between feature-thinking and job-thinking. Honest about where JTBD adds clarity and where it becomes performative ritual. JTBD has become one of the more cited and less practiced frameworks in product. Teams cite it in strategy docs, run job-statement workshops, produce wall-sized artifacts, and continue building from feature requests and persona archetypes the next quarter. The methodology gets the credit; the practice gets skipped. This skill is JTBD as applied product methodology. The framework's actual contribution: surfacing what users are trying to ACCOMPLISH (the job) rather than treating users as preference-aggregators (feature requests) or demographic archetypes (persona theater). When the framing is grounded in struggling moments and hire/fire criteria, it produces decisions; when it stops at the job-statement worksheet, it produces ritual. This skill is honest about both modes. JTBD genuinely earns its keep in discovery, prioritization, and positioning when applied with rigor. It
- What this skill is for
- Feature-request-list vs persona-theater vs job-framing
- The job statement structure
- Identifying struggling moments
- Hire and fire criteria
- Functional, emotional, and social dimensions of jobs
- Where JTBD adds clarity vs where it becomes ritual
- Applying JTBD to discovery, prioritization, positioning
- Common failure modes
- The framework: 12 considerations for JTBD framing
- Reference files
- Closing: jobs over features
What does the jtbd-framing skill do?
The Jobs-to-be-Done framework as applied product methodology. Job statements, struggling moments, hire and fire criteria, the difference between feature-thinking and job-thinking. Honest about where JTBD adds clarity (discovery, prioritization, positioning) and where it becomes performative ritual (job-statement workshops that do not drive decisions, persona-theater disguised as JTBD). Triggers on jobs-to-be-done, JTBD, job statements, struggling moments, hire criteria, fire criteria, switch triggers, functional emotional social jobs, outcome-driven innovation. Also triggers when a team is ove
How do I install it?
Run `npx skills add rampstackco/claude-skills --skill jtbd-framing --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From rampstackco/claude-skills, a repository with 515 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.