jobs-to-be-done

deanpeters/product-manager-skills · updated Apr 8, 2026

MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.

$npx skills add https://github.com/deanpeters/product-manager-skills --skill jobs-to-be-done
0 commentsdiscussion
summary

Structured framework for uncovering customer jobs, pains, and gains to validate product ideas and improve messaging.

  • Breaks customer needs into three categories: functional jobs (tasks to complete), social jobs (how they want to be perceived), and emotional jobs (emotional states they seek or avoid)
  • Identifies four pain types: challenges blocking progress, costliness in time/money/effort, common mistakes, and unresolved problems current solutions don't address
  • Surfaces four gain type
skill.md

Purpose

Systematically explore what customers are trying to accomplish (functional, social, emotional jobs), the pains they experience, and the gains they seek. Use this framework to uncover unmet needs, validate product ideas, and ensure your solution addresses real motivations—not just surface-level feature requests.

This is not a survey—it's a structured lens for understanding why customers "hire" your product and what would make them "fire" it.

Key Concepts

The Jobs-to-be-Done Framework

Influenced by Clayton Christensen and the Value Proposition Canvas (Osterwalder), JTBD breaks customer needs into three categories:

1. Customer Jobs:

  • Functional jobs: Tasks customers need to perform (e.g., "send an invoice")
  • Social jobs: How customers want to be perceived (e.g., "look professional to clients")
  • Emotional jobs: Emotional states customers seek or avoid (e.g., "feel confident in my work")

2. Pains:

  • Challenges: Obstacles customers face
  • Costliness: What's too expensive in time, money, or effort
  • Common mistakes: Errors customers make that could be prevented
  • Unresolved problems: Gaps in current solutions

3. Gains:

  • Expectations: What would exceed current solutions
  • Savings: Time, money, or effort reductions that delight
  • Adoption factors: What increases likelihood of switching
  • Life improvement: How a solution makes life easier or more enjoyable

Why This Structure Works

  • Separates job from solution: "Communicate with my team" (job) ≠ "email" (solution)
  • Reveals underlying motivations: Functional job may be "track expenses," but emotional job is "feel in control of finances"
  • Surfaces competition you didn't see: Customers "hire" non-obvious alternatives (pen and paper, spreadsheets, workarounds)
  • Prioritizes by intensity: Not all pains are equal—focus on the most acute

Anti-Patterns (What This Is NOT)

  • Not a feature wishlist: "I want AI, automation, and dashboards" is not a job
  • Not demographics: "Millennials want mobile-first" is a persona trait, not a job
  • Not generic: "Be more productive" is too vague—dig into which tasks and why
  • Not one-dimensional: Focusing only on functional jobs misses social/emotional motivations

When to Use This

  • Early-stage discovery (before you know the solution)
  • Validating product-market fit (does your solution address the right jobs?)
  • Prioritizing roadmap (which jobs are most painful/important?)
  • Competitive analysis (what are customers "hiring" competitors for?)
  • Marketing messaging (speak to jobs, not features)

