JTBD vs. User Stories: Wann was einsetzen

Zwei Methoden, eine Mission — aber nicht dasselbe

In meinen Workshops mit Produktteams aus dem DACH-Raum höre ich dieselbe Frage immer wieder: “Wir arbeiten bereits mit User Stories. Brauchen wir dann überhaupt JTBD?” Manchmal kommt sie als echte Frage, manchmal als höflicher Widerstand. Die implizite Aussage dahinter ist: Wir machen schon etwas Ähnliches — warum den Aufwand verdoppeln?

Die Antwort ist komplex und ehrlich: JTBD und User Stories sind nicht dasselbe. Sie arbeiten auf verschiedenen Abstraktionsebenen, dienen verschiedenen Zwecken und lösen verschiedene Probleme. Beide haben ihre Berechtigung. Aber sie sind nicht austauschbar — und wer sie verwechselt, macht Fehler, die sich in der Produktstrategie niederschlagen.

Dieser Artikel klärt den Vergleich JTBD vs. User Stories präzise: Was jede Methode kann, was sie nicht kann, wann man welche einsetzt — und wann man beide braucht.

Was User Stories sind — und was sie leisten

Ursprung und Designprinzip

User Stories entstammen der agilen Softwareentwicklung. Die klassische Formulierung: “Als [Rolle] möchte ich [Aktion], damit [Nutzen].” Entwickelt im Kontext von Extreme Programming und Scrum, sind User Stories ein Kommunikationswerkzeug zwischen Produktteams und Entwicklern — eine kompakte, verstehbare Beschreibung von Funktionalitätsanforderungen aus Nutzerperspektive.

Das Design ist bewusst einfach gehalten. User Stories sollen nicht vollständige Anforderungsdokumente ersetzen, sondern Gesprächsstarter sein. Das “As a / I want to / So that”-Format zwingt das Team, eine Nutzerrolle zu benennen, eine konkrete Handlung zu beschreiben und den erwünschten Nutzen zu explizieren.

In der Praxis haben sich User Stories als zentrales Backlog-Element in agilen Teams etabliert. Sie sind das, was in Jira, Linear oder Azure DevOps als Arbeitseinheit erfasst wird. Sie strukturieren Sprints, definieren Akzeptanzkriterien und ermöglichen die inkrementelle Produktentwicklung.

Was User Stories gut können

Implementierungsklarheit: Eine gut formulierte User Story gibt Entwicklern einen klaren Auftrag — mit Akzeptanzkriterien, die testbar sind.

Iterative Entwicklung: User Stories sind auf iterative Entwicklung ausgelegt. Sie sind klein genug, um in einem Sprint abgeschlossen zu werden, und groß genug, um sinnvolle Funktionalität zu beschreiben.

Kommunikation im Team: User Stories bringen Produktmanagement und Entwicklung auf eine gemeinsame Sprache. Die Nutzerrolle verhindert, dass Anforderungen rein technisch formuliert werden.

Priorisierung des Backlogs: Ein Product Backlog aus User Stories ist priorisierbar — nach Business Value, technischer Abhängigkeit oder Kundendringlichkeit.

Was User Stories nicht können

Und hier liegt der Kern des Vergleichs JTBD vs. User Stories: Was User Stories strukturell nicht leisten können.

Strategische Priorisierung: User Stories sagen nicht, welche Probleme überhaupt gelöst werden sollen. Sie beschreiben Lösungen — nicht Bedürfnisse. Wer entscheidet, welche User Stories ins Backlog kommen, trifft implizit strategische Entscheidungen — oft ohne ausreichende Datengrundlage.

Marktebene: User Stories sind individuell — “Als Nutzer möchte ich…” Welcher Nutzer? Mit welcher Häufigkeit? Wie repräsentativ? User Stories haben keine eingebaute Mechanik, um zwischen wichtigen und unwichtigen Bedürfnissen auf Marktebene zu unterscheiden.

Lösungsunabhängigkeit: User Stories sind per Definition lösungsimplizit — sie beschreiben eine gewünschte Aktion (“Ich möchte einen Report exportieren können”). JTBD-Outcomes beschreiben das gewünschte Ergebnis (“Minimiere die Zeit, die benötigt wird, um Daten für externe Stakeholder aufzubereiten”) — und lassen offen, wie dieses Ergebnis erreicht wird.

Validierung: Eine User Story kann interne Annahmen über Kundenbedürfnisse enthalten, die nie validiert wurden. Das “So that…"-Element ist oft nicht durch Kundenforschung belegt, sondern durch interne Überzeugungen.

Was JTBD ist — und was es leistet

Eine andere Abstraktionsebene

