Verified against ChatGPT · 2026-08-02
Write a JTBD interview script that surfaces the job, not a feature wishlist
Builds a three-phase Jobs-to-be-Done interview script — timeline, forces of progress, desired outcome — anchored to a real past switching moment instead of the interviewee's opinion of your product.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are a Jobs-to-be-Done researcher preparing an interview script. The goal is to reconstruct the job Restaurant general managers running 15+ hourly staff across multiple shifts was trying to get done when they last switched solutions, not to collect opinions about A shift-scheduling app for restaurant managers itself. CONTEXT Product or feature under research: A shift-scheduling app for restaurant managers Target customer segment: Restaurant general managers running 15+ hourly staff across multiple shifts What's known about their switching moment, if anything: Several mentioned switching after a group-text schedule mix-up left a shift uncovered Planned interview length: 30 minutes PHASE 1 — TIMELINE (4 questions) Reconstruct the sequence of events before they started looking for something new. Ask what they were doing before, what specifically triggered the search (the struggle moment — a breaking point, not a vague dissatisfaction), and what they tried first before finding a real solution. PHASE 2 — FORCES OF PROGRESS (4 questions, one per force) Ask about the push (what was actively wrong with the old way that was pushing them away from it), the pull (what was attractive about a new solution), the anxiety (what made them hesitate to switch — cost, learning curve, fear of choosing wrong), and the habit or attachment to the status quo (what kept them using the old way despite its problems). Do not merge these into one generic "what problems did you have" question — each force surfaces something different and gets flattened if combined. PHASE 3 — DESIRED OUTCOME (3 questions) Ask what "done" looked like for them — the outcome they were hiring a solution to produce — phrased around the specific past instance from Phase 1, never as a general opinion question. INTERVIEWER DISCIPLINE Under every question, add one line stating what it's designed to surface. Flag any question that asks about the future, asks for an opinion, or asks the interviewee to evaluate A shift-scheduling app for restaurant managers directly, and rewrite it to ask about a specific past instance instead — a script this size should have zero surviving violations by the time you're done. OUTPUT FORMAT Three headed phases, questions numbered within each phase, one-line rationale directly under every question, fitting comfortably inside 30 minutes at a natural conversational pace.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
This follows the documented JTBD interviewing method built by Bob Moesta and Chris Spiek (the demand-side thinking behind Clayton Christensen's milkshake study), which reconstructs one specific past switching event in detail rather than asking for a general opinion about a category of problem. The four forces of progress — push, pull, anxiety, and habit — are the actual named framework for why people switch or stay put, and separating them into four distinct questions matters because a plain 'what problems do you have' question almost never reaches anxiety or habit; customers don't volunteer their own hesitation or inertia unprompted, since admitting 'I was scared to switch' or 'I just kept using the old way out of habit' feels like an unflattering thing to say about yourself in an interview, so it has to be asked for directly. Anchoring every question to the specific past instance identified in Phase 1 — rather than letting Phase 2 and 3 drift into hypotheticals about switching in general — is what keeps the whole script grounded in something that actually happened and can't be answered with a flattering guess about future behavior. The interviewer-discipline pass at the end catches a failure mode that's easy to introduce by accident even when the phase structure is right: a well-intentioned follow-up question like 'would a feature like X have helped?' slips in naturally mid-interview and instantly breaks the past-behavior-only rule, and because it sounds so reasonable in the moment, it's the kind of violation a researcher would miss without an explicit rewrite-or-flag check built into the script before the interview happens rather than caught afterward in a transcript nobody re-reads closely enough.
Verified against
ChatGPT GPT-5.1 · 2026-08-02
Gemini 3 Pro · 2026-07-29
Changelog
- 2026-08-02 — Initial publish, verified against ChatGPT GPT-5.1 and Gemini 3 Pro.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
