📚 Kompletter Leitfaden

Jobs to Be Done: Das Framework, Beispiele & wie Sie es im Onboarding anwenden

Was Jobs to Be Done wirklich bedeutet, die vier Kräfte hinter jedem Wechsel, Vorlagen für Job Statements zum Kopieren, sechs ausgearbeitete Beispiele und wie Sie aus einem Job einen Onboarding-Ablauf machen, der Nutzer schneller zu ihrem Ergebnis bringt.

📅 Aktualisiert im November 2026 ⏱ 17 Min. Lesezeit ✍️ Von Kompassify
🌐 English Português Français Deutsch
Jobs-to-Be-Done-Framework: Ein Nutzer in einer Situation heuert ein Produkt an, um auf ein Ergebnis hin voranzukommen

Jedes Produktteam hat dieses Gespräch schon geführt. Jemand öffnet die Analytics, zeigt auf eine Funktion, deren Entwicklung ein Quartal gedauert hat, und fragt, warum sie niemand nutzt. Das Design wurde geprüft. Die Texte wurden poliert. Der Rollout lief nach Plan. Und trotzdem bleibt die Adoption flach.

Die übliche Reaktion ist, noch mehr hinzuzufügen: noch ein Tooltip, noch eine E-Mail, noch eine Zeile im Changelog. Das Problem liegt aber oft weiter vorne. Die Funktion wurde für einen Nutzertyp gebaut statt für einen Job, den dieser Nutzer tatsächlich erledigen wollte.

Jobs to Be Done ist das Framework, das diese Lücke schließt. Es ersetzt die Frage „Wer ist unser Nutzer?“ durch eine schärfere: Welchen Fortschritt will diese Person erreichen, und wofür hat sie uns angeheuert? Dieser Leitfaden zeigt, was JTBD bedeutet, wie Sie ein Job Statement schreiben, wie Sie die Interviews führen, sechs ausgearbeitete Beispiele und (der Teil, den die meisten Leitfäden auslassen) wie Sie aus einem Job einen Onboarding-Ablauf machen, der ihn tatsächlich erledigt.

Das Wichtigste in Kürze

  • Menschen heuern Produkte an, um voranzukommen. Ein Job ist der Fortschritt, den jemand in einer bestimmten Situation erreichen will: keine Funktion, keine Persona, keine Demografie.
  • Jeder Job hat drei Dimensionen. Funktional (die Aufgabe), emotional (wie sich die Person fühlen will) und sozial (wie sie gesehen werden will). Produkte, die nur die funktionale Dimension lösen, verlieren gegen solche, die alle drei lösen.
  • Wechsel werden von vier Kräften bestimmt. Push und Pull bewegen Nutzer zu Ihnen hin; Angst und Gewohnheit halten sie zurück. Onboarding ist größtenteils Angstabbau, deshalb behebt „mehr Vorteile“ selten eine schwache Aktivierungsrate.
  • Job Statements sind lösungsfrei. „Wenn [Situation], möchte ich [Motivation], damit ich [Ergebnis].“ Wenn ein Produkt, eine Funktion oder eine Technologie im Satz vorkommt, ist es kein Job Statement.
  • Befragen Sie Wechsler, nicht alle. Sprechen Sie mit Menschen, die in den letzten 90 Tagen etwas geändert haben, und rekonstruieren Sie ihre Zeitleiste rückwärts. Meinungen sind unzuverlässig, jüngstes Verhalten nicht.
  • Der Ertrag liegt im Onboarding. Sobald Sie den Job kennen, ist das erste Nutzungserlebnis keine Produkttour durch Ihre Menüleiste mehr, sondern der kürzeste Weg zu einer erledigten Instanz des Jobs.

Was ist Jobs to Be Done?

Definition von Jobs to Be Done (JTBD): ein Framework zum Verständnis von Kundenverhalten, das Menschen über den Fortschritt beschreibt, den sie in einer bestimmten Situation erreichen wollen, und nicht darüber, wer sie sind. Nach JTBD kaufen Kunden keine Produkte; sie heuern sie für einen Job an und feuern sie, wenn etwas anderes den Job besser erledigt.

Dieser Perspektivwechsel klingt klein. In der Praxis verändert er, was Sie bauen, was Sie messen und wen Sie als Wettbewerber betrachten.

Nehmen wir ein Team, das eine Reporting-Funktion entwickelt. Aus Persona-Sicht lautet das Briefing: „Marketingmanager in mittelständischen Unternehmen brauchen bessere Dashboards.“ Aus Job-Sicht lautet dasselbe Briefing: „Wenn mein CEO fragt, wie der letzte Monat lief, möchte ich in unter fünf Minuten eine belastbare Zahl haben, damit ich im Führungsmeeting nicht unvorbereitet dastehe.“

