Was ist Jobs to be Done (JTBD)?

Was ist JTBD

Jobs to be Done, kurz JTBD, sucht den Grund für eine Kaufentscheidung in der Situation, in der sich die Person befindet. Die Person „stellt“ ein Produkt „ein“, um eine Aufgabe in ihrem Leben zu erledigen.

Das Christensen Institute beschreibt den Job als den Fortschritt, den ein Mensch unter bestimmten Umständen zu machen versucht. Laut Institut stecken in jedem Job funktionale, soziale und emotionale Kräfte. Das Beispiel auf der Website ist jemand, der für seine wachsende Familie ein Haus kauft. Platz und Größe sind die funktionale Seite. Beziehungen in der Familie und die Nachbarn sind die soziale, das Gefühl, für die Familie zu sorgen und etwas zu erreichen, die emotionale Seite.

Im Deutschen wird meist der englische Begriff verwendet. Ich nutze auf dieser Seite die Abkürzung, weil sie in Teams am häufigsten fällt.

Christensen und der HBR-Artikel

Einer der Texte, die das Thema einem breiten Publikum bekannt machten, erschien in der Septemberausgabe 2016 der Harvard Business Review: „Know Your Customers' Jobs to Be Done“. Die Autoren sind Clayton M. Christensen, Taddy Hall, Karen Dillon und David S. Duncan.

Der Artikel beginnt mit der Feststellung, dass Innovation für Führungskräfte zugleich oberste Priorität und größte Enttäuschung ist. In der eingangs zitierten Umfrage von McKinsey hielten 84 % der Führungskräfte Innovation für äußerst wichtig für ihre Wachstumsstrategie. 94 % waren mit der Innovationsleistung ihres Unternehmens unzufrieden.

Die These im Untertitel ist klar: Wenn Sie verstehen, warum Kunden eine Wahl treffen, ist Innovation kein Glücksspiel mehr. Der ganze Artikel ist nur mit Abo lesbar. Das Milchshake-Beispiel unten zitiere ich deshalb aus einem frei zugänglichen Text der Harvard Business School.

Das Milchshake-Beispiel

Carmen Nobel erzählte 2011 bei HBS Working Knowledge Christensens Milchshake-Beispiel. Eine Fast-Food-Kette wollte mehr Milchshakes verkaufen.

Zuerst teilte die Kette den Markt nach Produkt und nach dem demografischen Profil des typischen Milchshake-Trinkers ein. Menschen mit diesem Profil fragte sie, wie der ideale Milchshake sein müsste. Der Umsatz stieg nicht.

Dann verbrachte einer von Christensens Forschungskollegen einen ganzen Tag in einem Restaurant. Er notierte, wer wann einen Milchshake kaufte und ob er ihn vor Ort trank. 40 Prozent der Milchshakes wurden frühmorgens gekauft, zum Mitnehmen.

Am nächsten Morgen stellte der Forscher den Kunden, die mit einem Milchshake hinausgingen, eine Frage: Für welchen Job hatten sie dieses Getränk eingestellt? Die meisten hatten einen langen, langweiligen Weg zur Arbeit vor sich. Sie wollten etwas, das eine Hand beschäftigt, die Fahrt etwas auflockert und sie bis mittags satt hält.

Sie hatten es eilig und waren in Arbeitskleidung unterwegs. Höchstens eine Hand war frei. Der Milchshake schlug bei diesem Job Bagel und Donut, weil das Trinken durch den Strohhalm die Fahrt füllte und satt machte.

Laut Nobel hätte die Kette mit einem passenden Produkt antworten können: einem dickeren Morgen-Milchshake mit Fruchtstücken. Für mich lautet die Lehre: Der Konkurrent war nicht ein anderer Milchshake, sondern alles, was man im Auto mit einer Hand essen kann.

Wie man eine Job Story schreibt

Ein Job Statement beschreibt den Job in einem Satz. Tony Ulwick von Strategyn definiert den Job als einzelnen, lösungsunabhängigen Satz. Sein Beispiel: „ein Stück Holz in einer geraden Linie schneiden“.

In diesem Satz kommen weder Säge noch Laser vor. Ulwicks Begründung ist kurz: „Jobs are stable; products are not.“ Jobs bleiben, Produkte ändern sich.

Die Form der Job Story

Die Form, die ich in Produktteams am häufigsten sehe, ist die Job Story. Mike Cohn schreibt, dass sie bei Intercom entstand und dass Alan Klement sie am besten erklärt. Die Vorlage hat drei Teile:

• Situation (When): der Moment und der Kontext, in dem der Job beginnt.
• Motivation (I want to): was die Person in diesem Moment tun will.
• Erwartetes Ergebnis (so I can): das Ergebnis, das sie eigentlich erreichen will.

