The Core Idea

The Jobs-to-Be-Done framework, popularized by Clayton Christensen and refined by practitioners like Bob Moesta, starts from a simple premise: customers don't buy products — they "hire" them to do a job.

The classic illustration: people buying a drill don't want a drill. They want a hole in the wall. And really, they want the picture hung. And really, they want their apartment to feel like home.

When you define products and features at the "drill" level, you miss the actual motivation driving purchase and use decisions. When you define them at the "job" level, you understand why customers choose your product, what alternatives they compare you to, and what failure looks like from their perspective.

The Job Statement Structure

A well-formed job statement describes:

• Who is trying to accomplish the goal
• What they're trying to get done (the functional job)
• When (the context or trigger)
• Why (the underlying motivation or desired outcome)

Format: "When [situation], I want to [motivation], so I can [expected outcome]."

Example: "When I need to share a project update with my client, I want to quickly generate a status summary without re-reading all the tickets, so I can maintain a professional communication without it taking an hour of my time."

This job statement tells you much more than "users want a reporting feature." It tells you the context (client communication), the friction (time spent), and the desired outcome (professional communication, fast).

Why This Changes Feature Decisions

Without JTBD: "Let's add a dashboard because users need to see their metrics."

With JTBD: "When starting my workday, I want to immediately understand what needs my attention, so I can triage my priorities in under 5 minutes."

These lead to very different designs. The first leads to a general-purpose metrics dashboard. The second leads to a prioritized action queue — possibly with no charts at all.

JTBD also helps you decide what not to build. If a feature doesn't serve any identified job that real users have, it shouldn't be on the roadmap regardless of how often it's requested. Requests are often solutions users suggest for their actual problems. Your job is to understand the problem, not just execute the requested solution.

How to Identify Jobs Through Interviews

The jobs your product serves aren't discovered through surveys or analytics — they're discovered through conversations. The interview technique for JTBD is called "timeline interviewing."

Rather than asking users what they want, walk them backward through a specific use of the product:

1. "Tell me about the last time you used [product] for [task]."
2. "What prompted you to decide to do that now? What happened right before?"
3. "What did you try before this? What didn't work about those approaches?"
4. "What would have to go wrong for you to stop using [product] for this?"

These questions reveal the trigger (what caused them to act), the context (what they were doing and why), and the competition (what they were doing before, or what they'd do if your product disappeared).

After 8–12 of these interviews, patterns in triggers and contexts will emerge. Those patterns are your jobs.

Applying JTBD to Your Roadmap

Once you've identified the top 3–5 jobs your product serves, use them to evaluate roadmap candidates:

• Does this feature help users do a current job better? (Improvement — generally worth doing if the job is high-frequency)
• Does this feature enable a new job that users currently can't do with us? (Expansion — worth doing if the new job is valuable and underserved)
• Does this feature serve no identified job? (Table stakes or speculative — deprioritize unless there's strong competitive pressure)

This framework gives you a principled way to say no to feature requests. "We hear this request, but we haven't validated that it serves a job our core users have" is a better answer than "it's not a priority right now."

The Limits of JTBD

JTBD is a lens, not a complete product methodology. It works well for defining what to build and why. It doesn't tell you how to build it, how to design the UX, or how to sequence features on the roadmap.

Combine it with user story mapping for feature sequencing, usability testing for interface design, and quantitative analytics for validating adoption. JTBD is strongest in the discovery and framing phases — before the design work starts.