Die zweite Formulierung verrät etwas, das die erste nie verraten könnte: Der echte Wettbewerber ist kein anderes Analytics-Tool. Es ist eine Tabelle, der der Marketingmanager bereits vertraut, und der Zeitdruck eines Meetings, das in zehn Minuten beginnt. Deshalb zählt die Geschwindigkeit bis zur Antwort mehr als die Vielfalt der Diagramme, und deshalb verliert ein Onboarding-Ablauf, der mit „Verbinden Sie sechs Datenquellen“ beginnt, jedes Mal.

Woher die Idee stammt

Das Framework wird vor allem mit Clayton Christensen verbunden, dessen „Milchshake“-Studie ergab, dass die morgendlichen Milchshake-Käufer einer Fast-Food-Kette überhaupt keine demografische Gruppe waren; es waren Pendler, die ein dickflüssiges Getränk anheuerten, um eine langweilige Autofahrt mit einer Hand erträglicher zu machen. Die Konkurrenz waren nicht andere Milchshakes. Es waren Bananen, Bagels und Langeweile.

Tony Ulwicks Outcome-Driven Innovation und Bob Moestas „Switch“-Interviews lieferten die praktische Mechanik dazu: wie man einen Job formuliert, wie man ihn findet und wie man die Kräfte erkennt, die jemanden endlich zum Wechsel bringen. Moderne SaaS-Teams nutzen meist eine Mischung aus allen dreien, und genau die beschreibt dieser Leitfaden.


Die drei Dimensionen eines Jobs

Ein Job ist nie rein praktisch. Jede Entscheidung, ein Produkt anzuheuern, hat drei Ebenen, und die übersehenen Ebenen entscheiden meist darüber, ob ein Produkt bleibt.

Ein praktischer Test: Nehmen Sie eine beliebige Funktion von Ihrer aktuellen Roadmap und schreiben Sie für jede Dimension einen Satz. Bleiben die Zeilen für emotional und sozial leer, bauen Sie eine Fähigkeit und lösen keinen Job, und die Adoption hängt dann ganz davon ab, ob Nutzer selbst herausfinden, warum es sie interessieren sollte.


Jobs to Be Done vs. Personas vs. User Stories

JTBD wird regelmäßig als Ersatz für Personas dargestellt. Das ist es nicht. Die drei Artefakte beantworten unterschiedliche Fragen und scheitern auf unterschiedliche Weise, und reife Teams behalten alle drei, nur mit klareren Grenzen.

Artefakt Frage, die es beantwortet Am besten geeignet für Wie es scheitert
Persona Wer ist diese Person? Positionierung, Tonalität, Kanalwahl, Lead-Qualifizierung im Vertrieb Driftet in die Fiktion ab: Stockfotos, erfundene Hobbys und demografische Angaben, die nie eine Produktentscheidung verändern
Job to Be Done Welchen Fortschritt will die Person erreichen, und wann? Roadmap-Priorisierung, Positionierung gegenüber echten Alternativen, Onboarding-Design, Definition der Aktivierung Auf der falschen Flughöhe geschrieben: entweder so breit, dass er nutzlos ist („mein Geschäft führen“), oder so eng, dass er ein verkleideter Feature-Wunsch ist
User Story Was sollen wir im nächsten Sprint bauen? Scoping und Übergabe an die Entwicklung Wird zu einem Lösungsticket mit dem Präfix „Als Nutzer“, losgelöst von jedem Job

Die saubere Arbeitsteilung: Der Job entscheidet, was es verdient zu existieren, die Persona entscheidet, wie Sie darüber sprechen, und die User Story entscheidet, was in diesem Sprint ausgeliefert wird. Probleme beginnen, wenn eine Persona die Arbeit des Jobs übernehmen soll; so landen Teams bei einer Roadmap voller Funktionen, die zur Zielgruppe passen und nichts Bestimmtem dienen.


Wie Sie ein Job Statement schreiben (mit Vorlage)

Im Job Statement wird der größte Teil des Werts geschaffen oder vernichtet. Es ist ein einziger Satz, und er muss jahrelang den Kontakt mit Ihrer Roadmap überstehen.

Die Vorlage:
Wenn [Situation: der auslösende Umstand],
möchte ich [Motivation: was ich zu tun versuche],
damit ich [erwartetes Ergebnis: wie mein Leben besser wird].

Die drei Regeln, die ein Job Statement brauchbar machen

1. Halten Sie es lösungsfrei

Keine Produktnamen, keine Funktionsnamen, keine Technologie. „Wenn ich einen neuen Kunden onboarden muss, möchte ich ihm eine automatisierte E-Mail-Sequenz schicken“ ist kein Job; es ist eine Lösung, die jemand bereits gewählt hat. Der Job darunter lautet: „Wenn ich einen neuen Kunden übernehme, möchte ich, dass er in der ersten Woche produktiv ist, ohne dass ich denselben Einrichtungs-Call wiederhole, damit ich mehr Kunden annehmen kann, ohne mehr Stunden zu arbeiten.“

