Master the JTBD interview as the diagnostic that distinguishes products people will pay for from products people will say nice things about and never use. The Christensen / Klement lineage; the Switch Interview; the forces of progress. The honest reframe: the user doesn't know what they want — they know what they're trying to accomplish in their life, and your job is to find that out. JTBD interviews are adversarial input testing for product hypotheses. You don't run a fuzzer hoping it confirms your code is correct; you run it hoping it surfaces the case you didn't think of. The interviews that say "actually I'd never pay for that, but I would pay for this adjacent thing you didn't propose" are the gold. The interviews that say "yeah I'd totally use that" are the noise. And this is the module where the lens itself is the named obstacle: the instinct to jump from problem to implementation — your best and fastest instinct — is exactly what leads the witness. In JTBD interviews, you are the test harness, not the implementation. Harnesses don't suggest fixes mid-test.
This course unlocks once you've finished its prerequisite. Open prerequisite →
The five JTBD interviews are the deliverable you will most want to skip, and I want to name that explicitly because the wanting-to-skip will feel reasonable in the moment — too bu…
Engineers default to "what feature should I build?" JTBD refuses that question. The shift from "what should I build" to "what is this person trying to accomplish" is uncomfortable…
Approach: Essential
Approach: Essential
Approach: Essential
Approach: Important
Applied to the same real product as M1 (continuity matters — the M1 interviews are the warm-up; these are the real thing).
7 lessons. Read in order; spiral back when you need to. By the end you'll have used the core ideas twice — once on the abstract, once on something you'll meet at work next week.