Jobs to be Done Methode: Ein Leitfaden für Produktmanager

Warum ein englischer Begriff die deutsche Produktentwicklung verändern sollte

“Jobs to be Done” klingt nach amerikanischem Management-Jargon. Und ja, die Methode stammt aus den USA — entwickelt von Clayton Christensen (Harvard Business School) und weiterentwickelt von Tony Ulwick. Aber der Grund, warum der englische Begriff auch im Deutschen verwendet wird, ist simpel: Es gibt keine adäquate Übersetzung.

“Zu erledigende Aufgaben” trifft es nicht. “Kundenaufträge” ist irreführend. “Functional Jobs” als “Funktionale Aufgaben” zu übersetzen, verwässert den konzeptionellen Kern. Deshalb sprechen auch deutsche Produktmanager, Innovationsleiter und Geschäftsführer von “Jobs to be Done” — oder kurz JTBD.

Das ist kein sprachliches Detail. Es ist ein Hinweis darauf, dass JTBD nicht einfach eine weitere Methode ist, die sich in bestehende Frameworks einordnen lässt. Es ist ein Paradigmenwechsel in der Art, wie wir über Kunden, Märkte und Produkte denken.

Und genau deshalb brauchen Produktmanager im DACH-Raum ein solides Verständnis davon — nicht als akademische Übung, sondern als praktisches Werkzeug für bessere Produktentscheidungen.

Die Grundidee: Menschen kaufen keine Produkte

Die zentrale Erkenntnis von JTBD lässt sich in einem Satz zusammenfassen: Menschen kaufen keine Produkte. Sie beauftragen Produkte, um einen Job in ihrem Leben zu erledigen.

Theodore Levitt, Harvard-Professor und Marketing-Legende, formulierte es in den 1960er-Jahren so: “Die Leute wollen keinen Viertelzoll-Bohrer. Sie wollen ein Viertelzoll-Loch.”

Christensen ging weiter: Selbst das Loch ist nicht der Job. Der Job könnte sein: “Ein Regal sicher an der Wand befestigen.” Oder, noch weiter gedacht: “Ordnung im Wohnraum schaffen.” Je nachdem, wie Sie den Job definieren, ändern sich Ihre Wettbewerber, Ihre Zielgruppe und Ihre Produktstrategie fundamental.

Ein Beispiel aus der DACH-Praxis

Nehmen Sie einen Hersteller von Baumaschinen. Traditionell definiert er seinen Markt über sein Produkt: “Wir verkaufen Bagger.” Seine Wettbewerber sind andere Baggerhersteller. Seine Innovationen drehen sich um Motorleistung, Grabtiefe, Reichweite.

Mit JTBD-Perspektive ändert sich alles: Der Kunde — ein Bauunternehmer — will nicht “einen Bagger bedienen.” Er will “Erdreich bewegen, um ein Fundament vorzubereiten.” Das ist sein Job. Und plötzlich sind die Wettbewerber nicht nur andere Bagger, sondern auch Spezialtiefbau-Dienstleister, autonome Verdichtungssysteme oder modulare Fertigfundamente, die weniger Erdarbeit erfordern.

Diese Perspektivverschiebung ist der Grund, warum Clayton Christensen JTBD als die wichtigste Innovationstheorie der letzten 50 Jahre bezeichnete.

Die drei Dimensionen eines Jobs

Ein Job-to-be-Done hat drei Dimensionen, die in der Praxis unterschiedlich relevant sind:

1. Der funktionale Job

Das ist der Kern: die praktische Aufgabe, die der Kunde erledigen will. Funktionale Jobs sind:

• Stabil: Sie ändern sich über Jahrzehnte kaum. Menschen wollten vor 100 Jahren Nachrichten übermitteln, sie wollen es heute. Die Lösungen haben sich verändert — der Job nicht.
• Lösungsunabhängig: Ein funktionaler Job beschreibt, was der Kunde erreichen will, nicht wie.
• Messbar: Funktionale Jobs lassen sich in konkrete, messbare Outcomes zerlegen.

Beispiel: “Einen Patienten während einer minimal-invasiven Operation sicher beatmen.” Das ist der funktionale Job eines Anästhesisten. Er war vor 20 Jahren derselbe wie heute — nur die Beatmungsgeräte haben sich verändert.

2. Emotionale Jobs

Emotionale Jobs beschreiben, wie sich der Kunde fühlen will, während er den funktionalen Job erledigt. Sie umfassen:

• Persönliche emotionale Jobs: “Ich will mich sicher fühlen, dass ich die richtige Entscheidung treffe.”
• Soziale emotionale Jobs: “Ich will, dass mein Team mich als kompetent wahrnimmt.”