Der Test: Könnte ein Wettbewerber mit einer völlig anderen Architektur dieses Statement bedienen? Wenn nicht, haben Sie eine Spezifikation geschrieben.

2. Verankern Sie es in einer Situation, nicht in einer Frequenz

„Wenn ich das wöchentliche Reporting mache“ ist ein Kalendereintrag. „Wenn ich nach einer Zahl gefragt werde, die ich nicht parat habe“ ist eine Situation; sie kann wöchentlich eintreten oder dreimal an einem Dienstag, und sie sagt Ihnen genau, wann Ihr Produkt zur Stelle sein muss. Situationen machen Jobs für das Onboarding und für In-App-Trigger umsetzbar, weil sich eine Situation am Nutzungsverhalten im Produkt erkennen lässt.

3. Formulieren Sie das Ergebnis in der Sprache des Nutzers, nicht in Ihrer

„Damit ich die Effizienz des Teams steigern kann“ ist ein Satz von Ihrer Marketing-Website. „Damit ich nicht jedes Mal zum Engpass werde, wenn jemand Neues anfängt“ ist das, was ein Mensch tatsächlich sagt. Ergebnisteile in Anbietersprache sind das deutlichste Zeichen dafür, dass ein Job Statement in einem Meeting erfunden und nicht in einem Interview gehört wurde.

Achten Sie auf die Flughöhe. Ein zu hoch angesetzter Job („mein Geschäft wachsen lassen“) lässt sich nicht gestalten. Ein zu tief angesetzter Job („die Tabelle nach Datum filtern“) ist eine Funktion. Die brauchbare Flughöhe ist meist die eines Jobs, den eine Person in einem Durchgang erledigen könnte und von dem sie sagen würde, er sei „erledigt“; das ist, nicht zufällig, auch die richtige Größe für das Ziel der ersten Sitzung im Onboarding.


Die vier Kräfte: warum Nutzer wechseln (und warum nicht)

Ein Job erklärt, was jemand will. Die vier Kräfte erklären, warum er endlich etwas dagegen unternimmt, oder warum er jahrelang nichts unternimmt, während Ihr Vertriebsteam Follow-ups verschickt.

Die vier Kräfte des Fortschritts → PUSH Frust darüber, wie es heute läuft. „Die Tabelle ist schon wieder kaputt.“ → PULL Der Reiz der neuen Lösung. „Die Demo wirkte völlig mühelos.“ ← ANGST Sorge, was das Neue kostet. „Was, wenn die Datenmigration scheitert?“ ← GEWOHNHEIT Bequemlichkeit des Gewohnten. „Ich weiß, wo alles ist.“ WECHSEL passiert hier Push + Pull > Angst + Gewohnheit → der Nutzer wechselt wirklich

Die Gleichung ist unverblümt: Ein Wechsel findet nur statt, wenn Push plus Pull schwerer wiegt als Angst plus Gewohnheit. Das Marketing steckt fast seine gesamte Energie in Pull. Der Vertrieb fügt ein wenig Push hinzu. Für die andere Seite der Waage ist fast niemand zuständig, und genau dort liegt der Großteil Ihrer verlorenen Aktivierung.

Kraft Wie sie klingt Wo Sie sie adressieren
Push „So können wir nicht weitermachen.“ Positionierung, Discovery im Vertrieb, problemorientierte Inhalte
Pull „Das würde es lösen.“ Landingpage, Demo, kostenlose Testphase
Angst „Was, wenn ich auf halbem Weg feststelle, dass es nicht funktioniert?“ Onboarding: Beispieldaten, Rückgängig-Funktion, ein sichtbarer erster Erfolg, ein geführter erster Durchlauf
Gewohnheit „Ehrlich gesagt, der alte Weg ist doch in Ordnung.“ Onboarding + Adoption: Importfunktionen, Integrationen und den neuen Weg schon am ersten Tag schneller machen als den alten

Das ist das Nützlichste, was JTBD einem Onboarding-Team gibt. Ist Ihre Trial-to-Paid-Rate schwach, liegt der Reflex nahe, das Produkt besser klingen zu lassen. Die vier Kräfte legen nahe, stattdessen darauf zu schauen, wovor Nutzer in den ersten zehn Minuten Angst haben: eine Diagnose, auf die Sie direkt reagieren können und die wir aus Kennzahlensicht in unseren Leitfäden zu User Friction und zur Conversion von kostenlosen Testphasen behandeln.


Wie Sie ein Jobs-to-Be-Done-Interview führen

JTBD-Forschung ist keine Umfrage und keine Sammlung von Feature-Wünschen. Sie ist ein strukturierter Versuch, eine bereits getroffene Entscheidung zu rekonstruieren, um die Kräfte zu finden, die sie hervorgebracht haben.

  1. Rekrutieren Sie Menschen, die kürzlich gewechselt sind: die sich in den letzten 90 Tagen registriert, ein Upgrade gemacht oder gekündigt haben

  2. Rekonstruieren Sie die Zeitleiste rückwärts ab dem Moment der Entscheidung

  3. Finden Sie den ersten Gedanken, das passive Umschauen, die aktive Suche und den Auslöser

  4. Ordnen Sie das Gehörte den vier Kräften zu

  5. Schreiben Sie das Job Statement und validieren Sie es dann am Nutzungsverhalten im Produkt

