Clayton Christensen vertelde meestal een verhaal over een fastfood-bedrijf dat meer milkshakes wilde verkopen. Ze ondervroegen klanten over smaakvoorkeur, zoetheidsniveaus en kopgrootte. Niets wat ze veranderden, verplaatste verkoop. Toen probeerde een onderzoeker een ander benadering: hij stond op een parkeerplaats en keek toe hoe mensen milkshakes kochten. Hij stelde één vraag — "wat probeerde je te bereiken toen je besloot om vandaag ochtend een milkshake te halen?"
Het antwoord: de meeste ochtendmilkshake-kopers hadden een lange, saaie forensingreis voor zich. Ze wilden iets dat hen bezig zou houden en niet hongerig zou laten voor lunch. De milkshake deed dat beter dan een banaan (te snel), een bagel (te rommelig), of koffie (te klein). Het product waar ze mee concurreerden, was niet andere milkshakes — het was verveling en honger.
Dat verhaal is de essentie van Jobs-to-be-Done. Mensen kopen geen producten. Ze huren ze in om een taak in hun leven uit te voeren.
In JTBD-terminologie is een "baan" de voortgang die iemand in een bepaalde omstandigheid probeert te maken. Het is geen taak ("Ik moet een bestand verzenden"). Het is geen doel ("Ik wil productiever zijn"). Het is de specifieke voortgang die een specifieke persoon in een specifieke situatie probeert te maken — met alle context, beperkingen en emoties die dat moment omringen.
De baan heeft drie componenten: een situatie (de trigger die de behoefte creëert), een motivatie (wat de persoon probeert te bereiken), en een resultaat (hun definitie van succes). Alle drie zijn belangrijk. Een product dat motivatie perfect uitvoert maar situatie negeert, zal op de verkeerde momenten worden gebruikt. Een product dat situatie perfect uitvoert maar resultaat negeert, zal worden ingehuurd en snel weer ontslagen.
Het schrijven van formele JTBD-verklaringen forceert duidelijkheid over welke baan je product eigenlijk wordt ingehuurd om uit te voeren — en onthult gaten tussen wat je denkt dat de baan is en wat gebruikers eigenlijk ervaren.
Merk op hoe elke verklaring iets onthult wat een functielijst nooit zou: de emotionele inzetten, de context van concurrerende krachten, en de definitie van succes vanuit gebruikersperspectief. Geen van deze zou naar voren komen in een enquête waarin "welke features wil je?"
Elke baan heeft drie dimensies, en producten die alleen de functionele adresseren, laten echte waarde liggen.
Slack groeide niet omdat het beter was dan e-mail bij het verzenden van berichten (functioneel). Het groeide omdat het teams voelden zich meer verbonden en levend (emotioneel) en individuen voelden zich deel van een realtime-gesprek in plaats van een inboxwachtrij (sociaal). Features die alleen de functionele baan adresseren, zijn makkelijk vermarkt. Producten die alle drie dimensies adresseren, zijn veel moeilijker te vervangen.
Het beste JTBD-onderzoek focust op het moment van inhuren — het besluit om een product te gaan gebruiken — en het moment van ontslag — het besluit om te stoppen. Beide momenten zijn rijk aan signaal.
Voor het inhuringsgesprek, vraag: "Denk terug aan het moment dat je besloot om [product] te gebruiken. Wat was er aan de hand? Wat probeerde je te bereiken? Wat probeerde je eerst?" Voor het ontslagingsgesprek: "Wanneer stopte je met het gebruik van [product]? Wat deed je voordat je besloot over te schakelen? Wat deed het alternatief anders?"
De antwoorden zullen je bijna altijd verrassen. Gebruikers zullen situaties, frustraties en motivaties beschrijven die je team nooit had verwacht. Dat is het punt. JTBD-onderzoek is geen validatieonderzoek — het is ontdekkingsonderzoek. Je test niet je aannames; je vervangt ze met bewijzen.
Zodra je de primaire taken hebt geïdentificeerd die je product wordt ingehuurd voor, gebruik je ze als filter voor elke significante productbeslissing. Voor elke voorgestelde feature, vraag: welke specifieke taak helpt dit gebruikers voortgang in te boeken? Als het antwoord "geen van onze primaire taken" is, is dat een sterk signaal om het lager prioriteit te geven — zelfs als de feature aantrekkelijk klinkt.
JTBD onthult ook waar je overservering doet. Als gebruikers een taak hebben die al goed genoeg wordt gedaan, biedt het toevoegen van meer features naar dat gebied afnemende baten — en mogelijk voegt complexiteit toe die het product moeilijker maakt voor gebruikers met verschillende taken. De takenlens toont je waar je moet investeren en waar je moet stoppen.