Jobs to Be Done is a research framework that focuses on the outcome a user is trying to achieve — the "job" they're hiring your product to do — rather than the features they interact with along the way. The core idea: people don't buy a quarter-inch drill because they want a drill. They buy it because they want a quarter-inch hole.
Most teams default to labeling things the way they built them. Your database has a "Gantt chart" feature, so that's what you call it in the nav. The problem: about half your users have no idea what a Gantt chart is, and the other half know but don't think of it that way when they're mid-task.
A project management app ran into exactly this. Their card sort using feature-based labels — "Gantt Chart," "Kanban Board," "Resource Allocation" — produced messy results. Agreement rates hovered around 40-55% for most cards. Users were sorting based on vague guesses about what these terms meant.
The team then ran 10 JTBD interviews, asking users to walk through the last time they needed to coordinate work across their team. The jobs that emerged were concrete: "track progress on active work," "figure out who's available next week," "see if we're going to hit the deadline." They rewrote their card labels to match this language and re-ran the sort.
Agreement rates jumped to 65-80% across the board. "Track project progress" landed cleanly under a single category. "Check team availability" did too. The information architecture that emerged from the second sort was structurally different — organized around workflows instead of tool types.
A JTBD interview is a structured conversation about a specific recent experience, not a wish list exercise. You're asking someone to reconstruct the last time they needed to accomplish something, in detail.
The key questions center on the timeline: What triggered the need? What did you try first? What did you switch to? What would "done" look like? You're listening for the functional job (the practical outcome), the emotional job (how they want to feel), and the social job (how they want to be perceived).
Plan for 30-45 minutes per interview. Eight to twelve interviews typically reach saturation for a single product area — you'll start hearing the same 4-6 core jobs by interview 7 or 8.
One thing JTBD interviews do poorly: they don't tell you about jobs people don't know they have. The framework is retrospective by design, so it captures existing behavior well but won't surface latent needs. Pair it with observational research if you're exploring a new problem space.
Once you have your job statements, they feed directly into card sort design in two ways:
Card labels: Rewrite cards using the verb phrases from your interviews. "Track project progress" instead of "Gantt Chart." "Get paid faster" instead of "Invoice Management." This takes 30 minutes and dramatically improves sort quality.
Card selection: Jobs that came up in every interview belong in your sort. Jobs that appeared once or twice probably don't need top-level navigation — they might be better as secondary content. This filtering keeps your card count between 20 and 40, which is the range where card sorting works best.
The job hierarchy also gives you a head start on expected categories. If multiple cards relate to the same parent job ("manage my money"), that cluster will likely emerge as a category in your open sort — and if it doesn't, that's an interesting finding worth investigating.
How is JTBD different from user personas? Personas describe who your users are — demographics, behaviors, goals. JTBD describes what they're trying to accomplish in a specific situation, regardless of who they are. A CEO and an intern might share the same job-to-be-done ("get a status update to my team quickly") despite being radically different personas. JTBD and personas complement each other: personas tell you who to recruit, JTBD tells you what to design for.
How does JTBD improve card sorting studies? JTBD interviews reveal the language users actually use when describing their goals, which makes for better card labels. Instead of labeling a card with a feature name like "Gantt Chart," you'd use the job language — "Track project progress." Cards written in job language consistently produce higher agreement rates because they match how users think about tasks rather than how your product organizes features.
How many JTBD interviews should you conduct before a card sort? Plan for 8-12 JTBD interviews to reach saturation for a single product area. You'll hear the same core jobs repeated after 6-8 interviews, with the remaining sessions confirming patterns and catching edge cases. Each interview runs 30-45 minutes and should focus on a recent real situation where the participant needed to accomplish something, not hypotheticals.
Explore related concepts, comparisons, and guides