Auf Deutsch baue ich sie so: „Wenn …, möchte ich …, damit …“. Eines von Cohns Beispielen betrifft Bestellungen: eine Warnung sehen, wenn eine Bestellung abgeschickt wurde, damit man dieselbe Bestellung nicht noch einmal abschickt.

Was NN/g ergänzt

Page Laubheimer von NN/g empfiehlt, den Job als einen Satz plus wichtigen Kontext zu schreiben. Ihm zufolge enthält ein gutes Job Statement auch Erfolgskriterien. Funktionale Kriterien beschreiben, ob der Job erledigt ist, emotionale die persönlichen und sozialen Anliegen.

Ich ergänze das Job Statement oft um eine weitere Zeile. Die Frage lautet: „Wie erledigt die Person diesen Job heute?“ Die Antwort ist manchmal ein Konkurrenzprodukt, manchmal eine WhatsApp-Gruppe.

Job-Story-Generator

Job Story

Wenn ich auf dem Heimweg merke, dass zu Hause nichts zu essen da ist, möchte ich das Abendessen sichern, bevor ich ankomme, damit ich nicht noch einmal aus dem Haus muss.

Das ist eine Beispiel-Job-Story. Mit JavaScript können Sie die Felder selbst ausfüllen und den Satz prüfen.

Die drei Beispiele und die Liste der Lösungswörter sind von mir erfundene Beispiele. Was Sie schreiben, wird nirgendwohin gesendet.

Job-Story-Generator: baut aus Situation, Motivation und erwartetem Ergebnis einen einzigen Satz. Beispiel 3 enthält absichtlich einen Lösungsnamen; die Prüfung erkennt ihn. Die Wortliste ist kurz und erfunden und findet nicht jeden Lösungsnamen.

Die Prüfliste ist klein, aber der Fehler, den sie findet, ist verbreitet. Ein Satz, der mit „Wenn ich die App öffne“ beginnt, beschreibt einen Bildschirm, nicht einen Job. Was hat die Person erlebt, bevor sie die App geöffnet hat? Das gehört ins Feld Situation.

JTBD und Persona

Manche Teams setzen JTBD an die Stelle der Persona. Ein frühes Beispiel dieser Debatte ist Klements Text. Klement kritisierte Personas 2013 im Intercom-Blog als erfundene Kunden, die über Merkmale ohne Ursachen beschrieben werden.

Laubheimers NN/g-Artikel von 2017 sieht beide als Werkzeuge, die sich ergänzen. Ihm zufolge entsteht diese Kritik, wenn man die Persona für ein demografisches Profil hält. Eine gute Persona beschreibt auch Ziele, Motivationen, Verhalten und Einstellungen.

Zwei von Laubheimers Beobachtungen finde ich in der Praxis sehr nützlich. Erstens kann dieselbe Persona dasselbe Produkt in verschiedenen Kontexten für verschiedene Jobs einstellen. Zweitens verallgemeinert JTBD die emotionale und soziale Seite über alle Nutzer hinweg und hilft dem Team deshalb weniger, Empathie aufzubauen.

So nutze ich beides: Die Persona beantwortet „wer“, die Job Story „in welchem Moment, wofür“. Schreiben Sie die Zielzeile der Persona als Job Story, leben beide im selben Dokument. Um die emotionale Seite sichtbar zu machen, können Sie auch eine Empathy Map ergänzen.

Den Job im Interview finden

Einen Job kann man nicht am Schreibtisch erfinden. Laubheimer schreibt, dass JTBD aus qualitativer Forschung wie Interviews und Feldstudien hervorgeht. Ich finde den Job am häufigsten im Nutzerinterview.

Eine allgemeine Frage wie „Was wünschen Sie sich?“ zeigt keinen Job. Man muss die Person erzählen lassen, was sie in der Vergangenheit tatsächlich getan hat: Wann zuletzt, wo, mit wem waren Sie, was geschah davor?

Das Switch-Interview

Die von Bob Moesta und Chris Spiek betriebene Website jobstobedone.org beschreibt dafür das Switch-Interview. Ein Switch-Interview rekonstruiert eine echte Kaufentscheidung Schritt für Schritt rückwärts. Es ist weder Fokusgruppe noch Umfrage.

• Mit wem: mit Menschen, die in den letzten 30 bis 90 Tagen das Produkt gewechselt haben. Laut Website lässt das Gedächtnis nach 90 Tagen nach. Auch wer fast gewechselt und dann aufgegeben hat, gehört auf die Liste.
• Wie lange: 45 bis 90 Minuten. Die Website sagt, dass ein gehetztes Interview Meinungen statt Ereignisse sammelt.
• Wo man beginnt: bei dem Moment, in dem die Person zum ersten Mal an den Wechsel dachte. Dieser Moment liegt oft Wochen oder Monate vor dem Kauf.
• Wie man zuhört: mit den eigenen Worten der Person. Die interviewende Person legt Kunden keine eigenen Worte in den Mund.