1. Rekrutieren Sie Menschen, die kürzlich gewechselt sind

Aktualität zählt mehr als Stichprobengröße. Wer sich vor elf Monaten registriert hat, erzählt Ihnen eine aufgeräumte, rationalisierte Geschichte, die mit dem tatsächlichen Ablauf wenig zu tun hat. Wer sich vor drei Wochen registriert hat, kann Ihnen noch sagen, welcher Browser-Tab offen war und was die Kollegin im Meeting davor gesagt hat.

Acht bis zwölf Interviews reichen meist, um die dominanten Jobs sich wiederholen zu sehen. Beziehen Sie abgewanderte Nutzer ein: Sie sind die günstigste Wahrheitsquelle, die Sie je bekommen werden, und die Einzigen, die Ihnen sagen können, wie der Job aussah, nachdem Sie daran gescheitert sind.

2. Rekonstruieren Sie die Zeitleiste rückwärts

Beginnen Sie beim Kauf oder bei der Registrierung und gehen Sie rückwärts. „Sie haben den Account an einem Dienstagnachmittag angelegt. Was ist an diesem Morgen passiert?“ Und dann weiter. Die meisten Wechselentscheidungen haben eine lange, stille Vorgeschichte: eine erste vage Unzufriedenheit Wochen oder Monate vorher, ein passiver Blick auf Alternativen, dann ein Ereignis, das den Status quo plötzlich inakzeptabel machte.

3. Suchen Sie nach den vier Momenten

Jede Wechselgeschichte enthält dieselben Etappen. Erster Gedanke („das nervt langsam“). Passives Umschauen (lesen, bemerken, halbherzig suchen, ohne Absicht zu handeln). Aktive Suche (vergleichen, Demos ansehen, Kollegen fragen). Und der Auslöser, das konkrete Ereignis, das die Absicht in Handlung verwandelt hat. Der Auslöser ist das Wertvollste am ganzen Interview, denn er sagt Ihrem Marketing genau, wann es auftauchen muss, und Ihrem Onboarding genau, in welchem Zustand der Nutzer ankommt.

4. Fragen Sie nach Verhalten, nie nach Vorlieben

„Was würde das besser machen?“ liefert eine Wunschliste. „Erzählen Sie mir, wie es beim letzten Mal war, als Sie das versucht haben“ liefert Belege. Gute JTBD-Fragen sind fast schon langweilig konkret: Was haben Sie zuerst ausprobiert? Wer war noch im Raum? Was hätte Sie fast abgehalten? Womit mussten Sie aufhören, um Platz dafür zu schaffen?

Die eine Frage, die Sie sich merken sollten: „Was hätte Sie fast davon abgehalten?“ Diese eine Frage fördert mehr Material zur Kraft der Angst zutage als eine ganze Umfrage.

5. Validieren Sie den Job am echten Nutzungsverhalten

Interviews sagen Ihnen, was der Job ist. Produktdaten sagen Ihnen, ob Ihr Produkt ihn erledigt. Sobald Sie einen Kandidaten für den Job haben, definieren Sie, wie „Job erledigt“ als Event aussieht, und prüfen Sie, welcher Anteil neuer Nutzer es erreicht und wie lange das dauert. Kann niemand dieses Event benennen, ist der Job noch zu abstrakt. Unsere Leitfäden zu User-Onboarding-Metriken und zur Time to Value zeigen, wie Sie das sauber instrumentieren.

Produktanalyse-Bericht, der das Event verfolgt, das für den erledigten Job to Be Done steht
(Wenn Sie den erledigten Job als Produkt-Event erfassen, wird aus einer Interview-Erkenntnis eine Zahl, die Sie bewegen können)

6 Beispiele für Jobs to Be Done

Abstrakten Job Statements stimmt man leicht zu, aber sie sind schwer zu schreiben. Diese sechs sind bewusst auf einer brauchbaren Flughöhe formuliert, mit getrennt aufgeführter funktionaler, emotionaler und sozialer Dimension.

Projektmanagement-Tool „Nicht mehr die Person sein, der alle hinterherlaufen müssen“

Job Statement: Wenn mein Team mit drei Tools arbeitet und niemand weiß, was blockiert ist, möchte ich einen Ort, der den echten Stand zeigt, ohne dass ich nachfragen muss, damit ich meine Vormittage nicht mehr mit dem Einsammeln von Updates verbringe.

  • Funktional: den aktuellen Stand aller Arbeitsstränge sehen, ohne ihn manuell einzusammeln
  • Emotional: sich in Kontrolle fühlen statt ständig im Rückstand
  • Sozial: als die Führungskraft gelten, die immer weiß, wo die Dinge stehen