Im B2B-Kontext — dem Hauptmarkt für DACH-Industrieunternehmen — werden emotionale Jobs oft unterschätzt. Aber ein VP Engineering, der eine neue Fertigungstechnologie auswählt, trifft keine rein rationale Entscheidung. Er wägt auch ab: “Was passiert mit meiner Karriere, wenn das schiefgeht?”

3. Konsumkettenjobs (Related Jobs)

Das sind Jobs, die vor, während oder nach dem Hauptjob erledigt werden müssen. Ein Chirurg, der ein Endoskop benutzt, muss es vorher vorbereiten, kalibrieren, sterilisieren, dokumentieren, warten. Jeder dieser Schritte ist ein eigener Job mit eigenen Bedürfnissen.

Die Job Map: Das wichtigste Werkzeug im JTBD-Arsenal

Die Job Map ist eine funktionale Zerlegung des Jobs-to-be-Done in seine einzelnen Schritte. Sie folgt einem universellen Schema, das Tony Ulwick über Hunderte von Projekten validiert hat:

1. Definieren: Was muss geplant oder definiert werden, bevor der Job beginnt?
2. Lokalisieren: Welche Inputs — Materialien, Informationen, Ressourcen — müssen gefunden oder gesammelt werden?
3. Vorbereiten: Wie werden die Inputs für die Nutzung vorbereitet?
4. Bestätigen: Was muss überprüft werden, bevor es weitergeht?
5. Ausführen: Die eigentliche Durchführung des Jobs.
6. Überwachen: Was muss während der Ausführung überwacht werden?
7. Modifizieren: Welche Anpassungen sind nötig, wenn sich Bedingungen ändern?
8. Abschließen: Was passiert, wenn der Job erledigt ist?

Warum die Job Map so wichtig ist

Die Job Map ist keine Prozessbeschreibung. Sie beschreibt nicht, wie der Kunde den Job heute erledigt — das wäre eine “Customer Journey Map.” Sie beschreibt die funktionale Struktur des Jobs selbst, unabhängig von der aktuellen Lösung.

Das ist ein entscheidender Unterschied: Eine Customer Journey Map zeigt, wie ein Bauunternehmer heute mit einem bestimmten Bagger arbeitet. Die Job Map zeigt, welche funktionalen Schritte nötig sind, um “Erdreich zu bewegen, um ein Fundament vorzubereiten” — egal ob mit Bagger, Radlader oder einer Technologie, die noch nicht existiert.

Desired Outcomes: Die Sprache der Kundenbedürfnisse

Für jeden Schritt der Job Map werden “Desired Outcomes” formuliert. Das sind konkrete, messbare Aussagen darüber, was der Kunde bei diesem Schritt erreichen will.

Die Formulierungsregeln

Outcomes folgen einem strengen syntaktischen Schema:

Richtung + Maßeinheit + Objekt + Kontext

Beispiele:

• “Minimiere die Wahrscheinlichkeit, dass das Instrument während der Operation die Sicht auf das Operationsfeld verdeckt.”
• “Minimiere die Zeit, die benötigt wird, um die Maschine auf eine neue Bodenart umzurüsten.”
• “Minimiere die Wahrscheinlichkeit, dass relevante Informationen über den Untergrund vor Beginn der Grabarbeiten übersehen werden.”

Die Richtung ist immer “Minimiere” — minimiere die Zeit, die Wahrscheinlichkeit, den Aufwand, die Abweichung. Das stellt sicher, dass Outcomes messbar und vergleichbar sind.

Warum diese Strenge wichtig ist

Die strikte Formulierung hat zwei Zwecke:

1. Lösungsunabhängigkeit: Wenn ein Outcome richtig formuliert ist, beschreibt er das Bedürfnis, nicht die Lösung. “Minimiere die Zeit für die Umrüstung” ist lösungsunabhängig. “Biete einen Schnellwechsler an” ist eine Lösung.

2. Messbarkeit: Jedes Outcome kann in einer Kundenbefragung nach Wichtigkeit und Zufriedenheit bewertet werden. Das ist die Basis für die quantitative Priorisierung in Outcome-Driven Innovation.

Die Formulierung von Outcomes ist eine Kunstform, die man lernen muss. In unseren Projekten investieren wir viel Zeit in die qualitative Phase — weil ein schlecht formuliertes Outcome in der quantitativen Phase unbrauchbare Daten liefert. Das ist wie bei einem Fragebogen: Garbage in, garbage out.

JTBD im deutschen Geschäftskontext

Die kulturelle Passung

Deutsche, österreichische und schweizerische Unternehmen haben eine natürliche Affinität zu JTBD — auch wenn sie die Methode oft noch nicht kennen. Warum?

Erstens: Die DACH-Ingenieurskultur denkt funktional. “Was muss das Produkt leisten?” ist eine Frage, die jedem Ingenieur vertraut ist. JTBD übersetzt diese Frage in die Kundenperspektive: “Was muss der Kunde leisten — und wie hilft unser Produkt dabei?”

