Jobs To Be Done: Vollständiger Leitfaden für Produktmanager
Die Vorstellung, dass Nutzer ein Produkt „anheuern“, mag zunächst etwas seltsam klingen. Vielleicht hast du deshalb sogar gedacht, dass das sogenannte Jobs To Be Done-Framework so etwas wie ein Insiderwitz für Produktmanager ist.
In Wirklichkeit ist Jobs to be Done (auch bekannt als jobs-to-be-done, JTBD oder Jobs-Theorie) nicht nur real, sondern auch eines der effektivsten und wirkungsvollsten Frameworks, die du für die Produktentwicklung nutzen kannst.
Als Senior Product Manager mit praktischer Erfahrung in der Anwendung der JTBD-Theorie kann ich dir sagen: Wenn du lernst, wie man diese faszinierende Methodik einsetzt, wird sich deine Denkweise über dein Produkt komplett verändern.
Du willst mehr vom The CPO Club?
Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:
Have an account? Log In
Grundprinzipien der Jobs To Be Done-Theorie
Bevor ich auf den Aufbau dieses Frameworks eingehe und dir erkläre, wie du es nutzen kannst, möchte ich dir zunächst die grundlegenden Ideen und Prinzipien dahinter vorstellen, damit du das Wesen dieses Frameworks wirklich verstehst (und nicht nur die Umsetzungsschritte auswendig lernst).
Erfahrene Produkt- und Management-Experten behaupten, dass die erste „Denkweise“ hinter JTBD bereits in die 1960er Jahre zurückreicht, als der berühmte Harvard Business School-Professor und Marketingwissenschaftler Theodore Levitt das Konzept der „erwünschten Ergebnisse“ vorstellte und diesen berühmten Satz prägte:
Die Genialität dieser Denkweise zeigt sich darin, wie man an die Produktentwicklung herangeht.
Spotify wollte in die Musikbranche einsteigen. Anstatt jedoch – wie damals iTunes – einen Marktplatz zu schaffen, auf dem sie Songs verkauften, erkannten sie, dass die Menschen Musik hören wollten und nicht primär daran interessiert waren, Musik zu kaufen.
Dadurch konnten sie etwas grundlegend anderes (und besseres) als Musikläden entwickeln – einen Streaming-Dienst, der ein nachhaltiges Geschäftsmodell mit dem gewünschten Ergebnis der Nutzer – Musik zu hören – vereinte.
Seit ihren Ursprüngen in den 60ern hat sich der Ansatz, erwünschte Ergebnisse zu priorisieren, deutlich weiterentwickelt. Viele bekannte Management-Experten und Wissenschaftler haben darauf aufbauend eigene Frameworks und „Philosophien“ entwickelt.
Zu den wichtigsten Meilensteinen gehören:
Clayton Christensens Idee der disruptiven Innovation, die er in seinem Buch "The Innovator's Dilemma" geprägt hat. Clayton stellte fest, dass jede weltverändernde Innovation zunächst die Bedürfnisse einer kleinen Kundengruppe (auch Early Adopters genannt) abdeckt und dann die Lösung verbessert, um die zusätzlichen Bedürfnisse einer größeren Masse späterer Nutzer zu erfüllen.
Der zentrale Punkt dieser „Nischenstart-und-dann-Erweiterung“-Struktur war die Fähigkeit der Gründer und Produktmanager, die Bedürfnisse und erwünschten Ergebnisse der Nischennutzer richtig zu identifizieren und dann das Gleiche für die breitere Zielgruppe umzusetzen.
Bob Moestas „Struggle-First“-Ansatz, den er in seinem Buch "Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress" beschreibt. Bob argumentiert darin, dass Kunden ständig versuchen, in ihrem Leben Fortschritte zu machen (ob finanziell, beziehungsbezogen oder in anderen Bereichen) und auf diesem Weg zahlreichen Herausforderungen begegnen. Großartige Produktmanager erkennen diese Herausforderungen und bieten den Nutzern Produkte an, die sie „anheuern“ können, um diese Herausforderungen für sie zu bewältigen.
Tony Ulwicks Outcome-driven Innovation (ODI)-Framework (hier ein lesenswerter Harvard Business Review-Artikel dazu). Laut Tony ist der entscheidende Faktor im Entscheidungsprozess der Kunden die gewünschten Ergebnisse, die sie durch die Nutzung deines Produkts erreichen möchten.
Die Grundidee ist, dass bei mehreren konkurrierenden Produkten die Kunden das auswählen, das ihnen am besten dabei hilft, ihre gewünschten Ergebnisse zu erreichen.
Wie funktioniert JTBD?
Mit all diesen Ideen und Frameworks im Hinterkopf kommen wir schließlich zu JTBD. Es gibt verschiedene Interpretationen der JTBD-Theorie (alle sind ziemlich gut), aber ich persönlich bevorzuge Tonys Version, die er in seinem Buch "Jobs to be Done: Theory to Practice" beschreibt.
Laut ihm müssen Kunden eine „Aufgabe“ erfüllen, die ihnen ermöglicht, ihr gewünschtes Ergebnis zu erreichen. Sie können diese Aufgabe auf verschiedenen Wegen und mit unterschiedlichen Lösungen erledigen, unter anderem indem sie Produkte „anheuern“, die diese Aufgabe für sie übernehmen.
Wenn wir dieses Konzept visualisieren, sieht das folgendermaßen aus:
Der Ausgangspunkt für Ihre Kunden ist der nicht-ideale aktuelle Zustand, der sie nicht zufriedenstellt. Zum Beispiel ist für eine im Homeoffice arbeitende Kundendienstmitarbeiterin ihr derzeitiger Zustand das Wohnzimmer, in dem sie üblicherweise arbeitet, da ihre Wohnung kein separates Arbeitszimmer hat.
Warum ist das ein nicht-idealer aktueller Zustand? Nun, wegen des ganzen Hintergrundlärms, den sie durch ihren Hund, Kinder und Nachbarn bekommt, befürchtet sie, bei ihren Supportanrufen mit Kunden unprofessionell zu wirken.
Sie hat also das gewünschte Ergebnis, störungsfreie Supportanrufe führen zu können.
Um dies zu erreichen, muss sie ihren aktuellen Zustand verändern und Fortschritte in Richtung ihres gewünschten Ergebnisses machen, indem sie den Hintergrundlärm reduziert. Das ist eine Aufgabe, die sie erledigen muss.
Eine Möglichkeit ist, alle anderen aus dem Wohnzimmer fernzuhalten – das ist aber für einen gesamten Arbeitstag in einer kleinen Wohnung kaum machbar. Eine andere Möglichkeit wäre, aus ihrer Wohnung auszuziehen und in eine mit schallisoliertem Büro zu ziehen – das ist jedoch aufwendig, stressig und bringt hohe langfristige Kosten mit sich. Schließlich gibt es die Option, eine Geräuschunterdrückungssoftware zu nutzen, die alle Geräusche in Echtzeit eliminiert.
Angesichts der Kosten der alternativen Lösungen wäre sie mehr als glücklich, jeden Monat ein paar Euro für diesen Service zu zahlen!
So hat die Geräuschunterdrückungssoftware erfolgreich ihre Aufgabe erfüllt, Hintergrundgeräusche aus ihren Anrufen zu entfernen, und ihr geholfen, das gewünschte Ergebnis — störungsfreie Anrufe — zu erreichen.
Die Gesetze von JTBD
In seiner Definition des JTBD-Frameworks auf seiner Beratungswebsite Strategyn bringt Tony einige interessante „Fakten“ über diese Aufgaben zur Sprache, die uns helfen, das Wesen von JTBD besser zu verstehen.
- Eine Aufgabe bleibt über die Zeit hinweg bestehen. Früher haben Menschen Protokollanten beauftragt, während Sitzungen Notizen zu machen. Heute nutzen sie stattdessen KI-Zusammenfassungstools. Unterschiedliche Lösungen, gleiche Aufgabe.
- Aufgaben sind „lösungsagnostisch“. Das bedeutet, dass Kunden verschiedene Arten von Lösungen beauftragen können, um dieselbe Aufgabe zu erledigen. Es bedeutet auch, dass Ihr Produkt nicht so aussehen muss wie das Ihrer Wettbewerber, um die Aufgabe gut zu erledigen.
- Die beste Lösung bekommt immer den Auftrag. Gibt es Konkurrenz, setzt sich das Produkt durch, das die Aufgabe besser, schneller oder günstiger erledigt (oder durch eine Kombination dieser drei Faktoren).
- Menschen wollen eine Einzellösung für eine Einzelaufgabe. Kunden bevorzugen Produkte, die die komplette Aufgabe von Anfang bis Ende abdecken können und vermeiden Situationen, in denen für eine Aufgabe mehrere Produkte nötig sind.
Zusammenfassend basiert das Jobs To Be Done Framework auf der Idee, dass Menschen letztlich die Ergebnisse wollen, nicht die Werkzeuge, mit denen sie diese erreichen.
Sie kümmern sich jedoch durchaus um den Prozess. Um ihre Ziele zu erreichen, müssen sie bestimmte Aufgaben (oder Jobs) erledigen und sind bereit, jemanden oder etwas (einen Service oder eine Software) zu engagieren, damit diese Aufgaben für sie übernommen werden.
Wenn Sie diese Aufgaben identifizieren und Ihre Produkte so gestalten, dass sie diese reibungslos erfüllen, erhöhen Sie die Wahrscheinlichkeit, dass Menschen für Ihr Produkt bezahlen und es langfristig nutzen.
Wie Sie das JTBD-Framework im täglichen Produktentwicklungsprozess einsetzen
Hoffentlich ist jetzt deutlich, wie wichtig es ist, das Wesen des JTBD-Frameworks zu verstehen, bevor man lernt, wie man es einsetzt, da die folgenden Schritte im Kontext deutlich mehr Sinn ergeben.
Was ich Ihnen gleich zeige, ist nicht die „Standard“-Version von JTBD (mehr dazu in den oben genannten Büchern).
Stattdessen möchte ich die JTBD-Variante teilen, die ich persönlich bei einigen meiner Produkte erfolgreich eingesetzt habe.
Hier ist ein Beispiel für Jobs to Be Done aus meiner eigenen Berufspraxis.
Erfahren, was Kunden brauchen und welches Ergebnis sie sich wünschen
Das Herzstück jedes erfolgreichen Produkts ist eine gründliche Nutzerforschung. Gerade weil JTBD maßgeblich auf dem Prinzip „Menschen wollen Ergebnisse, keine Werkzeuge“ beruht, sollten Sie immer damit beginnen, Ihre Nutzer zu identifizieren und herauszufinden, was sie wollen.
Ich habe keine spezielle, „JTBD-spezifische“ Methode für diese Recherche. Stattdessen haben mein Produktteam und ich auf unsere bewährten Methoden und auf Tools zur Nutzerforschung gesetzt. Der einzige Unterschied war, dass wir unsere Fragen gezielt darauf ausgerichtet haben, das letztliche Ziel unserer Nutzer zu erfassen.
Lassen Sie mich ein Beispiel geben zu dem Web-Push-Benachrichtigungsservice, an dem wir gearbeitet haben.
Hinweis: Dieses Tool ermöglicht es Websites, Push-Benachrichtigungen an ihre Besucher zu senden. Es war ein neuer, lukrativer Marketingkanal, mit dem Websites für ihre Produkte werben konnten.
Um die Nutzer-Personas für diesen Service zu entwickeln, haben wir Menschen interviewt, die die Produkte unserer direkten und indirekten Wettbewerber genutzt haben. Bei der Befragung eines Wettbewerber-Nutzers würde man traditionell Fragen wie diese stellen:
Obwohl wir diese Fragen auch während unserer Interviews gestellt haben, lag unser Hauptaugenmerk darauf, Antworten auf diese Fragen zu bekommen:
Und es gab einen guten Grund, warum wir sowohl direkte (z.B. OneSignal und iZooto) als auch indirekte (z.B. Mailchimp und Twilio) Wettbewerber interviewten. Wie zuvor erwähnt, sind Aufgaben und gewünschte Ergebnisse lösungsunabhängig. Das bedeutete, dass die Antworten, die wir auf das gewünschte Ergebnis bekamen, unabhängig davon, welches Tool die Interviewten nutzten, gleich (oder zumindest ähnlich) ausfielen.
Und genau das haben wir erhalten. Offenbar war das am häufigsten gewünschte Ergebnis für unseren Zielmarkt (zu diesem Zeitpunkt waren es Online-Shops), die Anzahl der sogenannten „abgebrochenen Warenkörbe“ zu verringern – also wenn Leute Produkte in den Warenkorb legen und sie dort tagelang oder wochenlang liegen lassen.
Die Aufgabe, die sowohl E-Mail- als auch Web-Push-Benachrichtigungsdienste für diese Shops erfüllten, bestand darin, Nutzer an den abgebrochenen Warenkorb zu erinnern und ihnen einen Rabatt anzubieten, falls sie zurückkommen und den Kauf abschließen.
Genau darauf haben wir uns am Ende konzentriert und ein Produkt entwickelt, das das besser konnte als alle anderen.
Das oben erwähnte Beispiel bezog sich auf Nutzerinterviews, aber das ist nicht der einzige Weg, um herauszufinden, was Ihre Kunden wirklich wollen. Sie können außerdem Folgendes in Betracht ziehen:
- Marktforschung zusammen mit der Festlegung verschiedener Kundensegmente und demografischer Merkmale.
- Nutzerumfragen, die Sie mithilfe unserer kuratierten Fragen für Produktfeedback-Umfragen durchführen können.
- Fokusgruppen-Interviews, bei denen Sie eine ausgewählte Gruppe von Personen einladen, um ihre Bedürfnisse und Erfahrungen mit Ihnen zu diskutieren.
Doch egal, welche Form der Kundenerforschung Sie durchführen: Denken Sie immer daran, die Fragen zu priorisieren, die das finale, gewünschte Ergebnis Ihrer Kunden aufdecken.
Formulierung der Job-Description
Als Ergebnis aller Erkenntnisse, die Sie aus den Interviews und Umfragen gewonnen haben, sollten Sie ein ziemlich gutes Verständnis sowohl der gewünschten Ergebnisse Ihrer Nutzer als auch der Aufgaben, die sie dafür üblicherweise ausführen, haben.
Jetzt ist es an der Zeit, diese Erkenntnisse zu nutzen und das Hauptprodukt der JTBD-Methodik zu formulieren – eine Job-Description. So sieht das aus:
Dieses Format, um Aufgaben und Ergebnisse zu beschreiben, ist sehr hilfreich, da es wichtige Informationen enthält, wie beispielsweise:
- Die Situation und das Umfeld, in dem der Kunde ein Problem hat. In unserem Fall waren es Personen, die ihren Warenkorb verlassen haben.
- Die Aufgabe, die der Kunde erledigen muss, um sein Ziel zu erreichen. Für Online-Shop-Betreiber war dies das Versenden von Erinnerungsnachrichten an jene, die ihren Warenkorb stehen lassen.
- Der emotionale und rationale Grund, warum der Kunde dieses Ergebnis erzielen will. Wenn Leute Produkte im Warenkorb vergessen, ist das potenziell verlorener Umsatz. Es gibt also einen guten, rationalen Grund, diese Fälle zu verringern.
- Zuletzt das gewünschte Ergebnis. In diesem Beispiel wollten Ladenbesitzer die abgebrochenen Warenkörbe beseitigen.
Sie haben vielleicht gemerkt, dass wir den Begriff „Erinnerungsnachricht“ statt „Erinnerungs-E-Mail“ für Push-Benachrichtigungen gewählt haben. Der Grund ist, dass es unseren Kunden eigentlich egal war, über welchen Kanal die Nachricht verschickt wird – solange sie die Abbruchrate senkt.
Erstellung einer Job Map
Die Dokumentation vieler der zu erledigenden Aufgaben und Ergebnisformulierungen Ihrer Kunden ist bereits eine beachtliche Leistung. Das ist jedoch nur die halbe Miete, denn Sie müssen diese Aufgaben in ein überzeugendes Wertversprechen, neue Produktanforderungen (einschließlich eines Fahrplans) und eine ansprechende Nutzererfahrung überführen.
Dafür können wir ein weiteres JTBD-Ergebnis nutzen – die Job Map.
Die Job Map ist die visuelle Darstellung der gesamten Reise, die Ihre Kunden durchlaufen müssen, um ihre Aufgabe erfolgreich zu bewältigen. Sie dient als Zwischenschritt zwischen Ihren Job-Formulierungen und der Customer Journey Map oder den Produktanforderungen, die Sie an Ihr Technikteam weitergeben.
Hier ein Beispiel-Template einer Job Map, entwickelt von GitLab.
Die oben gezeigte Struktur stammt von Tony Ulwich, der sie zur Abbildung von Jobs in seinem Outcome-driven Innovation Framework vorgeschlagen hat.
Nun fülle ich das gerne am Beispiel Spotify aus und der Aufgabe: „Kunde erstellt eine individuelle Playlist für seine spezielle Stimmung“.
- Definieren: Nutzer erkennen, dass sie eine personalisierte Playlist basierend auf ihrer Stimmung brauchen.
- Lokalisieren: Sie finden die Funktion zur Playlist-Erstellung und navigieren dorthin.
- Vorbereiten: Nutzer suchen nach und wählen die Songs aus, die sie in die Playlist aufnehmen möchten.
- Bestätigen: Sie überprüfen die Playlist, um sicherzugehen, dass alle gewünschten Songs enthalten sind, passend zur Stimmung.
- Ausführen: Die Nutzer speichern die Playlist und geben ihr einen Namen.
- Überwachen: Sie betrachten Kennzahlen wie die Anzahl der Streams und Likes, um die Beliebtheit ihrer Playlist einzuschätzen.
- Anpassen: Nutzer greifen das Feedback anderer auf und passen ihre Playlists durch Hinzufügen oder Entfernen von Songs an.
- Abschließen: Wenn sie die Stimmung erleben, für die die Playlist gedacht ist, schalten die Nutzer sie ein und genießen die Musik.
Abhängig von der Aufgabe, die Sie abbilden möchten, können Sie überlegen, einige der hier genannten Schritte wegzulassen, wenn es für diesen Schritt keine sinnvolle Nutzerhandlung gibt.
Eine Lösung schaffen, die Menschen für diese Aufgabe engagieren möchten
Nun sind wir an dem Punkt angelangt, an dem Sie Ihre üblichen Produktmanagement-Ergebnisse wie PRDs, Designs, User Stories und mehr mit Ihrer täglichen Software für Produktmanagement erstellen können.
Sie haben bereits die Liste der Schritte, die Ihre Nutzer unternehmen, um ihre unerfüllten Bedürfnisse abzudecken. Alles, was Sie noch tun müssen, ist, Funktionen zu entwickeln, die die erforderlichen Aktionen der Nutzer für jeden Schritt abdecken.
Für den Schritt „Vorbereiten“ in der obigen konkreten Aufgabe müssten Sie zum Beispiel eine Funktion bereitstellen, mit der Ihre Nutzer nach Songs suchen, Playlists anderer Nutzer filtern sowie diese Songs in die eigene Playlist übernehmen können.
Neben der Entwicklung von Funktionen für die eigentlichen Aufgaben sollten Sie auch an die eher „administrativen“ Aspekte denken – wie Ihre Preisgestaltung und Zahlungslogik, das Nutzererlebnis beim Verwalten von Daten und Konto sowie die Möglichkeit, Support in Anspruch zu nehmen.
Es geht darum, Ihr Produkt „engagierbar“ zu machen
Jobs To Be Done ist ein außergewöhnliches Denkmodell und eine hervorragende Methode, denn damit richten Sie Ihre Bemühungen auf Funktionen aus, die Ihr Produkt für Nutzer attraktiver machen, die Sie mit der Bewältigung ihrer Aufgaben beauftragen möchten.
Ganz gleich, ob Sie in einem Startup oder einem Tech-Giganten (wie Intercom oder Microsoft) arbeiten – ich versichere Ihnen: JTBD wird Ihnen helfen, die Wirkung Ihrer Produktmanagement-Arbeit zu steigern. Wenn Ihnen meine Gedanken zu JTBD gefallen haben, abonnieren Sie gern unseren Newsletter, um ähnliche Inhalte direkt in Ihr Postfach zu bekommen.