Folge für das Onboarding: Die erste Sitzung muss mit einem gefüllten Board enden, nicht mit einem leeren. Ein leerer Workspace überlässt dem Nutzer am ersten Tag den schwierigsten Teil des Jobs, genau das Problem, für das gut gestaltete Empty States da sind.
Buchhaltungssoftware „Nie wieder von einer Steuerrechnung überrascht werden“

Job Statement: Wenn jede Woche Geld in mein Unternehmen hinein- und hinausfließt, möchte ich wissen, was ich tatsächlich schulde, bevor es fällig wird, damit ich nicht länger eine grobe Zahl im Kopf behalte und hoffe.

  • Funktional: eine genaue, aktuelle Zahl der Verbindlichkeiten
  • Emotional: unterschwellige Geldsorgen durch Gewissheit ersetzen
  • Sozial: gegenüber Steuerberater, Geschäftspartner oder Kreditgeber gut organisiert wirken
Folge für das Onboarding: Der schnellste Weg zu Vertrauen ist früh eine abgeglichene Zahl. Jeder Einrichtungsschritt, der diese erste glaubwürdige Zahl hinauszögert, verbraucht die Geduld des Nutzers für Ihr Datenmodell statt für seinen Job.
Design-Tool „Feedback bekommen ohne ein weiteres Meeting“

Job Statement: Wenn ich die Freigabe von vier Personen in verschiedenen Zeitzonen brauche, möchte ich ihre Kommentare direkt an dem Element haben, das sie kommentieren, damit ich nicht länger widersprüchliches Feedback aus einem Gruppen-Call abgleichen muss.

  • Funktional: kontextbezogenes, zuordenbares Feedback asynchron sammeln
  • Emotional: das Gefühl haben, dass es vorangeht, ohne auf Kalender zu warten
  • Sozial: die Person sein, die liefert, ohne alle in ein Meeting zu zerren
Folge für das Onboarding: Das Aktivierungs-Event ist nicht „Datei erstellt“, sondern „Kommentar von einer Kollegin erhalten“. Einladungsabläufe verdienen genauso viel Designaufmerksamkeit wie der Editor selbst.
Kundensupport-Plattform „Dieselbe Frage nur einmal beantworten“

Job Statement: Wenn jeden Tag dieselben fünf Fragen hereinkommen, möchte ich, dass Kunden die Antwort finden, bevor sie ein Ticket eröffnen, damit ich meine Zeit mit den Problemen verbringen kann, die wirklich einen Menschen brauchen.

  • Funktional: wiederkehrende Anfragen in den Self-Service umleiten
  • Emotional: die Arbeit als sinnvoll statt mechanisch erleben
  • Sozial: der Geschäftsleitung zeigen, dass das Team ohne zusätzliches Personal skaliert
Folge für das Onboarding: Der Job ist erst erledigt, wenn die Entlastung sichtbar ist. Zeigen Sie die Zahl der Fragen, die ohne Ticket beantwortet wurden; die Zahl ist der Beweis, und Beweise machen eine Gewohnheit dauerhaft. Genau diesen Kreislauf soll eine In-App-Support-Ebene schließen.
HR- / People-Tool „Die erste Woche von jemandem nicht peinlich werden lassen“

Job Statement: Wenn eine neue Mitarbeiterin am Montag anfängt, möchte ich, dass alles, was sie braucht, vor ihrem ersten Login bereitsteht, damit ich mich am ersten Tag nicht für fehlende Accounts entschuldigen muss.

  • Funktional: Accounts, Dokumente und Aufgaben vor dem Starttermin bereitstellen
  • Emotional: die ganz spezielle Peinlichkeit eines sichtbar chaotischen Empfangs vermeiden
  • Sozial: für ein Unternehmen stehen, das seine Abläufe im Griff hat
Folge für das Onboarding: Der Job ist durch ein externes Datum begrenzt. Jedes Produkt, das einen Job mit fester Deadline bedient, sollte zuerst nach dem Datum fragen und von dort rückwärts arbeiten; die Deadline ist der Auslöser.
Analytics-Produkt „Eine Antwort haben, bevor das Meeting beginnt“

Job Statement: Wenn mir jemand aus der Führungsebene eine Frage stellt, die ich nicht aus dem Kopf beantworten kann, möchte ich innerhalb weniger Minuten eine Zahl haben, die ich zu vertreten bereit bin, damit ich zur Entscheidung beitragen kann, statt eine Rückmeldung zu versprechen.

  • Funktional: schnell eine vertrauenswürdige Kennzahl abrufen
  • Emotional: sich vorbereitet statt bloßgestellt fühlen
  • Sozial: glaubwürdig sein in einem Raum, in dem Glaubwürdigkeit sich aufsummiert