Die Zeitleiste auf der Website hat sechs Schritte: erster Gedanke, passive Suche, erstes Ereignis, aktive Suche, zweites Ereignis und Kauf. Die Kräfte beschreiben, warum jemand gewechselt hat, die Zeitleiste, wie.

Vier Kräfte

Dieselbe Quelle sieht jeden Wechsel als Tauziehen zwischen vier Kräften. Der Push ist das Problem der aktuellen Lage. Der Pull ist der Fortschritt, den die neue Lösung verspricht. Die Angst ist die Unsicherheit einer unerprobten Wahl. Die Gewohnheit bindet die Person an das, was sie heute tut.

Die Website rät, nicht direkt nach diesen Kräften zu fragen. Ich frage stattdessen immer weiter „Was passierte dann?“. Überträgt man die Interviews auf eine Zeitleiste, zeigen sich wiederkehrende Muster für denselben Job oft nach 5 bis 8 Interviews.

Wo JTBD im Prozess steht

Am meisten hilft JTBD in der Discovery-Phase. Schreiben Sie den Job auf, solange es noch keine Lösung gibt, vergleicht sich das Team seltener mit den falschen Konkurrenten. Wie im Milchshake-Beispiel kann der eigentliche Konkurrent aus einer anderen Kategorie kommen.

In der Entwicklung steht die Job Story neben der User Story. Cohn empfiehlt die User Story, wenn sich die Bedürfnisse der Nutzer deutlich unterscheiden. Würden alle Ihre Stories mit „As a user“ beginnen, empfiehlt er die Job Story. Beide können im selben Backlog stehen.

Auch das Beispiel aus Klements Intercom-Text passt hierher. Das Team gestaltete einen Profilbildschirm für ein Produkt, das Autoverkäufern hilft, Finanzierungen zu arrangieren. Die kaufende Person sollte sensible Finanzdaten teilen, deshalb ging es ihr vor allem um Vertrauen.

Im Profil standen Foto, Berufsbezeichnung, Zahl der verkauften Autos und Jahre im Unternehmen der verkaufenden Person. Dazu kamen einfache Wege zur Kontaktaufnahme.

Mir fällt an diesem Beispiel die Reihenfolge auf. Zuerst wurde die Sorge der kaufenden Person aufgeschrieben, der Profilbildschirm kam danach.

Häufige Fehler

Dieser Abschnitt ist meine Sicht. Beim Lesen von Job Statements sehe ich diese Fehler am häufigsten:

• Die Lösung in den Job schreiben. „Ich möchte eine Push-Benachrichtigung bekommen“ ist kein Job, sondern eine Designentscheidung. Schreiben Sie auf, was die Person zu verpassen fürchtet.
• Die Situation leer lassen. Ein Satz, der mit „Als Nutzer“ beginnt, beschreibt keinen Moment. Gibt es kein Ereignis, das den Job auslöst, weiß das Team nicht, wo es den Bildschirm platzieren soll.
• Das Ergebnis als Wiederholung der Motivation schreiben. „Ich möchte die Rechnung bezahlen, damit die Rechnung bezahlt ist“ sagt nichts. Das Ergebnis muss beschreiben, was sich im Leben der Person ändert.
• Bei einem einzigen Job stehen bleiben. Dieselbe Person nutzt dasselbe Produkt in verschiedenen Momenten für verschiedene Jobs. Auch Nobel schreibt, dass man für den Job, Kindern eine Freude zu machen, einen eigenen, dünneren Milchshake in Betracht ziehen könnte.

In einem bestehenden Produkt sehen Sie die Spuren dieser Fehler in den Abläufen: Weil niemand weiß, welchen Moment ein Bildschirm löst, füllen sich die Bildschirme mit Funktionen. In einem UX Audit Pro lese ich jeden Ablauf einzeln mit dieser Frage.

Meine Notiz

Ich sehe JTBD als eine Frage. Sie lautet: „Warum tut diese Person das genau in diesem Moment?“ Kennen Sie die Antwort nicht, ist das Job Statement eine Vermutung, so sauber es auch geschrieben ist.

Als kleines Team brauchen Sie kein großes JTBD-Programm. Sprechen Sie mit fünf Personen, die zuletzt gewechselt haben. Leiten Sie aus jedem Interview ein Job Statement ab und schauen Sie, welche sich wiederholen.

Probieren Sie auch Folgendes: Streichen Sie Ihren Produktnamen aus dem Job Statement. Ergibt der Satz noch Sinn? Dann haben Sie den Job gefunden. Wird er sinnlos, haben Sie eine Funktionsbeschreibung in der Hand.