Zweitens: DACH-Unternehmen schätzen Systematik und Reproduzierbarkeit. JTBD ist keine kreative Übung — es ist ein strukturierter Prozess mit klaren Regeln, definierten Outputs und messbaren Ergebnissen. Das passt zur Mentalität von Unternehmen, die ISO-zertifiziert sind und QM-Systeme ernst nehmen.

Drittens: In der DACH-Region haben viele Unternehmen langfristige Kundenbeziehungen. Sie kennen ihre Kunden — oft seit Jahrzehnten. JTBD nutzt dieses Beziehungskapital: Die qualitativen Interviews für die Job Map funktionieren besonders gut, wenn echtes Vertrauen zwischen Hersteller und Anwender besteht.

Die kulturellen Hürden

Gleichzeitig gibt es Hürden:

“Wir kennen unsere Kunden.” Das ist der häufigste Einwand. Und er ist oft falsch. Unternehmen kennen die Anforderungen, die Kunden artikulieren. Sie kennen die Beschwerden und die Feature-Wünsche. Aber sie kennen selten die 50 bis 150 Outcomes, die den gesamten Job beschreiben — und sie wissen fast nie, welche dieser Outcomes unterversorgt sind.

“Unsere Produkte sind technisch überlegen.” Das mag stimmen — und ist trotzdem kein Garant für Markterfolg. Technische Überlegenheit bei Outcomes, die Kunden als unwichtig bewerten, ist verschwendete Ingenieursleistung. JTBD hilft, technische Exzellenz dort zu konzentrieren, wo sie den größten Kundenwert schafft.

“Das ist zu akademisch.” JTBD hat tatsächlich einen theoretischen Unterbau. Aber die Methode ist in der Praxis alles andere als akademisch. Sie produziert konkrete, umsetzbare Ergebnisse: priorisierte Kundenbedürfnisse, identifizierte Wachstumssegmente, bewertete Produktkonzepte.

Praktische Anwendung: So starten Sie mit JTBD

Schritt 1: Den Job definieren

Versammeln Sie Ihr Kernteam — Produktmanagement, Engineering, Vertrieb — und stellen Sie eine einfache Frage: “Welchen Job erledigen unsere Kunden, wenn sie unser Produkt benutzen?”

Achten Sie auf die richtige Abstraktionsebene:

• Zu eng: “Ein Loch in Beton bohren” — das beschreibt die Nutzung Ihres Produkts, nicht den Job des Kunden.
• Zu breit: “Ein Gebäude errichten” — das umfasst zu viele Sub-Jobs, um handhabbar zu sein.
• Richtig: “Eine lasttragende Befestigung in einem Betonbauteil herstellen” — das ist der Job, auf den sich Ihr Produkt bezieht.

Schritt 2: Die Job Map erstellen

Führen Sie 10 bis 15 qualitative Interviews mit Anwendern durch. Nicht mit Einkäufern, nicht mit Entscheidern — mit den Menschen, die den Job tatsächlich ausführen.

Fragen Sie nicht: “Was gefällt Ihnen an unserem Produkt?” Fragen Sie: “Beschreiben Sie mir Schritt für Schritt, was Sie tun, wenn Sie [den Job] erledigen. Beginnen Sie bei der Planung und enden Sie beim Aufräumen.”

Kodieren Sie die Antworten nach dem Job-Map-Schema. Am Ende haben Sie eine funktionale Landkarte des Jobs mit 8 bis 12 Hauptschritten.

Schritt 3: Outcomes formulieren

Für jeden Schritt der Job Map formulieren Sie Desired Outcomes. Ziel: 8 bis 15 Outcomes pro Schritt, insgesamt 50 bis 150 für den gesamten Job.

Nutzen Sie die Formulierungsregeln: Richtung + Maßeinheit + Objekt + Kontext. Testen Sie jedes Outcome auf Lösungsunabhängigkeit: Beschreibt es, was der Kunde will — oder wie er es will?

Schritt 4: Quantitativ validieren

Erstellen Sie eine Befragung, in der Kunden jedes Outcome nach Wichtigkeit (1-5) und Zufriedenheit mit der aktuellen Lösung (1-5) bewerten. Berechnen Sie den Opportunity Score: Wichtigkeit + (Wichtigkeit - Zufriedenheit).

Outcomes mit hohem Score (über 10 auf einer 20-Punkte-Skala) sind Ihre Wachstumschancen.

Schritt 5: Strategische Schlüsse ziehen

Gruppieren Sie die Ergebnisse:

