A customer rarely “chooses a product” because of a feature. They choose it because something in their life or work became intolerable, a better possibility appeared, and the pain of changing finally felt smaller than the pain of staying put. A jobs to be done interview reconstructs that decision—not the polished story customers tell afterward.

Why Feature-Focused Customer Interviews Fail

Most product interviews fail because they begin with the product: “What do you like?” “Which feature do you use most?” “What should we build next?” Those questions produce opinions, feature requests, and post-rationalizations—not evidence of why someone changed behavior.

People are poor witnesses of their own purchasing logic when you ask them to summarize it. Ask a customer why they bought project-management software, and they may say “better reporting.” Walk them through the week before they switched, and you may learn that their CEO publicly challenged a missed deadline, their old spreadsheet had become unmanageable, and a colleague forwarded a competitor’s template at exactly the right moment.

A jobs to be done interview focuses on the job a customer hired a product to do. The “job” is not “use a dashboard” or “manage projects.” It is the progress they sought in a particular circumstance: “Avoid being surprised in executive planning meetings” or “coordinate a product launch without becoming the team’s human status-update machine.”

I learned this working with an eight-person B2B expense-management startup. We initially asked new customers which receipt-capture features mattered most, and every answer pointed toward incremental mobile improvements. In 14 switch interviews, the real pattern was different: finance leads hired the product to make month-end close predictable without chasing employees; the receipt scanner was merely a means to that outcome. The team repositioned onboarding around close-week control, and activation among finance-led accounts rose 19% over the following quarter.

A JTBD Interview Reconstructs the Switch, Not the Customer’s Preferences

The strongest JTBD method is the switch interview, often called the timeline technique. You interview people who recently switched to your product, switched away from it, or switched from a meaningful alternative—another product, a spreadsheet, an agency, a manual workflow, or doing nothing.

Your unit of analysis is the switching event. Do not ask participants to describe their general relationship with the category. Ask them to replay a specific decision from the first moment they thought, “I need to solve this,” through adoption and early use.

The timeline usually has five moments: the first thought, passive looking, active search, decision, and consumption. The precise dates matter less than the sequence, emotional stakes, people involved, and competing options at each point.

Use a Chronological Interview Guide to Surface Real Decision Evidence

• Start with the first thought. Ask: “Take me back to when you first realized your old way of doing this was not working. What happened?” Follow with: “What made that moment different from previous frustrations?”
• Map the old solution. Ask: “Before switching, how were you handling this?” and “What did that approach cost you in time, money, risk, or stress?”
• Find the trigger. Ask: “Was there a specific event that made you decide to look for an alternative?” and “Who else noticed the problem?”
• Trace the search. Ask: “What did you look at first?” “Where did you hear about those options?” and “What made an option worth investigating further?”
• Replay the decision. Ask: “When did you decide this was the one?” “What nearly stopped you?” and “Who had to agree before you could move ahead?”
• Examine early use. Ask: “What happened in the first week after you started?” and “When did you feel confident—or uncertain—that switching had been the right call?”

Chronology is not an administrative detail. It prevents participants from skipping directly to the outcome and inventing a neat rationale. When someone says, “We wanted better analytics,” I ask, “What was happening the last time the lack of analytics caused a problem?” That follow-up turns a vague need into a scene with actors, constraints, and consequences.

Keep the guide flexible. If a participant mentions that their manager rejected a budget request, do not rush to your next scripted question. Stay with the moment: what had they proposed, what did the manager object to, what happened next, and why did that push them toward a new solution?

For recurring programs, I prefer a real-time interviewer that can follow this structure while adapting to what each participant says. Usercall’s AI-moderated interviews give researchers controls over the interview flow while probing the timeline, and its research-grade qualitative analysis makes it practical to compare switch patterns across far more conversations than a small research team can manually moderate.

The Four Forces of Progress Explain Why Customers Move—or Stay Stuck

