The Jobs to Be Done Interview Technique

The Jobs to Be Done interview, sometimes called a "switch interview," is a specific style of customer conversation designed to reconstruct the real story behind a purchase or a switch — what was happening right before someone decided to try a new product, what they considered, and why they ultimately chose it. Unlike a standard user interview, which might ask general questions about needs or preferences, a JTBD interview digs into one specific, real moment in detail, since that's where the true underlying "job" a customer hired the product to do actually reveals itself.

Quick facts

• The core idea comes from the Jobs to Be Done framework — customers "hire" products to make progress on a specific job in their life.
• A JTBD interview focuses on one specific, real switching moment, not general opinions or hypothetical preferences.
• The interview typically walks through a timeline: the first thought of a problem, the moment of active looking, what was considered, and the final decision.
• This technique works best for understanding why someone switched to your product from something else — including switching from doing nothing at all.
• It pairs well with, but is more specific than, general user interview technique.

Why this interview style is different from a standard interview

A standard user interview might ask broad questions like "what are your biggest challenges with X." A JTBD interview instead reconstructs one specific, real decision in careful, chronological detail — because people are much better at accurately recalling a real, specific event than at generalizing about their needs and preferences in the abstract. By walking through exactly what happened, in order, the interview surfaces the real emotional and practical triggers behind a decision, which people rarely state directly if just asked "why did you choose this."

The timeline structure of a JTBD interview

1. First thought. "When did you first think about needing something like this?" — this identifies the earliest moment the underlying problem became noticeable, even before any active searching began.
2. The trigger event. "What happened that pushed you to actually start looking for a solution?" — often a specific, identifiable moment (a particularly bad experience, a deadline, something breaking) rather than a slow, gradual realization.
3. What was considered. "What options did you look at or consider, including doing nothing?" — this reveals the real competitive set, which often includes options a company wouldn't have guessed, like a spreadsheet, a competitor, or simply continuing to struggle without a solution.
4. The decision moment. "What finally made you choose this one?" — the specific factor that tipped the decision, which is often more emotional or circumstantial than a simple feature comparison.
5. First experience. "What happened right after you started using it — did it meet what you expected?" — this reveals whether the product actually delivered on the job it was hired for, from the customer's own perspective.

A worked example of a JTBD interview in practice

Imagine interviewing a customer who recently switched to a project management tool. Instead of asking "why do you like this tool," a JTBD interview might uncover: the customer first noticed frustration months earlier when a project slipped through the cracks using shared spreadsheets (first thought). The real trigger was a specific incident — a client-facing deadline was missed because two team members thought someone else owned a task (trigger event). They briefly considered a competitor tool, and also considered just enforcing stricter spreadsheet discipline (what was considered). They ultimately chose this tool because a colleague personally recommended it and set it up for them in one afternoon, removing the effort of evaluating it themselves (decision moment). This story reveals the real job: not "manage projects" in the abstract, but specifically "make sure nothing falls through the cracks on client-facing deadlines" — a much sharper, more actionable insight than a generic feature request would have revealed.

Why this level of specificity matters

If you'd simply asked this customer "what features do you want in a project management tool," you'd likely get a generic list of common features. The JTBD interview instead revealed the emotional stakes (a client-facing failure), the real trigger (not a vague, slow realization but one specific incident), and the actual decision driver (a trusted personal recommendation, not a feature comparison) — all information that's far more useful for understanding what to build, how to market it, and even how new customers are likely to discover and adopt the product in the first place.

Common mistakes when running a JTBD interview

• Asking general, abstract questions instead of anchoring to one specific, real event. "What do you look for in a tool like this" invites a generic, less useful answer compared to "walk me through the day you decided to switch."
• Skipping the timeline structure and jumping straight to "why do you like it." The value of this technique comes specifically from the chronological reconstruction — skipping ahead loses the context that makes the answer meaningful.
• Not asking what else was considered, including doing nothing. The real competitive set is often surprising, and skipping this question misses genuinely useful competitive insight.
• Interviewing only recent, enthusiastic customers. Interviewing customers who switched away, or who seriously considered the product and chose not to buy it, often reveals equally valuable, sometimes more urgent insight.

FAQ

How is a JTBD interview different from a standard customer interview? A standard interview often asks broader, more general questions about needs and preferences. A JTBD interview specifically reconstructs one real, specific switching decision in chronological detail, which tends to reveal more accurate, less rationalized insight than general questions do.

How long does a JTBD interview typically take? Most JTBD interviews run 30-45 minutes, since walking through a full, detailed timeline of a real decision takes real time — rushing this style of interview tends to produce a much shallower, less useful result.

Can JTBD interviews be used for customers who've had your product for a long time, not just recent switchers? They work best with relatively recent decisions, since memory of specific details fades over time — interviewing someone about a switch that happened years ago tends to produce a much less accurate, more reconstructed-after-the-fact story.

Do you need a large number of JTBD interviews to find a useful pattern? Often not as many as you'd think — because each interview goes so deep into one specific story, a relatively small number of well-run JTBD interviews (often 8-12) can reveal clear, recurring patterns in the real underlying job customers are hiring the product for.