Jobs-to-Be-Done Interview vs User Interview: Key Differences

Most product teams conflate these two research methods, and it costs them. They schedule what they call “user interviews” but then probe into the underlying job the customer is trying to accomplish—and vice versa. The result is muddled insights that lead to features nobody asked for and products that miss the point entirely. Understanding what separates a Jobs-to-Be-Done interview from a traditional user interview isn’t academic hair-splitting. It’s the difference between building something people actually want and building something they say they like in a survey.

This guide breaks down each method, clarifies where they overlap, and shows you exactly when to use which.

What Is a Jobs-to-Be-Done Interview?

A Jobs-to-Be-Done (JTBD) interview is a qualitative research method designed to uncover the underlying functional, emotional, and social “jobs” that customers hire a product or service to accomplish. The framework, popularized by Clayton Christensen’s work and refined by practitioners like Alan Klement and Bob Moesta, treats customer behavior as hiring a solution to get a job done.

In practice, a JTBD interview is structured around a specific formulation: “When [situation arises], I want to [motivation], so I can [expected outcome].” The interviewer focuses relentlessly on the progress the customer is trying to make in their life—not the features of your product, not their opinion of your interface, but the underlying struggle that prompted them to seek a solution in the first place.

The key characteristic that distinguishes JTBD interviews is their forward-looking, progress-oriented framing. You’re not asking what the customer dislikes about current solutions. You’re asking what they’re trying to achieve and what’s standing in the way of that progress. The famous “milk” example from Clayton Christensen illustrates this: people don’t actually want milk—they want a breakfast experience that feels complete. The milk is just the vessel they currently use.

In a JTBD interview, you’ll hear questions like:

• What prompted you to start looking for a solution?
• What other solutions have you tried, and what were you hoping each would do that the others didn’t?
• What does a successful outcome look like to you—describe the moment when you’d feel like you made the right choice?
• What are you unable to do right now that you wish you could do?

The goal is to map the hiring criteria—the specific outcomes that would make your product the right choice—and to understand the forces that push customers toward change (the “pushes”) and the ones that hold them back (the “habits,” “fears,” and “risks”).

What Is a User Interview?

A user interview is a broader category of qualitative research that encompasses conversations with people who use—or might use—a product, feature, or service. Unlike the narrowly scoped JTBD interview, a user interview can serve many purposes: understanding current behaviors, uncovering pain points, gathering feedback on existing designs, testing usability, or exploring attitudes and preferences.

User interviews typically fall into two buckets. The first is generative or discovery user interviews, conducted early in product development to understand the problem space. The second is evaluative user interviews, conducted later to test whether a solution actually works for its intended audience. Both are valuable, but they ask different questions and yield different insights.

In a traditional user interview, the conversation tends to orbit the product or category directly. You’ll hear questions like:

• How do you currently solve this problem?
• What are the biggest frustrations with your current approach?
• Walk me through the last time you used [product/category].
• What would make this product better?
• How would you describe this feature to a friend?

The interviewer is looking for pain points, workarounds, unmet needs, and satisfaction levels. The lens is often retrospective—understanding what happened—and focused on the customer’s relationship with existing solutions or the category as they understand it.

This is not a flaw. User interviews are excellent for validating assumptions, identifying usability issues, and gathering the kind of granular behavioral data that informs incremental improvements. The risk comes when teams treat user interviews as a substitute for the deeper, job-focused discovery that precedes product strategy.

Key Differences Between JTBD Interviews and User Interviews

Understanding the structural differences between these methods matters more than memorizing their definitions. Here’s where they diverge:

Core Focus: JTBD interviews focus on the progress the customer is trying to make. User interviews focus on the customer’s relationship with existing solutions.

Question Orientation: JTBD interviews are forward-looking—”what are you trying to achieve?” User interviews are backward-looking—”what have you done or used?”

Timing: JTBD interviews typically happen before a solution exists. User interviews can be before, during, or after product development.

Outcome: A JTBD interview gives you a map of hiring criteria and the forces of progress. A user interview gives you a catalog of pain points, behaviors, and preferences.

Language Used: JTBD interviews use job statements and progress metaphors. User interviews use language about needs, frustrations, features, and usability.

Product Dependency: JTBD interviews abstract from specific products initially. User interviews often reference specific products or categories.

Here’s a concrete example of the difference in practice. Suppose you’re building project management software. In a user interview, a prospect might say: “I hate jumping between Trello and Slack. It’s annoying that I can’t see everything in one place.” That’s a pain point—valuable, but tied to specific tools and specific frustration.

In a JTBD interview exploring the same conversation, you’d push past that: “What would being able to see everything in one place let you accomplish that you can’t do now?” The answer might reveal something unexpected—like the real job isn’t organization at all, but the need to feel confident that nothing’s falling through the cracks before stepping into a client meeting. The job is peace of mind, not task management. That’s a fundamentally different insight, and it leads to different product decisions.

The most important distinction is this: a user interview tells you what customers dislike about the current landscape. A JTBD interview tells you what they’re ultimately trying to achieve—and whether your product is positioned to be the instrument of that progress.

When to Use a Jobs-to-Be-Done Interview

You should use a JTBD interview when you’re exploring a new market, considering a new product category, or trying to understand why customers choose one solution over another when multiple options exist. It’s the right tool when you need to define what “success” means from the customer’s perspective before you build anything.

Specifically, JTBD interviews shine in these scenarios:

Entering an unfamiliar market. Before you know what features to build, you need to know what job people are hiring solutions to accomplish. A JTBD interview helps you avoid the common trap of copying competitors’ features without understanding why those features exist in the first place.