• Push: dissatisfaction with the current solution. Ask: “What had become frustrating or risky about the old way?” “What were you no longer willing to tolerate?”
• Pull: attraction to the new solution. Ask: “What did you see or hear that made this option feel promising?” “What did you imagine would be different if it worked?”
• Anxiety: fear that the new solution will fail. Ask: “What worried you about switching?” “What did you need to believe before committing?”
• Habit: the comfort and inertia of the existing behavior. Ask: “Why had you kept doing it the old way until then?” “What would have happened if you had changed nothing?”

A switch happens only when push and pull outweigh anxiety and habit. This is where many teams make the wrong product decision. They hear a powerful pull—“your integrations looked great”—then invest more in marketing that promise, while ignoring the anxiety that blocked conversion: implementation effort, data migration, approval risk, or fear of team resistance.

In a study for an 11-person SaaS team selling scheduling software, users praised automated reminders. Yet the timeline revealed that nearly every buyer had delayed switching for months because importing historical appointments felt dangerous. The product team stopped treating migration as an edge-case support issue, built a guided import preview, and cut sales-cycle length for self-serve accounts by roughly two weeks.

Do not treat the four forces as labels to code after the fact. Use them to guide live probing. If someone names a benefit, ask what made it matter now. If they name a concern, ask how they overcame it. If they claim they “had been meaning to switch for ages,” investigate what finally broke the habit.

Recruit Recent, Genuine Switchers or Your Findings Will Be Fiction

The participant screen determines whether a jobs to be done interview produces useful evidence. Recruit people who changed behavior recently—ideally within the last 30 to 90 days for a self-serve product, or within six months for a long B2B buying cycle. Beyond that window, memory decays and customers replace messy decisions with cleaner narratives.

Do not interview loyal users who never made a real switch. A person who has used your tool for three years can explain their current workflow, but they are unlikely to recall the alternatives, tensions, and objections that shaped the original choice. Equally, someone who signed up but never completed adoption may be valuable, but they belong in a failed-conversion or churn study, not a successful-switch sample.

Screen for evidence of a real switching event

• “When did you begin using [product]?”
• “What did you use, hire, or do instead before then?”
• “Did you actively compare alternatives before choosing?”
• “What event or problem prompted you to make a change?”
• “Who was involved in the decision?”

Include switchers away from your product as well. They expose the job your product failed to complete, the anxiety you did not resolve, or the old habit your onboarding accidentally reinforced. For those conversations, use a focused version of a churn interview guide, but preserve the same chronological discipline.

If you have product analytics, recruit at meaningful behavioral moments rather than from a generic customer list. A user who exports data three times in a week, abandons a setup flow, downgrades after a team invite, or returns after 45 days of inactivity is signaling a changing job context. Usercall can place user intercepts at those moments, connecting the metric to the “why” while the participant still remembers the decision.

Turn JTBD Interviews Into Decisions About Messaging, Product, and Timing

A JTBD interview is useful only when it changes how the team acts. After each interview, capture the timeline, the old and new solutions, the trigger, and evidence for each force. Then compare interviews for repeated circumstances—not repeated feature requests.

Look for patterns such as: customers switch after a manager asks a question they cannot answer; they begin searching when a workaround consumes more than two hours per week; they choose you when a peer validates implementation; they hesitate because switching requires a cross-functional approval. Those patterns are inputs for positioning, onboarding, activation design, sales enablement, and product prioritization.

The best JTBD output is a sharply defined hiring story, not a persona. “Operations leads at 20–50 person agencies hire us after client reporting becomes a weekly scramble, because they need to deliver reliable updates without assembling data manually” is more actionable than “Busy operations manager, age 34.”

Run these interviews continuously, not as a one-off strategy workshop. The job may stay stable while triggers, alternatives, and anxieties shift with market conditions. Pair switch interviews with a broader continuous discovery interview system, and use targeted product discovery questions when you need to test how well a proposed solution fits the job.

Related: Product Discovery Interview Questions · Continuous Discovery Interviews: Building an Always-On Research System · Churn Interview Questions · The User Interview Playbook

Usercall runs AI-moderated user interviews that collect qualitative insights at scale, with the depth of a real conversation and without the overhead of a research agency. Use its researcher controls to run consistent JTBD timelines and adaptive probes, then start a free trial—Usercall is self-serve, with no sales call required.

Related methodology: The Mom Test · Win-Loss Interviews