Folge für das Onboarding: Der echte Wettbewerber ist eine Tabelle, der der Nutzer bereits vertraut. Um sie zu schlagen, braucht es Geschwindigkeit und Nachvollziehbarkeit, nicht mehr Diagrammtypen; deshalb gehört „Warum ist diese Zahl so, wie sie ist?“ in die erste Sitzung.

Wie Sie Jobs to Be Done auf das User Onboarding anwenden

Hier hört JTBD auf, eine Forschungsübung zu sein, und beginnt, sich bezahlt zu machen. Im Onboarding erledigt Ihr Produkt entweder den Job, oder es verlangt vom Nutzer, zuerst eine Oberfläche zu lernen. Fast jedes schlechte Onboarding ist Letzteres.

❌ Feature-orientiertes Onboarding Tour durchs Menü Einstellungen erklären Jeden Tab zeigen „Alles eingerichtet!“ Leerer Bildschirm ✅ Job-orientiertes Onboarding Nach dem Auslöser fragen Echte Daten importieren Job einmal erledigen Ergebnis zeigen Job erledigt

1. Definieren Sie Aktivierung als erledigten Job, nicht als erledigte Schritte

Die meisten Aktivierungsdefinitionen sind Stellvertreter für Aufwand: Profil ausgefüllt, Tour beendet, drei Funktionen angeklickt. Nichts davon ist Fortschritt aus Sicht des Nutzers. Ersetzen Sie sie durch das kleinste Event, das bedeutet, dass der Job einmal wirklich erledigt wurde: ein Bericht geteilt, ein Kunde eingeladen, eine Rechnung abgeglichen.

Diese eine Änderung zeigt oft, dass eine gesund wirkende Aktivierungsrate gemessen hat, wie brav Nutzer Ihrer Tour folgen, und nicht, welchen Wert sie bekommen haben. Unser Leitfaden zum Steigern der Nutzeraktivierung geht tiefer auf die Wahl dieses Events ein, und der Leitfaden zum Aha-Moment zeigt, wie Sie ihn in Ihren Daten erkennen.

2. Streichen Sie jeden Schritt der ersten Sitzung, der nicht dem Job dient

Nehmen Sie Ihren aktuellen Registrierungs- und Ersteinstiegsablauf und markieren Sie jeden Schritt: Bringt er den Nutzer einer erledigten Instanz des Jobs näher, oder dient er Ihrer Datenbank? Teamnamen, Avatare, Rollenauswahl und Präferenzbildschirme gehören fast immer zur zweiten Sorte. Sie können warten; in unserem Leitfaden zu Best Practices für den Registrierungsprozess sehen Sie, wie weit sich das treiben lässt.

3. Lösen Sie Hilfe über die Situation aus, nicht über den Kalender

Ein Job Statement benennt eine Situation. Situationen lassen sich erkennen: Ein Nutzer öffnet zum ersten Mal den Reporting-Bereich, importiert eine Datei, lädt eine Kollegin ein oder landet auf einer leeren Liste. Hilfe, die in diesen Momenten erscheint, kommt an; Hilfe, die an „Tag 1, Tag 3, Tag 7“ ausgelöst wird, meist nicht, weil sie keine Ahnung hat, was der Nutzer gerade zu tun versucht.

Mit Kompassify-Produkttouren können Sie eine Tour oder einen Tooltip genau an das Element und die Seite heften, an denen der Job tatsächlich beginnt, und sie auf das Segment ausrichten, für das dieser Job real ist, ohne die Entwicklung um ein Release zu bitten.

Eine kontextbezogene Produkttour, die in dem Moment startet, in dem der Nutzer mit dem Job to Be Done beginnt
(Hilfe, die durch die Situation ausgelöst wird statt durch die Nummer des Tages)

4. Machen Sie aus dem Job die Checkliste

Eine Onboarding-Checkliste ist der klarste Ort, um einen Job sichtbar zu machen, weil sie öffentlich festlegt, was „erledigt“ bedeutet. Formulieren Sie jeden Punkt als Schritt im Job, als Ergebnis, das der Nutzer wiedererkennt: „Verbinden Sie den Account, über den Sie tatsächlich berichten“, nicht „Integrations-Setup abschließen“.

Die Onboarding-Checkliste und der Fortschrittsbalken von Kompassify sind genau dafür da: dem Nutzer zu zeigen, wie weit er im Job ist, und nicht, wie weit er in Ihrem Einrichtungsassistenten ist.

5. Gehen Sie die Kraft der Angst gezielt an

Listen Sie die drei Dinge auf, vor denen ein neuer Nutzer in den ersten zehn Minuten am meisten Angst hat: meist „Ich importiere die falschen Daten“, „Ich mache etwas kaputt, das mein Team sieht“ und „Ich verbringe eine Stunde und komme nirgendwohin“. Gestalten Sie dann für jedes etwas, das es entschärft: eine Sandbox, eine sichtbare Rückgängig-Funktion, einen Beispieldatensatz oder einen Fünf-Minuten-Weg zu einem ersten Ergebnis. Angst ist die Kraft, die nur das Onboarding wirklich bewegen kann.

