Jobs To Be Done: Volledige gids voor productmanagers
Het idee dat gebruikers een product 'inhuren' klinkt in eerste instantie misschien een beetje vreemd. Hierdoor heb je misschien zelfs gedacht dat het zogenaamde raamwerk voor te verrichten taken niet meer is dan een soort in-grap voor productmanagers.
In werkelijkheid zijn te verrichten taken (ook bekend als jobs-to-be-done, JTBD of de theorie van te verrichten taken) niet alleen iets wat echt bestaat, maar vormen ze ook een van de meest effectieve en impactvolle raamwerken die je kunt gebruiken om je producten te ontwikkelen.
Als senior productmanager met praktische ervaring met het toepassen van de JTBD-theorie, kan ik je uit eigen ervaring vertellen: leren hoe je deze fascinerende methodologie gebruikt, zal je manier van denken over je product volledig veranderen.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Principes van de theorie van te verrichten taken
Voordat ik de structuur van dit raamwerk bekijk en je uitleg hoe je het gebruikt, wil ik je eerst kennis laten maken met de belangrijkste ideeën en principes erachter. Zo help ik je de essentie van dit raamwerk te begrijpen, in plaats van je alleen de implementatiestappen uit het hoofd te laten leren.
Veteranen uit de product- en managementwereld beweren dat de eerste “manier van denken” achter JTBD teruggaat tot de jaren 60, toen de beroemde professor van Harvard Business School en marketingwetenschapper Theodore Levitt het concept van “gewenste resultaten” introduceerde en deze beroemde zin uitsprak:
De genialiteit van deze manier van denken zit in de manier waarop je productontwikkeling begint te benaderen.
Spotify wilde de muziekindustrie betreden. In plaats van een marktplaats te creëren waar ze nummers zouden verkopen (net als iTunes destijds), beseften ze echter dat mensen muziek wilden kunnen beluisteren, niet dat ze die moesten kunnen kopen.
Daardoor hadden ze de vrijheid om iets te bouwen dat fundamenteel anders (en beter) was dan muziekwinkels: een streamingdienst die een duurzaam bedrijfsmodel in balans bracht met het gewenste resultaat van hun gebruikers: naar muziek luisteren.
Sinds het ontstaan ervan in de jaren 60 heeft de benadering waarbij gewenste resultaten prioriteit krijgen zich aanzienlijk ontwikkeld. Veel beroemde managementexperts en wetenschappers hebben hierop hun eigen raamwerken en “filosofieën” gebaseerd.
Enkele van de belangrijkste mijlpalen waren:
Clayton Christensens idee van disruptieve innovatie dat hij introduceerde in zijn boek "Het dilemma van de innovator." Clayton merkte op dat elke innovatie die de wereld verandert, begint met het vervullen van de behoeften van een kleine groep klanten (ook wel eerste gebruikers genoemd). Vervolgens wordt de oplossing verbeterd om ook in de aanvullende behoeften van grotere groepen laatkomende gebruikers te kunnen voorzien.
Het centrale punt van deze structuur van “beginnen in een niche en vervolgens uitbreiden” was het vermogen van oprichters en productmanagers om de behoeften en gewenste resultaten van nichegebruikers correct te identificeren en vervolgens hetzelfde te doen voor het bredere publiek.
Bob Moesta’s benadering waarbij de worsteling centraal staat die hij beschreef in zijn boek "Verkoop aan de vraagzijde 101: stop met verkopen en help je klanten vooruitgang te boeken," Bob stelt dat klanten voortdurend proberen vooruitgang te boeken in hun leven (of dat nu financieel is, met betrekking tot relaties of iets anders) en dat ze op die weg met talloze problemen worden geconfronteerd. Goede productleiders zijn in staat deze problemen te zien en producten aan te bieden die gebruikers kunnen “inhuren” om deze problemen voor hen op te lossen.
Tony Ulwicks raamwerk voor resultaatgerichte innovatie (ODI) (hier vind je een goed artikel van Harvard Business Review hierover). Volgens Tony zijn de uiteindelijke resultaten die klanten met jouw product willen bereiken de belangrijkste factor die hun besluitvorming aanstuurt.
Het idee is dat klanten, wanneer ze kunnen kiezen uit meerdere concurrerende producten, uiteindelijk kiezen voor het product dat hen het best helpt hun gewenste resultaten te bereiken.
Hoe werkt JTBD?
Met al deze ideeën en raamwerken in gedachten komen we uiteindelijk uit bij JTBD. Er bestaan verschillende interpretaties van de JTBD-theorie (die allemaal heel goed zijn), maar persoonlijk geef ik de voorkeur aan Tonys versie, die hij beschrijft in zijn boek “Te verrichten taken: van theorie naar praktijk.”
Volgens hem moeten klanten een “taak” uitvoeren waarmee ze hun gewenste resultaat kunnen bereiken. Ze kunnen deze taak via verschillende paden en oplossingen uitvoeren, waaronder door producten te “inhuren” die de taak voor hen kunnen uitvoeren.
Als we dit concept visualiseren, ziet het er als volgt uit:
Het startpunt voor je klanten is de niet-ideale huidige situatie die hen niet tevreden stelt. Voor een thuiswerkende medewerker van de klantenservice is deze huidige situatie bijvoorbeeld haar woonkamer, waar ze haar werk meestal doet omdat haar appartement geen speciaal thuiskantoor heeft.
Waarom is dit een niet-ideale huidige situatie? Omdat ze door al het achtergrondgeluid van haar hond, kinderen en buren bang is dat ze tijdens haar supportgesprekken met klanten onprofessioneel klinkt.
Ze heeft dus de gewenste uitkomst dat ze supportgesprekken zonder achtergrondgeluid kan voeren.
Om dit te bereiken, moet ze haar huidige situatie veranderen en vooruitgang boeken richting haar gewenste uitkomst door het achtergrondgeluid te verminderen. Dit is een taak die ze moet volbrengen.
Een manier is om iedereen uit de woonkamer te houden, maar dat is gedurende een volledige werkdag een lastige opgave in een klein appartement. Een andere manier is om haar appartement te verlaten en te verhuizen naar een appartement met een geluiddichte werkruimte, maar dat is arbeidsintensief, stressvol en brengt veel langetermijnkosten met zich mee. Tot slot kan ze ervoor kiezen om software voor ruisonderdrukking in te huren, zodat al het geluid in realtime wordt verwijderd.
Gezien de kosten van de alternatieve oplossingen zou ze maar wat graag een dozijn dollar per maand betalen voor zo'n dienst!
De software voor ruisonderdrukking heeft haar taak om achtergrondgeluiden uit haar gesprekken te verwijderen dus met succes volbracht en haar geholpen de gewenste uitkomst te bereiken: gesprekken voeren zonder afleiding.
De wetten van JTBD
In zijn definitie van het JTBD-framework op de website van zijn adviesbureau Strategyn noemt Tony een aantal interessante “feiten” over deze taken die ons kunnen helpen de essentie van JTBD verder te begrijpen.
- Een taak blijft hetzelfde naarmate de tijd verstrijkt. Vroeger huurden mensen notulisten in om tijdens vergaderingen aantekeningen voor hen te maken. Nu huren ze in plaats daarvan AI-hulpmiddelen voor samenvattingen in. Verschillende oplossingen, dezelfde taak.
- Taken zijn “oplossingsonafhankelijk”. Dit betekent dat klanten verschillende soorten oplossingen kunnen inhuren om dezelfde taak uit te voeren. Het betekent ook dat je product er niet hetzelfde uit hoeft te zien als wat je concurrenten aanbieden om de taak goed uit te voeren.
- De beste oplossing krijgt altijd de taak. Als er concurrentie is, is de winnaar het product dat de taak beter, sneller of goedkoper uitvoert (of een combinatie van deze drie).
- Mensen willen één oplossing voor één taak. Klanten geven de voorkeur aan producten die de volledige taak van begin tot eind kunnen uitvoeren en vermijden situaties waarin ze meerdere producten moeten inhuren om de taak af te handelen.
Kort samengevat steunt het Jobs To Be Done-framework op het idee dat mensen uiteindelijk niet zozeer de hulpmiddelen willen die ze gebruiken, maar de uiteindelijke uitkomsten.
Ze vinden het proces echter wel belangrijk. Om hen te helpen hun einddoelen te bereiken, moeten ze bepaalde taken (of jobs) volbrengen en zijn ze bereid iemand of iets (een dienst of software) in te huren om deze taken voor hen uit te voeren.
Door deze taken te identificeren en je producten erop af te stemmen zodat ze deze naadloos uitvoeren, vergroot je de kans dat mensen voor je product betalen en het blijvend gebruiken.
Hoe je het JTBD-framework gebruikt bij je dagelijkse productontwikkeling
Hopelijk is het duidelijk waarom het zo belangrijk is om de essentie van het JTBD-framework te begrijpen voordat je leert hoe je het gebruikt, want de volgende stappen zijn in die context veel logischer.
Wat ik met je ga delen is niet de “standaardversie” van JTBD (waarover je kunt lezen in de vele hierboven genoemde boeken).
In plaats daarvan wil ik de variant van JTBD met je delen die ik in de praktijk met succes voor een aantal van mijn producten heb gebruikt.
Hier is een Jobs to Be Done-voorbeeld uit mijn eigen professionele ervaring.
Inzicht krijgen in de behoeften en gewenste uitkomsten van de klant
De kern van elk succesvol product is goed uitgevoerd gebruikersonderzoek. Gezien hoe sterk JTBD leunt op het idee dat “mensen uitkomsten willen, geen hulpmiddelen”, moet je altijd beginnen met het identificeren van je gebruikers en ontdekken wat ze willen.
Ik heb geen specifieke manier om dit onderzoek uit te voeren die speciaal op JTBD is afgestemd. In plaats daarvan hebben mijn productteam en ik vertrouwd op onze traditionele methoden en hulpmiddelen om meer over gebruikers te leren. Het enige verschil was dat we onze vragen richtten op het ontdekken van de uiteindelijke uitkomst die onze gebruikers wilden bereiken.
Laat me een voorbeeld delen van de webpushmeldingsdienst waaraan we werkten.
Opmerking: met deze tool kunnen websites pushmeldingen naar hun bezoekers sturen. Het was een nieuw, lucratief marketingkanaal dat websites konden gebruiken om hun producten te promoten.
Om de gebruikerspersona's voor deze dienst te ontwikkelen, interviewden we mensen die de producten van onze directe en indirecte concurrenten hadden gebruikt. Wanneer je een gebruiker van een concurrent interviewt, stel je traditioneel vragen zoals deze:
Hoewel we deze vragen ook tijdens onze interviews stelden, lag onze belangrijkste focus op het verkrijgen van antwoorden op deze vragen:
En er was een goede reden waarom we zowel directe (bijv. OneSignal en iZooto) als indirecte (bijv. Mailchimp en Twilio) concurrenten interviewden. We vermeldden eerder dat taken en gewenste resultaten niet afhankelijk zijn van een specifieke oplossing. Dit betekende dat de antwoorden die we over het resultaat zouden krijgen hetzelfde (of op zijn minst vergelijkbaar) zouden zijn, ongeacht welk hulpmiddel onze geïnterviewden gebruikten.
Dat is precies wat we kregen. Blijkbaar was het meest voorkomende gewenste resultaat voor onze doelmarkt (op dat moment waren dat e-commercewinkels) het verminderen van het aantal zogenaamde “verlaten winkelwagens”—wanneer mensen producten aan hun winkelwagen toevoegen en deze daar dagen of weken laten staan.
De taak die zowel e-mail- als webpushmeldingsdiensten voor hen uitvoerden, was gebruikers herinneren aan de verlaten winkelwagen en een korting aanbieden als ze terugkwamen en de aankoop deden.
Hier besloten we ons uiteindelijk op te richten en we bouwden een product dat dit beter kon dan wie dan ook.
Het voorbeeld dat ik hierboven gaf, ging over gebruikersinterviews, maar dat is niet de enige manier om te ontdekken wat je klanten willen. Je kunt ook overwegen om het volgende te doen:
- Marktonderzoek, samen met het bepalen van verschillende klantsegmenten en demografische kenmerken.
- Enquêtes onder gebruikers, die je kunt uitvoeren met behulp van onze samengestelde lijst met enquêtevragen.
- Interviews in focusgroepen, waarbij je een geselecteerde groep mensen uitnodigt om hun behoeften en ervaringen met je te bespreken.
Maar ongeacht welk type klantonderzoek je uitvoert, onthoud altijd dat je prioriteit moet geven aan de vragen die de uiteindelijke resultaten blootleggen die je klanten willen bereiken.
De taakverklaring formuleren
Op basis van alle inzichten die je uit onze interviews en enquêtes hebt verzameld, zou je een redelijk goed inzicht moeten hebben in zowel de resultaten die je gebruikers willen bereiken als de taken die ze gewoonlijk uitvoeren om die resultaten te bereiken.
Nu is het tijd om deze inzichten concreet te maken door het belangrijkste resultaat van de JTBD-methodologie te formuleren: een taakverklaring. Zo ziet die eruit:
Dit format voor het beschrijven van resultaten en taken is erg nuttig, omdat het cruciale informatie bevat, zoals:
- De situatie en de omgeving waarin de klant een probleem ervaart. In ons geval waren dat mensen die hun winkelwagens achterlieten.
- De taak die onze klant moet uitvoeren om het gewenste resultaat te bereiken. Voor eigenaren van e-commercewinkels ging het om het versturen van herinneringsberichten naar degenen die hun winkelwagens hadden achtergelaten.
- De emotionele en rationele reden achter de wens van de klant om het resultaat te bereiken. Als mensen producten aan hun winkelwagens toevoegen en dit vergeten, betekent dit voor onze klanten verloren potentiële omzet en hebben zij een rationele reden om deze gevallen te verminderen.
- Tot slot hebben we het gewenste resultaat. In dit voorbeeld wilden winkeleigenaren afrekenen met deze verlaten winkelwagens.
Je hebt misschien gemerkt dat we de term “herinneringsberichten” gebruikten in plaats van “herinnerings-e-mails” voor pushmeldingen. De reden is dat het onze klanten niet echt uitmaakte via welk fysiek kanaal dit bericht werd verzonden, zolang het verlatingspercentage er maar succesvol door daalde.
Een taakmap maken
Het documenteren van veel van de uitspraken over de te vervullen taken en gewenste resultaten van je klanten is op zichzelf al een prestatie. Maar het is slechts de helft van het werk, want je moet deze taken omzetten in een degelijke waardepropositie, nieuwe productvereisten (inclusief een roadmap) en een gebruikerservaring.
Hiervoor kunnen we gebruikmaken van een ander JTBD-resultaat: de taakmap.
De taakmap is de visuele weergave van de volledige reis die je klanten moeten afleggen om hun taak succesvol te voltooien. Deze dient als tussenstap tussen je taakomschrijvingen en de klantreis of productvereisten die je aan je engineeringteam overdraagt.
Hieronder zie je een voorbeeldsjabloon van een taakmap die door GitLab is ontwikkeld.
De bovenstaande structuur is bedacht door Tony Ulwick, die voorstelde om deze te gebruiken voor het in kaart brengen van taken binnen zijn raamwerk voor resultaatgerichte innovatie.
Laat me dit nu voor je invullen aan de hand van het voorbeeld van Spotify en de taak: “Een klant maakt een persoonlijke afspeellijst voor zijn specifieke stemming.”
- Definiëren: Gebruikers begrijpen dat ze een gepersonaliseerde afspeellijst nodig hebben die is afgestemd op hun stemming.
- Lokaliseren: Ze vinden de functie voor het maken van een afspeellijst en navigeren daarheen.
- Voorbereiden: Gebruikers zoeken de nummers die ze aan de afspeellijst willen toevoegen en selecteren deze.
- Bevestigen: Ze controleren de afspeellijst om er zeker van te zijn dat alle nummers die ze voor hun stemming wilden hebben erin staan.
- Uitvoeren: Gebruikers slaan de afspeellijst op en geven deze een naam.
- Monitoren: Ze bekijken statistieken zoals het aantal streams en likes om de populariteit van hun afspeellijst te beoordelen.
- Aanpassen: Gebruikers verwerken de feedback van anderen in hun afspeellijsten door nummers toe te voegen of te verwijderen.
- Voltooien: Wanneer ze de stemming ervaren waarvoor deze afspeellijst is gemaakt, zetten gebruikers de afspeellijst aan en genieten ze van de muziek.
Afhankelijk van de taak die je in kaart wilt brengen, kun je overwegen sommige stappen hier weg te laten als je vindt dat gebruikers voor die stap geen concrete handeling hoeven uit te voeren.
Een oplossing creëren die mensen voor die taak zullen inhuren
Ten slotte zijn we aangekomen op het punt waarop je met behulp van je dagelijkse software voor productmanagement je reguliere productmanagementresultaten kunt creëren, zoals PRD's, ontwerpen, gebruikersverhalen en meer.
Je beschikt al over de lijst met stappen die je gebruikers zetten om in hun onvervulde behoeften te voorzien. Het enige wat je nu nog hoeft te doen, is functies creëren die de noodzakelijke handelingen voor elke stap ondersteunen.
Voor de stap “voorbereiden” van de hierboven beschreven specifieke taak moet je bijvoorbeeld een functie ontwikkelen waarmee je gebruikers naar nummers kunnen zoeken, de afspeellijsten van andere gebruikers kunnen filteren en deze nummers aan hun eigen afspeellijst kunnen toevoegen.
Vergeet naast het ontwikkelen van functies die je taken ondersteunen ook de meer “administratieve” functies niet, zoals je prijsstelling en betalingslogica, je klantervaring met betrekking tot het beheren van hun gegevens en account, en hun mogelijkheid om ondersteuning te krijgen.
Alles draait om het inhuren van je product
Het raamwerk Jobs To Be Done is uitzonderlijk en biedt een bijzondere manier van denken, omdat het je helpt je inspanningen te richten op functies die je product aantrekkelijker maken voor gebruikers die jou willen inhuren om hun taken voor hen uit te voeren.
Of je nu bij een startup of een technologiegigant werkt (zoals Intercom of Microsoft), ik verzeker je dat JTBD je helpt de impact van je productmanagementwerk te vergroten. Als je mijn gedachten over JTBD met plezier hebt gelezen, abonneer je dan op onze nieuwsbrief om vergelijkbare inhoud in je inbox te ontvangen.