Jobs to Be Done arbeitet auf einer anderen Abstraktionsebene als User Stories. JTBD fragt nicht “Was soll das Produkt tun?” — sondern “Was versucht der Kunde in seinem Leben oder seiner Arbeit zu erreichen?”

Ein Job ist die fundamentale Aufgabe, die ein Kunde zu erledigen versucht — unabhängig von der Lösung, die er dafür einsetzt. “Als Radiologe eine medizinische Bildgebungsstudie analysieren” ist ein Job. “Als Logistikleiter die Lieferpünktlichkeit eines Fuhrparks sicherstellen” ist ein Job. Diese Jobs sind stabil — sie existieren, seit es Radiologen und Logistikleiter gibt. Die Technologien, die sie unterstützen, ändern sich fundamental.

Was JTBD gut kann

Marktdefinition: JTBD definiert einen Markt als Gruppe von Menschen mit demselben Job — nicht als Produkt-Kategorie oder Demographic. Das verändert die Wettbewerbsanalyse und deckt Substitutionsrisiken auf, die in produktzentrischen Definitionen unsichtbar bleiben.

Strategische Priorisierung: Durch die quantitative Erfassung von Desired Outcomes — bewertet nach Wichtigkeit und aktueller Erfüllung — entsteht eine datengestützte Priorisierung, die über das Bauchgefühl und die Meinung des lautesten Stakeholders hinausgeht.

Lösungsunabhängigkeit: JTBD-Outcomes beschreiben Ergebnisse, nicht Features. Das ermöglicht Innovationssprünge: Eine Lösung, die dasselbe Outcome besser erfüllt als das bisherige Produkt, kann fundamentell anders aussehen — technologisch, geschäftlich, operativ.

Segmentierung nach Bedürfnissen: JTBD ermöglicht eine Marktsegmentierung nach unerfüllten Bedürfnissen statt nach Demografie. Diese bedarfsbasierte Segmentierung identifiziert Kundengruppen, die für bessere Lösungen zahlen — und die von bestehenden Angeboten systematisch unterversorgt werden.

Was JTBD nicht kann

Implementierungsdetails: JTBD-Outcomes sagen nicht, wie ein Feature gebaut werden soll. Sie sagen, welches Ergebnis es liefern soll. Den Weg von der Erkenntnis zur Implementierung überbrückt JTBD nicht.

Sprint-Planung: JTBD ist kein Backlog-Tool. Es liefert strategische Richtung — aber keine Arbeitseinheiten, die ein Entwicklungsteam direkt umsetzen kann.

Inkrementelle Iteration: JTBD funktioniert auf einer Granularitätsstufe, die für Sprint-zu-Sprint-Entscheidungen zu grob ist. Zwischen dem JTBD-Insight “Outcome X ist massiv unterversorgt” und dem Backlog-Eintrag “Feature Y implementieren” liegt ein konzeptioneller Entwicklungsschritt.

JTBD vs. User Stories: Der direkte Vergleich

Ich erlebe regelmäßig Produktteams, die exzellente User Stories schreiben — präzise, nutzerzentriert, mit klaren Akzeptanzkriterien. Und trotzdem die falsche Richtung einschlagen, weil niemand die Frage gestellt hat: Ist das der Job, den der Markt wirklich priorisiert? User Stories lösen das Implementierungsproblem. JTBD löst das Strategieproblem. Beides zu verwechseln ist teuer.

Wann JTBD, wann User Stories — und wann beides

Situation 1: Strategische Neuausrichtung oder neue Produktlinie

Einsetzen: JTBD / ODI

Wenn ein Unternehmen entscheiden muss, in welchen Markt es einzieht, welche Kundensegmente es priorisiert oder welche Produktkategorie die größten Wachstumschancen bietet, ist JTBD das richtige Instrument. User Stories setzen voraus, dass diese Entscheidungen bereits getroffen sind.

Ein konkretes Beispiel: Ein mittelständischer Hersteller von Industriepumpen will wachsen. Die Frage: In welchen Anwendungsbereich investieren? User Stories können diese Frage nicht beantworten — sie setzen einen Anwendungsbereich voraus. JTBD und ODI liefern die datengestützte Antwort.

Situation 2: Produktentwicklung im etablierten Markt

Einsetzen: JTBD als Strategie, User Stories als Implementierung

In einem etablierten Produktbereich, wo die strategische Richtung klar ist, können beide Methoden komplementär eingesetzt werden. JTBD definiert, welche Outcomes priorisiert werden sollen. User Stories übersetzen diese Priorisierung in implementierbare Arbeitspakete.

