From product-owner
Define a Jobs-to-be-Done analysis for a product or feature area. Produces structured job statements, outcome expectations, and hiring/firing criteria. Use when entering a new problem space, validating product-market fit, or reframing features as customer jobs.
npx claudepluginhub hpsgd/turtlestack --plugin product-ownerThis skill is limited to using the following tools:
Define a Jobs-to-be-Done analysis for $ARGUMENTS.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Define a Jobs-to-be-Done analysis for $ARGUMENTS.
Follow every step below. The output must be a complete JTBD analysis that product, design, and engineering can use to evaluate feature priorities — not a theoretical exercise.
Before writing job statements, define who is hiring the product:
Document each job performer with:
| Field | Description |
|---|---|
| Performer | Specific role + circumstance |
| Triggering context | The moment the job arises |
| Current solution | What they hire today |
| Frequency | How often does this job arise? |
| Emotional state | How do they feel when the job arises? (stressed, curious, bored, anxious) |
The functional job is the anchor. Write it using the canonical format:
When I [situation/context],
I want to [motivation/action],
so I can [expected outcome/goal].
Write exactly one core functional job. This is the primary job the product is hired to do.
Every core functional job has related jobs that influence the hiring decision. Map all three types:
Jobs that must be done before, during, or after the core job:
| Sequence | Job Statement | Relationship to Core Job |
|---|---|---|
| Before | When I [context], I want to [action], so I can [outcome] | Precondition for the core job |
| During | When I [context], I want to [action], so I can [outcome] | Happens alongside the core job |
| After | When I [context], I want to [action], so I can [outcome] | Follow-up to the core job |
How the performer wants to feel (or avoid feeling) while getting the job done:
Write each as: "I want to feel [emotion] when [doing the core job]" or "I want to avoid feeling [emotion] when [doing the core job]."
How the performer wants to be perceived by others:
Do not skip emotional and social jobs. They are often the real reason someone switches products. The functional job is table stakes — emotional and social jobs differentiate.
For each job (core + related), define the outcomes the performer uses to measure success. Outcomes follow the format:
[Direction] + [metric] + [object of control] + [context]
Examples:
| # | Job | Outcome Statement | Importance (1-10) | Current Satisfaction (1-10) | Opportunity |
|---|---|---|---|---|---|
| 1 | Core | Minimise the time it takes to... | 9 | 3 | Underserved |
| 2 | Core | Minimise the likelihood of... | 8 | 7 | Adequately served |
| 3 | Related | Increase the confidence that... | 7 | 2 | Underserved |
Opportunity Score = Importance + max(Importance - Satisfaction, 0). Scores above 12 are underserved. Scores below 6 are overserved.
Rules:
What causes the performer to seek a new solution? Map the "switching triggers":
| Trigger | Description | Example |
|---|---|---|
| Push (current solution) | What frustration with the current solution causes them to look? | "My spreadsheet broke when we hit 10,000 rows" |
| Pull (new solution) | What attractive quality of the new solution draws them in? | "I saw a demo where the report generated in 2 seconds" |
| Anxiety (switching cost) | What fear prevents them from switching? | "Will I lose my historical data?" |
| Habit (inertia) | What keeps them with the current solution despite frustration? | "My team already knows how to use the spreadsheet" |
What would cause the performer to stop using the product?
Synthesise the analysis into actionable product decisions:
Classify every outcome from Step 4:
| Category | Definition | Product Implication |
|---|---|---|
| Underserved | High importance, low satisfaction (opportunity > 12) | Build here — this is where value is created |
| Adequately served | Importance matches satisfaction | Maintain parity — do not regress |
| Overserved | Low importance, high satisfaction (opportunity < 6) | Simplify or remove — you are over-investing |
For each underserved outcome:
# Jobs-to-be-Done Analysis: [Product Area / Feature]
## Job Performer
| Field | Description |
|-------|-------------|
| **Performer** | [Specific role + circumstance] |
| **Triggering context** | [The moment the job arises] |
| **Current solution** | [What they hire today] |
| **Frequency** | [How often] |
| **Emotional state** | [How they feel] |
## Core Functional Job
> When I [situation], I want to [motivation], so I can [outcome].
## Related Jobs
### Functional
| Sequence | Job Statement | Relationship |
|----------|---------------|--------------|
| Before | ... | ... |
| During | ... | ... |
| After | ... | ... |
### Emotional
- I want to feel [emotion] when [context]
- I want to avoid feeling [emotion] when [context]
### Social
- I want to be seen as [perception] by [audience]
## Desired Outcomes
| # | Job | Outcome Statement | Importance | Satisfaction | Opportunity |
|---|-----|-------------------|------------|--------------|-------------|
| 1 | ... | ... | ... | ... | ... |
## Hiring / Firing Criteria
### Hiring (switching triggers)
| Push | Pull | Anxiety | Habit |
|------|------|---------|-------|
| ... | ... | ... | ... |
### Firing (churn triggers)
1. [Firing moment] — [sudden / gradual]
## Product Implications
### Underserved Opportunities
| Outcome | What to Build | Success Metric |
|---------|---------------|----------------|
| ... | ... | ... |
### Overserved (deprioritise)
- [Outcome] — current investment exceeds importance
Write the output to a file: docs/jtbd-[area].md.
/product-owner:write-prd — JTBD informs the PRD problem statement. The core job becomes the "problem" section; underserved outcomes become requirements./ux-researcher:persona-definition — personas and jobs are complementary lenses. Personas describe who; jobs describe why.Use the JTBD canvas template (templates/jtbd-canvas.md) for output structure.