When NOT to Use This

  • After you've already built the product (too late for discovery)
  • For trivial features (don't over-analyze small tweaks)
  • As a substitute for quantitative validation (JTBD informs hypotheses; data validates them)

Application

Use template.md for the full fill-in structure.

Step 1: Define the Context

Before exploring JTBD, clarify:

  • Target customer segment: Who are you studying? (reference skills/proto-persona/SKILL.md)
  • Situation: In what context does the job arise? (e.g., "When managing a project deadline...")
  • Current solutions: What do they use today? (competitors, workarounds, doing nothing)

If missing context: Conduct customer interviews, contextual inquiries, or "switch interviews" (why they switched from a previous solution).


Step 2: Explore Customer Jobs

Functional Jobs

Ask: "What tasks are you trying to complete?"

### Functional Jobs:
- [Task 1 customer needs to perform]
- [Task 2 customer needs to perform]
- [Task 3 customer needs to perform]

Examples:

  • "Reconcile monthly expenses for tax filing"
  • "Onboard a new team member in under 2 hours"
  • "Deploy code to production without downtime"

Quality checks:

  • Verb-driven: Jobs are actions ("send," "analyze," "coordinate")
  • Solution-agnostic: Don't say "use email to communicate"—say "communicate with remote teammates"
  • Specific: "Manage finances" is too broad; "Track business expenses for tax deductions" is specific

Social Jobs

Ask: "How do you want to be perceived by others?"

### Social Jobs:
- [Way customer wants to be perceived socially 1]
- [Way customer wants to be perceived socially 2]
- [Way customer wants to be perceived socially 3]

Examples:

  • "Be seen as a strategic thinker by my exec team"
  • "Appear responsive and reliable to clients"
  • "Look tech-savvy to my younger colleagues"

Quality checks:

  • Audience-specific: Who is the customer trying to impress? (boss, clients, peers, etc.)
  • Emotional weight: Social jobs often drive adoption more than functional jobs

Emotional Jobs

Ask: "What emotional state do you want to achieve or avoid?"

### Emotional Jobs:
- [Emotional state customer seeks or avoids 1]
- [Emotional state customer seeks or avoids 2]
- [Emotional state customer seeks or avoids 3]

Examples:

  • "Feel confident I'm not missing important details"
  • "Avoid the anxiety of manual data entry errors"
  • "Feel a sense of accomplishment at the end of the day"

Quality checks:

  • Positive and negative: Include both what they seek ("feel in control") and what they avoid ("avoid embarrassment")
  • Rooted in research: Don't fabricate emotions—use customer quotes

Step 3: Identify Pains

Challenges

Ask: "What obstacles are preventing you from completing this job?"

### Challenges:
- [Obstacle customer faces 1]
- [Obstacle customer faces 2]
- [Obstacle customer faces 3]

Examples:

  • "Tools don't integrate, forcing manual data entry"
  • "No visibility into what teammates are working on"
  • "Approval processes take 3+ days, blocking progress"

Costliness

Ask: "What takes too much time, money, or effort?"

### Costliness:
- [What's too costly in time, money, or effort 1]
- [What's too costly in time, money, or effort 2]

Examples:

  • "Generating monthly reports takes 8 hours of manual work"
  • "Hiring a specialist costs $10k, which we can't afford"
  • "Learning the current tool requires 20+ hours of training"

Common Mistakes

Ask: "What errors do you make frequently that could be prevented?"

### Common Mistakes:
- [Frequent error 1]
- [Frequent error 2]

Examples:

  • "Forgetting to CC stakeholders on critical emails"
  • "Miscalculating tax deductions due to missing receipts"
  • "Accidentally overwriting someone else's work in shared files"

Unresolved Problems

Ask: "What problems do current solutions fail to address?"

### Unresolved Problems:
- [Problem not solved by current solutions 1]
- [Problem not solved by current solutions 2]

Examples:

  • "Current CRM doesn't track customer health scores"
  • "Email doesn't preserve conversation context when people are added mid-thread"
  • "Existing tools require technical expertise we don't have"

Step 4: Uncover Gains

Expectations

Ask: "What would make you love a solution?"

### Expectations:
- [What could exceed expectations 1]
- [What could exceed expectations 2]

Examples:

  • "Automatically categorizes expenses without manual tagging"
  • "Suggests next steps based on project status"
  • "Integrates seamlessly with tools we already use"

Savings

Ask: "What savings in time, money, or effort would delight you?"

### Savings:
- [Way of saving time, money, or effort 1]
- [Way of saving time, money, or effort 2]

Examples:

  • "Reduce report generation from 8 hours to 10 minutes"
  • "Eliminate the need for a full-time admin"
  • "Cut onboarding time from 2 weeks to 2 days"

Adoption Factors

Ask: "What would make you switch from your current solution?"

### Adoption Factors:
- [Factor increasing likelihood of adoption 1]
- [Factor increasing likelihood of adoption 2]

Examples:

  • "Free trial with no credit card required"
  • "Migration support to import existing data"
  • "Testimonials from companies like ours"

Life Improvement

Ask: "How would your life be better if this job were easier?"

### Life Improvement:
- [How solution makes life easier or more enjoyable 1]
- [How solution makes life easier or more enjoyable 2]

Examples:

  • "I could leave work on time instead of staying late to finish reports"
  • "I'd feel less stressed about missing important deadlines"
  • "I could focus on strategic work instead of busywork"

Step 5: Prioritize and Validate

  • Rank pains by intensity: Which pains are acute vs. mild annoyances?
  • Identify must-have vs. nice-to-have gains: What would drive adoption vs. what's just a bonus?
  • Cross-reference with personas: Do different personas have different jobs/pains/gains? (reference skills/proto-persona/SKILL.md)
  • Validate with data: Survey a broader audience to confirm JTBD insights from interviews

Examples

See examples/sample.md for full JTBD examples.

Mini example excerpt:

**Functional Jobs:** Coordinate tasks across a distributed team
**Pains - Challenges:** Team members use different tools, creating silos
**Gains - Savings:** Reduce status reporting time from 3 hours to 15 minutes

Common Pitfalls

Pitfall 1: Confusing Jobs with Solutions

Symptom: "I need to use Slack" or "I need AI-powered analytics"

Consequence: You've anchored on a solution, not the underlying job.

Fix: Ask "Why?" 5 times. "I need Slack" → "Why?" → "To communicate with my team" → "Why?" → "To get quick answers" → "Why?" → "To avoid project delays."


Pitfall 2: Generic Jobs

Symptom: "Be more productive" or "Save time"

Consequence: Too vague to inform product decisions.

Fix: Get specific. "Save time" → "Reduce time spent generating monthly reports from 8 hours to 1 hour."


Pitfall 3: Ignoring Social/Emotional Jobs

Symptom: Only documenting functional jobs

Consequence: You miss powerful motivators. People often buy based on emotional/social needs, not just functional.

Fix: Explicitly ask about perception and emotions in interviews. "How would solving this make you feel?" "Who would notice if you solved this?"


Pitfall 4: Fabricating JTBD Without Research

Symptom: Filling out the template based on assumptions

Consequence: You're guessing. JTBD analysis is only valuable if grounded in real customer insights.

Fix: Conduct "switch interviews" (ask why they switched from a previous solution), contextual inquiries, or problem validation interviews.


Pitfall 5: Treating All Pains as Equal

Symptom: Listing 20 pains without prioritization

Consequence: No clarity on what to solve first.

Fix: Rank pains by intensity (acute vs. mild). Ask "If we only solved one pain, which would have the biggest impact?"


References

Related Skills

  • skills/proto-persona/SKILL.md — Defines who has these jobs/pains/gains
  • skills/problem-statement/SKILL.md — JTBD informs the "Trying to" and "But" sections
  • skills/positioning-statement/SKILL.md — JTBD informs the "that need" statement

External Frameworks

  • Clayton Christensen, Competing Against Luck (2016) — Origin of Jobs-to-be-Done theory
  • Tony Ulwick, Outcome-Driven Innovation (2016) — Quantifying jobs and outcomes
  • Alexander Osterwalder, Value Proposition Canvas (2014) — Customer jobs/pains/gains framework

Dean's Work

  • [Link to relevant Dean Peters' Substack articles if applicable]

Provenance

  • Adapted from prompts/jobs-to-be-done.md in the https://github.com/deanpeters/product-manager-prompts repo.

Skill type: Component Suggested filename: jobs-to-be-done.md Suggested placement: /skills/components/ Dependencies: References skills/proto-persona/SKILL.md Used by: skills/positioning-statement/SKILL.md, skills/problem-statement/SKILL.md, skills/epic-hypothesis/SKILL.md

how to use jobs-to-be-done

How to use jobs-to-be-done on Cursor

AI-first code editor with Composer

1

Prerequisites

Before installing skills in Cursor, ensure your development environment meets these requirements:

  • Cursor installed and configured on your development machine
  • Node.js version 16.0+ with npm package manager (verify with node --version)
  • Active project directory or workspace where you want to add jobs-to-be-done
2

Execute installation command

Execute the skills CLI command in your project's root directory to begin installation:

$npx skills add https://github.com/deanpeters/product-manager-skills --skill jobs-to-be-done

The skills CLI fetches jobs-to-be-done from GitHub repository deanpeters/product-manager-skills and configures it for Cursor.

3

Select Cursor when prompted

The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:

◆ Which agents do you want to install to?
│ ── Universal (.agents/skills) ── always included ────
│ • Amp
│ • Antigravity
│ • Cline
│ • Codex
│ ●Cursor(selected)
│ • Cursor
│ • Windsurf
4

Verify installation

Confirm successful installation by checking the skill directory location:

.cursor/skills/jobs-to-be-done

Reload or restart Cursor to activate jobs-to-be-done. Access the skill through slash commands (e.g., /jobs-to-be-done) or your agent's skill management interface.

Security & Verification Notice

We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.

Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.

List & Monetize Your Skill

Submit your Claude Code skill and start earning

GET_STARTED →

Use Cases

User Story & Requirements Generation

Create detailed user stories, acceptance criteria, and feature specs

Example

Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios

Reduce spec writing time by 50%, ensure comprehensive coverage

Competitive Analysis

Research competitors, compare features, identify gaps

Example

Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities

Complete competitive research in 2 hours instead of 2 days

Roadmap Prioritization

Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs

Example

Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale

Make data-driven prioritization decisions faster

Stakeholder Communication

Draft PRDs, status updates, and stakeholder presentations

Example

Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement

Save 3-5 hours/week on communication overhead

Implementation Guide

Prerequisites

  • Claude Desktop or compatible AI client
  • Access to product documentation and roadmap tools (Jira, Notion, etc.)
  • Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
  • Stakeholder contact information and communication channels

Time Estimate

30-60 minutes to see productivity improvements

Installation Steps

  1. 1.Install product management skill
  2. 2.Start with user story generation for known feature
  3. 3.Progress to competitive analysis: research 2-3 competitors
  4. 4.Use for roadmap prioritization: apply RICE/ICE scoring
  5. 5.Draft stakeholder communications and refine based on feedback
  6. 6.Build template library for recurring PM tasks
  7. 7.Share effective prompts with product team

Common Pitfalls

  • Not validating competitive research—verify facts before sharing
  • Accepting user stories without involving engineering team
  • Over-relying on frameworks without qualitative judgment
  • Not customizing outputs to company culture and communication style
  • Skipping stakeholder validation of generated requirements

Best Practices

✓ Do

  • +Validate research and competitive analysis with real data
  • +Collaborate with engineering when generating technical requirements
  • +Customize frameworks and templates to your company context
  • +Use skill for first drafts, refine with stakeholder input
  • +Document successful prompt patterns for PM tasks
  • +Combine AI efficiency with human judgment and intuition

✗ Don't

  • Don't publish competitive analysis without fact-checking
  • Don't finalize user stories without engineering review
  • Don't make prioritization decisions solely on AI scoring
  • Don't skip customer validation of generated requirements
  • Don't ignore company-specific context and culture

💡 Pro Tips

  • Provide context: company goals, constraints, customer feedback
  • Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
  • Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
  • Use skill for 70% generation + 30% customization to company needs

When to Use This

✓ Use When

Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.

✗ Avoid When

Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.

Learning Path

  1. 1Basic: user stories, feature specs, status updates
  2. 2Intermediate: competitive analysis, prioritization frameworks, PRDs
  3. 3Advanced: product strategy, go-to-market planning, OKR setting
  4. 4Expert: product vision, market positioning, business model innovation

Discussion

Product Hunt–style comments (not star reviews)
  • No comments yet — start the thread.
general reviews

Ratings

4.547 reviews
  • Shikha Mishra· Dec 20, 2024

    jobs-to-be-done is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.

  • Meera Rao· Dec 12, 2024

    We added jobs-to-be-done from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.

  • Evelyn Patel· Dec 12, 2024

    Solid pick for teams standardizing on skills: jobs-to-be-done is focused, and the summary matches what you get after install.

  • Ishan White· Nov 23, 2024

    Useful defaults in jobs-to-be-done — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.

  • Yash Thakker· Nov 11, 2024

    Useful defaults in jobs-to-be-done — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.

  • Sakshi Patil· Nov 3, 2024

    Keeps context tight: jobs-to-be-done is the kind of skill you can hand to a new teammate without a long onboarding doc.

  • Aditi Taylor· Nov 3, 2024

    jobs-to-be-done has been reliable in day-to-day use. Documentation quality is above average for community skills.

  • Chaitanya Patil· Oct 22, 2024

    We added jobs-to-be-done from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.

  • Aditi Martin· Oct 22, 2024

    jobs-to-be-done fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.

  • Hiroshi Okafor· Oct 14, 2024

    Registry listing for jobs-to-be-done matched our evaluation — installs cleanly and behaves as described in the markdown.

showing 1-10 of 47

1 / 5