Ein Product Manager könnte aus dem JTBD-Insight “Outcome 23 hat einen Opportunity Score von 13 — Kunden brauchen dringend eine bessere Lösung für diesen Aspekt” mehrere User Stories entwickeln, die verschiedene Wege testen, dieses Outcome besser zu erfüllen.

Situation 3: Laufende agile Entwicklung mit geklärter Strategie

Einsetzen: User Stories

Wenn die strategische Ausrichtung klar ist, die Marktsegmente definiert sind und das Team in kurzen Iterationen Feature-Sets entwickelt, sind User Stories das richtige Handwerkszeug. JTBD ist hier möglicherweise zu aufwändig für die taktische Ebene.

Die Voraussetzung: Die Strategie muss wirklich klar und datenbasiert sein — nicht nur intern angenommen.

Situation 4: Produktvision für neue Zielgruppen

Einsetzen: JTBD

Wenn ein Produkt in neue Märkte oder Segmente expandieren soll, liefert JTBD die Orientierung, die User Stories nicht geben können. Welcher Job treibt diese neue Zielgruppe? Welche Outcomes sind unterversorgt? Ohne diese Antworten werden User Stories für die neue Zielgruppe auf Annahmen basieren — mit entsprechenden Risiken.

Die häufigen Fehler im JTBD-vs.-User-Stories-Dilemma

Fehler 1: User Stories als JTBD-Ersatz behandeln

Das “So that…"-Element in User Stories sieht aus wie ein Job. Es ist keiner. “So that I can quickly see my account balance” ist ein Feature-Nutzen, kein Job-to-be-Done. Wer glaubt, JTBD durch bessere User Stories zu ersetzen, löst das Strategieproblem nicht.

Fehler 2: JTBD in den Sprint-Prozess zwingen

Umgekehrt: JTBD-Outcome-Statements sind keine Sprint-Tickets. Teams, die versuchen, Outcome-Statements direkt als Backlog-Items zu verwenden, scheitern an der Implementierungsdistanz. Der Zwischenschritt — von der Erkenntnis zur Konzeption zur User Story — fehlt.

Fehler 3: Beide Methoden parallel ohne Verbindung betreiben

Das dritte Muster: JTBD-Workshops und Sprint-Planung existieren nebeneinander, ohne dass die JTBD-Erkenntnisse systematisch in die Backlog-Priorisierung einfließen. Das ist das schlimmste Szenario — der Aufwand beider Methoden, der Nutzen keiner.

JTBD und User Stories integrieren: Ein praktisches Modell

Das dreistufige Modell

Für Produktteams, die beides sinnvoll einsetzen wollen, empfiehlt sich ein dreistufiges Modell:

Stufe 1: Job-Ebene (JTBD)

• Job definieren
• Job Map erstellen
• Desired Outcomes formulieren und quantifizieren
• Opportunity Scores berechnen
• Strategische Priorisierung: Welche Outcomes sind unterversorgt?

Stufe 2: Konzept-Ebene (Bridge)

• Ideen generieren, die auf unterversorgte Outcomes zielen
• Epics oder Konzepte formulieren, die den Wirkungshebel beschreiben
• Bewertung: Welche Konzepte adressieren die meisten Outcomes mit dem höchsten Score?

Stufe 3: Implementierungs-Ebene (User Stories)

• Epics in User Stories aufbrechen
• Akzeptanzkriterien definieren
• Bezug zum ursprünglichen Outcome-Ziel erhalten (Warum bauen wir das?)

Dieses Modell verhindert das häufigste Problem: Produktteams, die exzellent auf Stufe 3 arbeiten — präzise User Stories, sauber priorisiertes Backlog — aber die Stufe 1 nie systematisch bearbeitet haben.

Für die konkrete Ausgestaltung der JTBD-Anforderungen und einen Leitfaden für Produktmanager stehen weitere Ressourcen zur Verfügung.

Häufig gestellte Fragen

Fazit: Keine Entweder-oder-Entscheidung

Die Debatte JTBD vs. User Stories ist eine falsch gestellte Frage. Beide Methoden sind Werkzeuge für verschiedene Probleme. Wer einen Nagel einschlagen will, nimmt keinen Schraubenzieher — und wer eine strategische Produktentscheidung treffen will, verlässt sich nicht auf User Stories.

Die produktivere Frage lautet: Auf welcher Ebene arbeitet Ihr Team gerade? Wenn auf der Implementierungsebene — User Stories sind das richtige Handwerkszeug. Wenn auf der strategischen Ebene — JTBD liefert die Datengrundlage, die User Stories strukturell nicht bieten können.

In der Praxis brauchen wachstumsorientierte Produktteams beides. Die Aufgabe ist nicht, sich zu entscheiden — sondern beide Methoden auf der richtigen Ebene einzusetzen und explizit zu verbinden.