Jobs-to-be-done interviews: our exact script

Ask a customer what they want and they will tell you, confidently and specifically, and you will build it, and they will not use it. This is not because customers lie. It's because the question "what would make this product better?" invites people to play product manager — and amateur product managers, God love them, produce feature requests, not insight.

Jobs-to-be-done interviewing exists to get underneath that. The premise: people don't buy products, they hire them to make progress in a circumstance. Nobody wants a budgeting dashboard; in a specific moment of financial wobble, they hire something — a spreadsheet, an app, a shoebox of receipts, an anxious phone call to their sister — to make the wobble stop. Understand the hiring moment and the firing of the old solution, and you understand more than a hundred feature requests will ever tell you.

We run JTBD interviews at the start of nearly every product engagement, from the Brightmarsh learning platform to fintech rebuilds. This is, close to verbatim, how we do it.

Recruit for the event, not the demographic

The interview is about a moment of change, so recruit people standing in the rubble of one. Our screeners select for recency of action, not persona fit:

• Bought, switched, or abandoned a solution in the category within the last 90 days. Memory decays fast; a switch from last year gets retold as mythology.
• The decider, not a delegate. Interviewing the person who was assigned the vendor shortlist teaches you about procurement, not progress.
• A spread across outcomes: people who hired the client, people who hired a competitor, people who solved it with duct tape and haste. The duct-tape hirers are gold — they show you the job with no product mythology in the way.

Eight to twelve interviews per distinct circumstance usually saturates. If interview ten is still surfacing new hiring moments, keep going; if it's confirming, stop and spend the budget on synthesis.

The script: one purchase timeline, no opinions

The interview has one job: reconstruct the story of the switch as a timeline of events, thoughts and feelings. We explicitly ban hypotheticals ("wouldn't it be great if…") and feature talk ("what would you want in…") — politely, in the first two minutes: "I'm going to ask about what actually happened, in quite boring detail. If I ask something you have to guess at, tell me you don't remember — that's a useful answer."

Opening — anchor the event (5 min). "Take me back to when you first started using [current solution]. When was that roughly? What was going on at work at the time?" You're building a shared map you'll fill in.

First thought (10 min). The most revealing section. "When did you first realise the old way wasn't working? Not when you decided to switch — the first little crack." Probe for the trigger: a missed deadline, a boss's question they couldn't answer, a Sunday-evening dread. Push on passive energy: "You say it was frustrating — frustrating enough to do something? What did you do that day?" The gap between first thought and action — sometimes eighteen months — is where inertia, anxiety and the real switching cost live.

The search (10 min). "Walk me through what you did next." Where did they look, who did they ask, what did they google at 11pm, what did they almost hire and why not? The almost-hired solutions expose the actual competitive set — which is never the one in the client's positioning deck. For a budgeting product it's the shoebox of receipts.

The decision moment (10 min). "Describe the actual moment you committed." What were they anxious about? Who else had to say yes? "What would have had to be true for you not to switch right then?" This surfaces the push (pain of the status quo), pull (attraction of the new), anxiety (fear of the new) and habit (loyalty to the old) — the four forces, collected as story rather than a questionnaire.

First use and fitting-in (10 min). "The first week — what was harder than expected?" Where did the product have to earn its place? The distance between the purchase story and the first-use story is where onboarding and activation either close the loop or quietly start the next firing.

The questions people forget to ask

• "What did you fire?" Every hiring has a firing. Sometimes the fired solution is a product; often it's a spreadsheet, an intern, or a ritual ("every Friday I exported three reports into…"). The fired thing defines the floor the new product must beat, and it's usually embarrassingly beatable.
• "What did you expect to happen that didn't?" Expectations are the silent spec the client never wrote.
• "Who noticed you switched?" Progress is social. If nobody noticed, the outcome the product promises may not be the outcome the customer wanted.
• "If this disappeared tomorrow, what would you do Monday morning?" The honest answer to this — not "I'd be devastated", the behaviour — is your retention story in miniature.

Red flags you're hearing a pitch, not a job

Interviews fail quietly when the story turns into marketing. Our markers:

• Adjectives without events. "It was just so clunky" with no story of a specific clunky afternoon. Ask for the afternoon. If there isn't one, the frustration is borrowed.
• Suspiciously clean causality. Real switches are messy, ambivalent, half-accidental. A narrative with a villain product and a hero moment is a retelling, not a memory.
• Feature-demanding masquerading as pain. "I needed better reporting" is a solution statement. The job is behind it: needed reporting for whom, every when, to avoid what?
• The group interview. Two colleagues in one session will negotiate a shared fiction within ten minutes. One job-holder per interview, always.

From transcript to decisions

We transcribe everything, then code each interview into the timeline and the four forces — not into themes. The output is a one-page map per interview and a wall where hiring moments cluster. What we're hunting: the circumstances that repeat, phrased as jobs: "When the end of month closes in and I still can't see cash position, give me one number I can defend in the Monday meeting, so I can stop dreading Sunday."

Two disciplines keep synthesis honest. First, every clustering decision cites timestamps — if the cluster can't point at events in three separate transcripts, it's a vibe. Second, the client's team does part of the clustering with us. A founder who has personally pasted five customers' hiring moments onto a wall stops saying "users want…" and starts saying "people in the month-end crunch want…" — which is worth more than any deliverable. This is why discovery sits inside our product squads, not ahead of them, and why the wall is weekly-demo material, part of the same shipping cadence as the code.

Key takeaways

• Recruit for recency of a switch within 90 days, across people who hired you, hired a rival, and hired duct tape.
• Ban hypotheticals upfront; reconstruct one timeline: first thought, search, decision moment, first use.
• Hunt the four forces (push, pull, anxiety, habit) inside stories of specific afternoons, never as a questionnaire.
• Always ask what was fired, what was expected, who noticed, and what they'd do Monday if it vanished.
• Watch for pitch-signals: adjectives without events, clean causality, solution-shaped complaints, group interviews.
• Synthesise into clustered hiring moments with timestamp citations — and make the client cluster with you.

FAQ

How is this different from usability testing? Usability testing asks "can people operate this?" JTBD asks "why did anyone show up?" Test usability on a product that exists; run jobs interviews before the roadmap does. They answer different budgets of the same question: are we building the right operation for a real need?

Can we do these over video? Yes — our Sydney-to-London teams run most sessions on calls. What matters is transcripts and recording consent, not the room. You lose some body language and gain screen-sharing moments ("show me the spreadsheet you fired"), which are often better.

How many interviews is enough? Eight to twelve per distinct circumstance, extended until new hiring moments stop appearing. Circumstances, not personas: a part-time bookkeeper and a CFO in the same month-end crunch are the same job.

What if customers can't remember the first thought? Some can't — classic triggers look trivial in hindsight. Triangulate with bank or procurement records of the search ("what did you google?") and accept partial timelines. An honestly incomplete timeline beats a tidy fiction every time.