• Unterversorgte Outcomes (hohe Wichtigkeit, niedrige Zufriedenheit): Hier liegt Wachstumspotenzial. Neue Features, bessere Lösungen, neue Produkte.
• Überversorgte Outcomes (hohe Zufriedenheit, niedrige Wichtigkeit): Hier können Sie vereinfachen oder Kosten senken.
• Adäquat versorgte Outcomes: Hier muss nichts verändert werden — parken Sie diese.

Für eine vertiefte Darstellung des gesamten Prozesses lesen Sie den Leitfaden Innovationsberatung: Systematische Innovation im Unternehmen.

JTBD vs. andere Methoden: Die Abgrenzung

JTBD vs. Personas

Personas beschreiben, wer der Kunde ist. JTBD beschreibt, was der Kunde tun will. Eine Persona “Thomas, 45, Bauleiter, zwei Kinder” sagt nichts darüber aus, welche funktionalen Bedürfnisse Thomas bei der Bauleitung hat. JTBD ignoriert Thomas als Person und fokussiert auf den Job: “Eine Baustelle termingerecht und budgetkonform abwickeln.”

JTBD vs. User Stories

User Stories (“Als [Rolle] möchte ich [Aktion], damit [Nutzen]”) sind ein nützliches Format in der agilen Entwicklung. Aber sie sind oft lösungsgebunden: “Als Bauleiter möchte ich eine App, mit der ich den Baufortschritt fotografisch dokumentieren kann.” JTBD fragt tiefer: “Minimiere die Zeit, die benötigt wird, um den aktuellen Baufortschritt gegenüber dem Zeitplan zu bewerten.” Die Lösung muss keine App sein.

JTBD vs. Design Thinking

Eine detaillierte Gegenüberstellung finden Sie im Artikel Design Thinking vs. Jobs to be Done: Was funktioniert besser?. Die Kurzversion: Design Thinking ist stark in der Empathie-Phase, JTBD ist stark in der Analyse und Priorisierung. Die Kombination kann sinnvoll sein — wenn Design Thinking auf JTBD-Daten aufbaut, nicht auf Bauchgefühl.

Häufige Fehler bei der JTBD-Anwendung

Fehler 1: Den Job zu lösungsnah definieren

“Unseren CNC-Fräser bedienen” ist kein Job — es ist die Beschreibung einer Interaktion mit Ihrem Produkt. Der Job ist: “Ein Werkstück formgenau aus einem Rohteil herstellen.”

Fehler 2: Outcomes als Feature-Wünsche formulieren

“Eine intuitive Benutzeroberfläche” ist ein Feature-Wunsch, kein Outcome. “Minimiere die Zeit, die benötigt wird, um die Parameter für einen neuen Auftrag einzugeben” — das ist ein Outcome.

Fehler 3: Die qualitative Phase abkürzen

Manche Teams versuchen, Outcomes am Schreibtisch zu formulieren, ohne Kunden zu befragen. Das führt zu blinden Flecken — und zu Outcomes, die interne Annahmen abbilden, nicht Kundenbedürfnisse.

Fehler 4: JTBD als einmalige Übung behandeln

Der Job Ihres Kunden ändert sich selten. Aber die Wettbewerbslandschaft ändert sich ständig. Deshalb sollten quantitative JTBD-Studien regelmäßig wiederholt werden — idealerweise alle 2 bis 3 Jahre.

Ich unterrichte JTBD an der WU Wien und der RWTH Aachen. Die häufigste Reaktion von Studierenden und Führungskräften gleichermaßen: ‘Das ist so offensichtlich — warum machen wir das nicht schon längst?’ Die Antwort: Weil es eben nicht offensichtlich ist, solange man im Produkt-Paradigma denkt. Der Wechsel zum Job-Paradigma braucht einen bewussten Entscheidungsmoment.

Wann ist JTBD der richtige Ansatz?

JTBD eignet sich besonders, wenn:

• Ihr Markt gesättigt erscheint und Sie vermuten, dass es verborgene Wachstumschancen gibt.
• Ihre Produktentwicklung von internen Meinungen getrieben wird statt von quantifizierten Kundendaten.
• Sie in einen neuen Markt eintreten wollen und verstehen müssen, welche Bedürfnisse dort unterversorgt sind.
• Ihre Innovationsquote stagniert — viele neue Features, aber wenig messbarer Kundenwert.
• Sie eine Plattformstrategie entwickeln und verstehen müssen, welcher Job die verschiedenen Anwendungsfälle verbindet.

JTBD eignet sich weniger, wenn:

• Sie ein reines Commodity-Geschäft betreiben, in dem der Preis die einzige Differenzierung ist.
• Der Job so einfach ist, dass er keine sinnvolle Zerlegung in Outcomes erlaubt (das ist selten).
• Sie keine Bereitschaft haben, Ihre Produktstrategie auf Basis von Kundendaten zu überdenken.

Häufig gestellte Fragen