6. Segmentieren Sie nach Job, nicht nur nach Tarif

Zwei Nutzer im selben Tarif können mit völlig unterschiedlichen Jobs ankommen. Eine von JTBD geleitete Segmentierung erlaubt es, jeden zu dem Ablauf zu leiten, der seinem Job dient, die Grundlage jedes wirklich personalisierten Onboardings. Eine kurze Frage wie „Was führt Sie heute hierher?“ bei der Registrierung reicht oft zum Verzweigen, sofern die Antwortoptionen Jobs sind und keine Jobtitel.

Die Kurzfassung: Finden Sie den Job, definieren Sie Aktivierung als einmal erledigten Job, streichen Sie alles aus der ersten Sitzung, was ihm nicht dient, lösen Sie Hilfe in der passenden Situation aus und stecken Sie den Rest Ihrer Energie in den Abbau von Angst. Diese Abfolge ist das meiste, was JTBD einem Onboarding-Team zu bieten hat.


Häufige Fehler bei Jobs to Be Done

✅ Das sollten Sie tun

  • Menschen befragen, die in den letzten 90 Tagen gewechselt sind
  • Job Statements schreiben, die eine Situation benennen, keinen Zeitplan
  • Die emotionale und soziale Dimension ausdrücklich einbeziehen
  • Tabellen, manuelle Prozesse und „gar nichts tun“ als Wettbewerber behandeln
  • Jeden Job an einem messbaren Produkt-Event validieren
  • Personas behalten, für Positionierung und Kanäle, nicht für die Roadmap
  • Interviews wiederholen, wenn sich Ihr Markt oder Ihre Preise ändern

❌ Das sollten Sie lassen

  • Job Statements in einem Workshop ohne Kundenkontakt erfinden
  • Einen Feature-Wunsch schreiben und ihn Job nennen („Ich möchte einen Massenexport“)
  • Den Job so hoch ansetzen, dass er sich nicht gestalten lässt
  • Nutzer fragen, was sie wollen, statt was sie getan haben
  • Annehmen, dass ein Produkt genau einen Job hat
  • JTBD nutzen, um eine bereits getroffene Entscheidung zu rechtfertigen
  • Bei der Forschung stehen bleiben; eine ungenutzte Job Map ändert nichts

Der teuerste Fehler: die Interviews führen, eine schöne Job Map erstellen und den Onboarding-Ablauf nie ändern. Ein Job, der nicht verändert, was ein neuer Nutzer in seiner ersten Sitzung sieht, hat Sie Forschungszeit gekostet und nichts eingebracht. Wählen Sie einen Job, bauen Sie einen Ablauf um ihn herum neu und messen Sie die Veränderung der Aktivierung, bevor Sie irgendetwas anderes kartieren.


Ein 30-Tage-Plan, um JTBD in die Praxis zu bringen

Woche 1–2: Den Job finden

  • Eine Liste der Nutzer ziehen, die sich in den letzten 90 Tagen registriert, ein Upgrade gemacht oder gekündigt haben
  • 8–12 Switch-Interviews führen und jede Zeitleiste rückwärts rekonstruieren
  • Jedes Zitat als Push, Pull, Angst oder Gewohnheit markieren
  • Zwei oder drei Kandidaten für Job Statements im Standardformat entwerfen

Woche 3: Messbar machen

  • Das eine Event definieren, das bedeutet: „Der Job wurde einmal erledigt“
  • Es instrumentieren und die aktuelle Reichweite und die Zeit bis zur ersten Erledigung messen
  • Die bestehende erste Sitzung Schritt für Schritt am Job prüfen; siehe unseren Leitfaden zum Onboarding-Audit
  • Die drei größten Ängste aus den Interviews auflisten

Woche 4: Einen Ablauf neu bauen

  • Jeden Schritt der ersten Sitzung streichen, der nicht dem Job dient
  • Die Checkliste so umschreiben, dass jeder Punkt ein Schritt des Jobs ist
  • Hilfe von tagesbasiertem Timing auf situationsbasierte Auslöser umstellen
  • Einen Angstlöser ausliefern: Beispieldaten, Rückgängig-Funktion oder eine Sandbox
  • Die Rate erledigter Jobs vorher und nachher vergleichen

Bauen Sie Ihr Onboarding um den Job herum, nicht um das Menü

Kompassify bietet Ihnen No-Code-Produkttouren, Onboarding-Checklisten, Tooltips, Fortschrittsbalken und Produktanalyse: alles, was Sie brauchen, damit neue Nutzer in ihrer ersten Sitzung einen Job erledigen. Kostenlos bis 100 monatlich aktive Nutzer, DSGVO-konform und in der EU gehostet.

Kostenlos starten →

Häufig gestellte Fragen

Was ist Jobs to Be Done (JTBD)?

