Jobs-to-Be-Done (JTBD) Framework

Das JTBD-Framework, entwickelt von Clayton Christensen und im SaaS-Bereich von Bob Moesta populär gemacht, besagt, dass Kunden keine Produkte kaufen – sie „engagieren“ sie, um in einer bestimmten Situation Fortschritte zu erzielen. Die klassische Veranschaulichung: Ein Baumarkt verkauft keine Bohrer; er verkauft 1/4-Zoll-Löcher. Und Menschen wollen keine 1/4-Zoll-Löcher – sie wollen ein Bild aufhängen. Und sie wollen nicht nur ein Bild aufhängen – sie wollen stolz auf ihr Zuhause sein. Diese Schichtung von funktionalen, emotionalen und sozialen Dimensionen jeder Aufgabe zeigt, dass Produktentscheidungen, die sich ausschließlich auf die Feature-Funktion konzentrieren, die emotionalen und sozialen Treiber übersehen, die das Kundenverhalten und die Loyalität am stärksten beeinflussen. Angewandt auf SaaS: Kunden „nutzen kein CRM“ – sie „engagieren“ es, um „sich über meine Vertriebspipeline im Klaren zu sein und selbstbewusst in ein Prognosetreffen zu gehen“.

Product Ops integriert JTBD, indem es PMs darin schult, JTBD-Interviewtechniken in der Nutzerforschung einzusetzen. Ein JTBD-Interview konzentriert sich auf die Wechselgeschichte des Kunden – die Momente, die dazu führten, dass er eine neue Lösung suchte, das spezifische Ereignis, das die Suche auslöste („der Anstoß“), was er sich von der neuen Lösung versprach („der Sog“) und was ihn fast vom Wechsel abgehalten hätte („Ängste“). Diese Zeitleiste der Ereignisse offenbart: den spezifischen Kontext, in dem Kunden die Aufgabe erleben, die Wettbewerber, die sie in Betracht zogen (einschließlich Nicht-Konsum – nichts tun), die Faktoren, die ihre Entscheidung beeinflussten, und die Erwartungen, die sie an das neue Produkt stellten. Product Ops fasst JTBD-Erkenntnisse in einem „Forces of Progress“-Modell zusammen, das das PM-Team während der Priorisierung verwendet – um sicherzustellen, dass Features um den vollständigen Job-Kontext herum entwickelt werden, nicht nur um die funktionale Aufgabe.

Outcome-Driven Innovation (ODI), Tony Ulwicks Implementierung von JTBD, übersetzt die Theorie in ein quantitatives Priorisierungstool. ODI definiert „gewünschte Ergebnisse“ als die spezifischen Metriken, die Kunden verwenden, um den Erfolg bei ihrer Aufgabe zu bewerten – ausgedrückt in der Form „minimieren Sie die Zeit, die für [Aufgabe] benötigt wird“ oder „minimieren Sie die Wahrscheinlichkeit, dass [unerwünschte Situation] eintritt“. Kunden bewerten jedes Ergebnis nach zwei Dimensionen: Wichtigkeit (wie wichtig ist es, dass das Produkt hier hervorragend ist?) und Zufriedenheit (wie zufrieden sind sie mit der Leistung des aktuellen Produkts?). Der Opportunity Score = Wichtigkeit + max(Wichtigkeit - Zufriedenheit, 0). Hohe Wichtigkeit + geringe Zufriedenheit = hohe Opportunity. Dies gibt Product Ops eine priorisierte Liste von „unerfüllten Bedürfnissen“, die statistisch auf Kundeneingaben basiert, resistent gegenüber individuellem Kundeneinfluss ist und direkt für den Aufbau der Roadmap umsetzbar ist.