Jobs-to-be-Done (JTBD) Skill — Uncovering Customers’ Jobs, Pain Points, and Gains

Skill Overview

The jobs-to-be-done skill provides a structured JTBD analysis framework. It examines three types of jobs—functional, social, and emotional—to systematically identify what customers “hire” your product to accomplish, along with the underlying pain points and desired gains. This helps you uncover genuinely unmet needs. Each analysis takes approximately 20–30 minutes.

Use Cases

1. Customer requests don’t align with the roadmap: Customers keep asking for features that don’t seem worth building. Use this skill to move beyond the feature level, identify what they are truly trying to accomplish, and then decide how to respond instead of directly adding their wish list to the backlog.
2. Product repositioning: Analyze why users switch from an existing solution and uncover the unmet needs behind that behavior, so the new positioning is grounded in real motivations. The solution customers “hire” is often an invisible competitor such as a spreadsheet, pen and paper, or something similar.
3. Turning scattered feedback into structured insights: Have a pile of interview notes and support tickets filled with fragmented information? Use this skill to organize vague feedback into clear customer jobs, pain points, and gains, providing a structured basis for product decisions.

Core Features

1. Breakdown of the three types of customer jobs: Reconstruct customer motivations across three dimensions: functional jobs (what they want to accomplish), social jobs (how they want to be perceived and by whom), and emotional jobs (what emotions they want to experience or avoid). This prevents mistaking a solution such as “use Slack” for the job itself.
2. Four-dimensional pain-point assessment: Examine, in sequence, obstacles and challenges; time, money, and effort costs; preventable common errors; and problems left unresolved by existing solutions. This ensures pain points are identified comprehensively and distinguishes severe pain from minor discomfort rather than listing a few items based on intuition.
3. Gain identification and prioritization: Cover four categories of gains—expectations, savings, adoption drivers, and quality-of-life improvements—and rank them by pain-point intensity. Distinguish between “must-haves” and “nice-to-haves,” so the results can be used directly for roadmap prioritization and product messaging.

Frequently Asked Questions

What is the difference between JTBD and user personas?

Personas answer “Who is the user?” JTBD answers “In what situation does the user want to accomplish what, and why?” For example, “Millennials prefer mobile devices” is a persona characteristic, not a job; “Complete account reconciliation before filing taxes” is a job. The two can be used together: personas define the research subjects, while JTBD reveals their motivations. This skill also recommends cross-validating with personas, since the jobs, pain points, and gains of different personas may vary significantly.

Can I run the analysis without interview data?

Yes, but the conclusions will only be hypotheses. The skill explicitly identifies “filling in the template without research support” as an anti-pattern. It recommends supplementing the inputs first by conducting switching interviews—asking users why they switched from their previous solution—organizing support tickets, or directly providing existing interview summaries as analysis material. JTBD is responsible for forming hypotheses; quantitative research and data are responsible for validating them. Neither can replace the other.

How can the analysis results be put into practice? What are its limitations?

The output ranks items by pain-point intensity and distinguishes between “must-have” and “nice-to-have” gains. It can be used directly for three purposes: prioritizing the roadmap by addressing the most severe pain points first, writing positioning copy that focuses on jobs rather than features, and creating a list of hypotheses to validate. Keep its limitations in mind: a single analysis takes approximately 20–30 minutes and is best suited to early-stage needs discovery and product repositioning. Fine-tuning features in an established product does not justify running the full analysis. Conclusions should be confirmed through broader research or data before committing development resources.