Jobs to Be Done ist ein Framework, das Kundenverhalten über den Fortschritt erklärt, den eine Person in einer bestimmten Situation erreichen will, und nicht darüber, wer sie ist. Statt Nutzer nach Demografie oder Rolle zu beschreiben, beschreibt JTBD den Job, für den sie ein Produkt anheuern: die funktionale Aufgabe, den emotionalen Zustand, den sie erreichen wollen, und wie sie von anderen wahrgenommen werden möchten. Die Kernidee: Menschen kaufen keine Produkte; sie heuern sie an, um in einer konkreten Situation voranzukommen.

Was ist der Unterschied zwischen Jobs to Be Done und User Personas?

Personas beschreiben, wer der Nutzer ist: Rolle, Senioritätsstufe, Unternehmensgröße, Tools, Ziele. Jobs to Be Done beschreibt, was der Nutzer erreichen will und in welcher Situation. Beide beantworten unterschiedliche Fragen und funktionieren am besten zusammen. Eine Persona sagt Ihnen, wie Sie jemanden ansprechen und über welchen Kanal Sie ihn erreichen; ein Job sagt Ihnen, was Ihr Produkt tatsächlich leisten muss und wohin Ihr Onboarding den Nutzer bringen muss. Zwei sehr unterschiedliche Personas können denselben Job haben, und eine Persona kann mehrere verschiedene Jobs haben.

Wie schreibt man ein Job Statement?

Das Standardformat lautet: Wenn [Situation], möchte ich [Motivation], damit ich [erwartetes Ergebnis]. Ein gutes Job Statement ist lösungsfrei, über die Zeit stabil und konkret in Bezug auf die Situation, die es auslöst. Zum Beispiel: „Wenn mitten im Projekt ein neues Teammitglied dazukommt, möchte ich es produktiv machen, ohne stundenlang meine eigene Zeit zu blockieren, damit ich meine eigenen Ergebnisse im Plan halte.“ Beachten Sie, dass in diesem Satz kein Produkt, keine Funktion und keine Technologie vorkommt; genau das ist der Test.

Was sind die vier Kräfte des Fortschritts bei JTBD?

Die vier Kräfte erklären, warum ein Kunde wechselt oder nicht wechselt. Push ist die Frustration mit der aktuellen Situation. Pull ist die Anziehungskraft der neuen Lösung. Angst ist die Sorge, was mit der neuen Lösung schiefgehen könnte. Gewohnheit ist die Bequemlichkeit der bisherigen Arbeitsweise. Ein Wechsel findet nur statt, wenn Push plus Pull stärker ist als Angst plus Gewohnheit. Die meiste Onboarding-Arbeit besteht in Wahrheit darin, Angst abzubauen und Gewohnheiten zu verdrängen, nicht darin, mehr Pull zu erzeugen.

Wie führt man ein Jobs-to-Be-Done-Interview durch?

Befragen Sie Menschen, die vor Kurzem zu Ihrem Produkt gewechselt sind oder es verlassen haben, idealerweise innerhalb der letzten 90 Tage, solange die Erinnerung noch frisch ist. Rekonstruieren Sie die Zeitleiste rückwärts ab dem Kaufmoment: Wann haben sie zum ersten Mal gemerkt, dass sich etwas ändern muss, was haben sie ausprobiert, was hat die Suche ausgelöst, was hätte sie fast von der Registrierung abgehalten. Fragen Sie nach Ereignissen und Verhalten, nie nach Meinungen oder Funktionswünschen. Acht bis zwölf Interviews mit Menschen, die kürzlich gewechselt haben, bringen die dominanten Jobs meist zum Vorschein.

Wie verbessert Jobs to Be Done das User Onboarding?

Die meisten Onboardings scheitern, weil sie die Oberfläche erklären, statt den Job zu erledigen. Sobald Sie den Job kennen, können Sie eine erste Sitzung definieren, die eine sinnvolle Instanz davon abschließt, jeden Schritt streichen, der ihm nicht dient, und Aktivierung als erledigten Job messen statt als abgeschlossene Schritte. In der Praxis heißt das: eine Checkliste, deren Punkte dem Job entsprechen, Produkttouren, die im Moment des Jobs erscheinen statt beim ersten Login, und Empty States, die zeigen, wie der erledigte Job aussieht.

Ist Jobs to Be Done nur für neue Produkte nützlich?

Nein. JTBD ist bei ausgereiften Produkten wohl sogar nützlicher, weil dort die Funktionslisten schneller gewachsen sind als die Klarheit. Es gibt einem etablierten Team eine Möglichkeit zu entscheiden, was gestrichen wird, welches Segment tatsächlich bedient wird und warum eine gut gebaute Funktion nicht angenommen wird. JTBD-Interviews mit abgewanderten Nutzern sind einer der schnellsten Wege herauszufinden, ob Sie sie an einen Wettbewerber, an eine interne Behelfslösung oder an das völlige Verschwinden des Jobs verloren haben, eine Unterscheidung, die unser Leitfaden zu User Churn genauer beleuchtet.