Conducting JTBD Customer Interviews

Conduct JTBD customer interviews that reconstruct a real switch, from first thought to first use, to surface the job, its forces and outcomes.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

JTBD customer interviews reconstruct a decision a customer actually made: the moment they hired a new solution or fired an old one. The best-known form is the switch interview developed by Bob Moesta and Chris Spiek, which walks the customer back along the timeline of a purchase and listens for the forces that moved them (jobstobedone.org). Their live mattress interview, later referenced in Christensen's book Competing Against Luck, is a good model of the style (the mattress interview).

In the Jobs-to-be-Done (JTBD) Framework, these interviews do three jobs. They test and correct the draft job statement. They supply the steps and struggles for the job map. And they provide the customer's vocabulary for outcome statements, which later go into a survey. Switch interviews come from the Christensen and Moesta school, and ODI practitioners also run interviews to capture outcomes. This skill uses the switch format because recent, concrete decisions produce the most reliable detail.

A JTBD interview is neither a feature-request session nor a satisfaction survey. You are not asking what customers want. You are asking what happened: when they first thought something had to change, what they tried, what made them act, what they compared and what almost stopped them. People are poor at explaining their reasons in the abstract and much better at recalling a specific day, place and conversation.

The output of each interview is a written timeline, a note of the four forces with quotes, the job in the customer's words and any outcomes, emotional jobs and social jobs you heard. Across a set of interviews, these become the evidence for the job statement, the job map and the outcome list.

How It Works

The timeline gives the conversation a structure. Moesta and Spiek describe the stages as first thought, passive looking, a first event that raises the energy, active looking, a second event that forces the decision, and then purchase and consumption (JTBD timeline). Each stage answers a different question:

• First thought: what changed that made the current way feel inadequate?
• Passive looking: what did they notice without searching, and where?
• First event: what turned background dissatisfaction into a search?
• Active looking: what options did they compare, and on what criteria?
• Second event: what made them decide at that moment rather than later?
• Purchase and consumption: what did they expect, and what happened when they started using it?

The four forces explain why the switch happened. Push is the problem with the current situation. Pull is the attraction of the new solution. Anxiety is the fear about the new choice, and habit is the comfort of the present way (four forces). A switch happens when push and pull outweigh anxiety and habit. During the interview, the forces work as a diagnostic: if a customer describes a strong push and a strong pull but took a long time to switch, there is an anxiety or habit you have not heard yet.

The interviewer does not follow the timeline in order. The timeline page recommends bouncing around it, jumping back from a purchase detail to fill a gap earlier on, and notes that first thoughts often happen further back than people first report (JTBD timeline). Concrete detail unlocks memory: the day of the week, who else was there, what the weather was, what they were doing just before.

Two rules from the mattress interview matter most. "Reconstruct the timeline before you ask about the product," and "espoused behavior is not real behavior": when a customer starts theorizing about what they would do, bring them back to what they did (the mattress interview).

Recruiting decides the quality of the data. Interview people who made the decision recently enough to remember it, and include people who switched to a competitor or to a workaround, not only your own new customers.

Step-by-Step Guide

Step 1: Define the switching event

Write down the decision you want to study, such as moving from spreadsheets to a dedicated tool, or cancelling a subscription. Name the job executor and, for business products, the buyer if they differ. Decide what counts as recent enough for good recall. A precise event makes recruiting and comparison across interviews possible.

Step 2: Recruit people who made that decision

Screen for people who made the switch recently, and for who made the decision. Include switches to competitors, to manual workarounds and to doing nothing, since each shows a different balance of forces. Avoid people who are only considering a change, because they can only speculate. Offer a fair incentive and book enough time for a relaxed conversation.

Step 3: Prepare a light guide

Write an opening that explains you want to understand their story, not to sell or test anything. List the timeline stages and the four forces as prompts rather than a script. Add a few openers, such as "When did you first realize the old way wasn't working?" Plan to record, with permission, so you can listen rather than take notes.

Step 4: Start at the purchase and work backward

Begin with the moment they bought or signed up, which is usually the clearest memory. Ask where they were, what they did just before and who else was involved. Then move backward to the events that led there and forward to first use. Fill gaps by asking for specifics: dates, places, people and exact words.

Step 5: Probe the four forces

For each part of the story, ask what was pushing them away from the old way and what drew them to the new one. Ask what worried them about switching and what they missed or kept doing from before. When the forces do not explain the timing, look for the missing anxiety or habit. Record quotes, since their exact words will feed outcome statements.

Step 6: Capture the job, criteria and outcomes

Near the end, ask what they were ultimately trying to get done and how they judge whether it is going well. Note the criteria they used to compare options and the struggles they described at each step of the job. Write down emotional and social jobs separately, such as wanting to look competent to a manager. These notes become input to Writing Desired Outcome Statements.

Step 7: Write up each interview the same day

Turn the recording into a one-page timeline, a forces summary with quotes and a list of job, outcome and emotional notes. Do it while the conversation is fresh, since detail fades quickly. Use the same template for every interview so they can be compared. Flag anything that contradicts the draft job statement or job map.

Step 8: Synthesize across interviews

Lay the timelines side by side and look for repeated triggers, forces and criteria. Group interviews that share a pattern, and note where patterns diverge, since divergence may point to different segments. Stop scheduling interviews when new ones stop changing the job map and outcome list. Update the job statement and map with what you learned.

Best Practices

• Interview people who switched away from your product as well as to it. Churned customers show the forces your product lost to, which new customers cannot.
• Pair interviewers, with one asking and one listening for gaps in the timeline and the forces. The listener often catches the missing anxiety that explains a long delay.
• Ask for the last specific instance, not the usual pattern. "Tell me about the last time you did this" produces events. "How do you usually do this" produces a summary that hides the struggles.
• Treat what customers say they would do as a lead, not as data (the mattress interview). Follow it back to something they did.
• Keep emotional and social jobs in their own notes (Christensen Institute). They matter for positioning and onboarding, and mixing them into functional outcomes muddies the survey.

Common Mistakes

• Asking about features: "Would you use X?" invites speculation and politeness. Ask what happened the last time they faced the problem, and let features come up on their own.
• Recruiting people who have not decided: Prospects who are still considering can only guess at their forces. Recruit people who have made the switch, in either direction.
• Stopping at the first answer: The first reason a customer gives is usually a tidy summary. Ask what happened just before, who else was involved and what they did next until the story has concrete detail.
• Hearing only push and pull: Teams listen for the pain and the attraction because those support their product. Ask directly about worries and old habits, which often explain slow or failed switches (four forces).
• Leaving synthesis for later: Unwritten interviews lose detail within days, and a pile of recordings rarely gets analyzed. Write each one up the same day.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Jobs-to-be-Done (JTBD) Framework

Related Skills

• Defining the Customer's Core Functional Job
• Creating Job Maps
• Writing Desired Outcome Statements

Sources

• jobstobedone.org: The JTBD Timeline
• jobstobedone.org: The Four Forces of Progress
• jobstobedone.org: The Mattress Interview
• Christensen Institute: Jobs to Be Done

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.