Designing a new product category. If you’re creating something that doesn’t have obvious competitors, user interviews tend to yield “I don’t know” responses because people can’t compare to what they haven’t used. JTBD interviews work better here because they focus on the underlying struggle, not the current solutions.

Understanding competitive displacement. Why do customers switch from one solution to another? The answer almost never lives in feature comparisons. It lives in the job they were trying to get done and the moment when the old solution stopped serving that job. JTBD interviews are purpose-built for mapping these forces.

Reframing your value proposition. If your product is struggling to land with customers, the issue is often that you’re describing features instead of articulating the job you’ve been hired to do. JTBD interviews give you the language to reframe your positioning around the actual progress you’re enabling.

The honest caveat: JTBD interviews require more skill to conduct well. The framework is deceptively simple—ask about progress, not products—but it takes practice to resist the pull of product-focused follow-up questions. If your team hasn’t been trained on the methodology, you’ll get weaker results than a well-executed user interview.

When to Use a User Interview

User interviews are the workhorse of product research, and you should use them liberally. They’re the right choice when you need to understand how people interact with existing solutions, validate that your product works as intended, or gather feedback on specific designs or features.

Specifically, user interviews are ideal for:

Usability testing. Watching someone try to accomplish a task with your product—whether it’s a prototype or a live feature—reveals friction that self-reported data misses. The famous quote from Thomas Gilovich (“we are pretty accurate at reporting what we do but terrible at reporting how we feel”) captures why watching behavior matters more than asking about it.

Gathering feedback on specific concepts. Once you have a concrete idea, user interviews let you test whether it resonates. “Here’s a mockup—would you use this?” yields messy but useful data, especially when combined with probing on what specifically appeals or doesn’t.

Understanding category habits. If you’re building in an established category, user interviews help you map the landscape: what tools do people use, how do they use them, what do they love, what do they tolerate? This is essential context for differentiation.

Iterating on existing products. For incremental improvements, bug fixes, or feature additions, user interviews give you direct access to the people who will use what you’re building. They’re faster to conduct and easier to synthesize than the more abstract JTBD framework.

One thing many articles on this topic get wrong: user interviews and JTBD interviews aren’t rivals. They’re sequential. The most effective research programs use JTBD interviews early to discover what jobs need to be done, then layer in user interviews to validate solutions against those jobs. Skipping the JTBD phase and jumping straight to user interviews is like designing a house before understanding what the inhabitants need. You might build something impressive, but it’ll be the wrong shape.

How to Conduct a Jobs-to-Be-Done Interview

The mechanics of a JTBD interview aren’t complicated, but the discipline to stay in the right frame is where most teams struggle. Here’s what the process looks like in practice:

Recruit for the job, not the demographic. You’re not looking for “product managers who use Slack.” You’re looking for people who are trying to make progress on a specific job—”stay informed about what my team is working on without micromanaging them.” The job, not the persona, is your recruitment criterion.

Start with the situation, not the product. Open with context: “Tell me about the last time you were in a situation where you needed to [general description of the job].” Avoid mentioning your product or any competitors in the opening. You want to hear how people describe the problem in their own language.

Map the hiring chain. People don’t just hire one product to accomplish a job—they layer solutions. Someone trying to “feel more confident in meetings” might hire a calendar app, a note-taking tool, and a presentation tool. Understanding this chain reveals where your product fits and where the competition lives.

Probe for the forces of progress. This is where JTBD gets its power. Push past surface answers to understand: What pushed them to look for a new solution? (The push) What did they try before, and what was missing? (Failed hires) What would have to be true for them to make a change? (The anxieties and habits that hold them back)

Land on the moment of truth. Ask them to describe the moment when they knew they’d made the right choice—or the moment when they felt they’d made a mistake. This reveals the criteria that actually matter, not the ones they tell you in surveys.

A practical note: you need to conduct at least 10 to 15 JTBD interviews before the pattern recognition kicks in. With fewer, you’re often hearing individual quirks rather than universal job dimensions. This is more investment than a quick user interview, but the strategic insight it unlocks is proportionally greater.

Common Mistakes to Avoid

The biggest mistake I see teams make is running what they call a “JTBD interview” but then asking product-focused questions throughout. They begin with the right framing—”Tell me about a time you needed to organize your work”—but then slip into “What tools do you use?” and “What do you like about them?” The result is a user interview dressed up in JTBD language.

The second mistake is applying JTBD to the wrong stage. Trying to uncover abstract jobs when you have a live product and specific feedback to gather is a waste. The framework is for discovery, not validation. Use it to find the mountain, not to map the trail up it.

The third mistake is treating JTBD as a magic wand. It reveals the job, but it doesn’t tell you which job to pursue or how to win at it. The framework gives you direction; you still need strategy, design, and execution to convert insight into product-market fit.

Conclusion

The choice between a JTBD interview and a user interview isn’t about which method is better. It’s about which method answers the question you’re actually asking. If you’re trying to discover what progress people need and why current solutions fail them, invest in the structured discipline of a Jobs-to-Be-Done interview. If you’re trying to validate whether your solution works or gather feedback on specific interactions, run a user interview.

The trap to avoid is treating these as interchangeable. Most teams default to user interviews because they’re familiar, and then wonder why their roadmap feels reactive instead of strategic. The JTBD framework forces you to slow down and ask what jobs actually matter—uncomfortable, but necessary work that pays dividends in product clarity.

Where I’d push you to think further: even after you identify the job, you face a strategic decision that JTBD doesn’t answer. Which job should you pursue? The one with the most demand, or the one where you have the best chance of being hired? That question sits at the intersection of jobs research, competitive positioning, and business strategy—and it’s where the real product leadership work begins.