KURZ ERKLÄRT
Jobs to Be Done hilft dir zu verstehen, welchen Fortschritt ein Unternehmen in einer konkreten Situation erreichen will. Für B2B SaaS reicht dafür keine Liste gewünschter Funktionen. Du brauchst den Arbeitszusammenhang, den Anlass für Veränderung und die Bedingungen, unter denen verschiedene Beteiligte eine neue Lösung akzeptieren würden.
Wie diese Entscheidung mit Positionierung, Markteintritt und Wachstum zusammenhängt, zeigt der übergeordnete Guide Go-to-Market für B2B SaaS: vom Marktverständnis zur umsetzbaren Wachstumsstrategie.
Eine Situation statt einer Persona untersuchen
Beginne bei einem kürzlich durchlaufenen Entscheidungsfall. Eine Rollenbeschreibung wie IT-Leitung erklärt noch nicht, warum gerade jetzt etwas verändert werden soll. Frage nach dem letzten schwierigen Arbeitsablauf und danach, welche Konsequenzen daraus entstanden. Der Christensen Institute beschreibt Jobs über angestrebten Fortschritt unter bestimmten Umständen und berücksichtigt funktionale, soziale und emotionale Aspekte. Übertrage diesen Blick behutsam auf den Geschäftskontext: Eine technische Aufgabe kann zugleich die Verantwortung einer Person gegenüber ihrer Geschäftsleitung berühren. Diese Dimensionen solltest du erfragen, statt sie aus dem Jobtitel abzuleiten.
Die Entscheidung als zeitlichen Ablauf erfassen
Lass dir den Weg vom ersten Unbehagen bis zur Entscheidung erzählen. Welche Zwischenlösung wurde ausprobiert? Wann kam eine weitere Abteilung hinzu? Was ließ die bisherige Lösung erneut attraktiv erscheinen? Notiere konkrete Wendepunkte und trenne die Aussagen der Beteiligten von deiner Interpretation. Die zeitliche Rekonstruktion verhindert, dass du eine elegante Erklärung nachträglich über einen widersprüchlichen Prozess legst. Wenn mehrere Personen beteiligt waren, sprich möglichst mit unterschiedlichen Rollen. Abweichende Erinnerungen sind ein Untersuchungsanlass und müssen nicht sofort zu einer gemeinsamen Geschichte geglättet werden.
Job, Ergebnis und Lösung auseinanderhalten
Beschreibe zunächst die Aufgabe unabhängig von eurem Produkt. Danach ergänzt du, woran die Beteiligten eine Verbesserung erkennen würden und welche Randbedingungen gelten. „Ein Dashboard nutzen“ ist bereits eine Lösung. „Vor einer Ressourcenentscheidung widersprüchliche Auslastungsdaten klären“ beschreibt eine Aufgabe genauer. Mögliche Erfolgskriterien wären nachvollziehbare Datenherkunft und eine abgestimmte Entscheidung. Prüfe, ob die Formulierung zu breit oder zu eng ist. Wenn nahezu jedes Unternehmen hineinpasst, fehlen wahrscheinlich Umstände. Wenn nur euer aktuelles Feature die Beschreibung erfüllen kann, habt ihr vermutlich eine Produktanforderung als Job formuliert.
Hypothetisches Beispiel: verlässliche Übergaben
Ein fiktiver IT-Dienstleister sucht vermeintlich ein neues Ticketsystem. In den Interviews berichtet die Serviceleitung jedoch von Übergaben zwischen Schichten, bei denen Zusagen an Kunden verloren gehen. Die Einkaufsabteilung möchte bestehende Verträge weiterverwenden, die Mitarbeitenden wollen keine doppelte Dokumentation. Der relevante Fortschritt lautet deshalb nicht einfach „Tickets zentralisieren“, sondern verbindliche Übergaben trotz wechselnder Zuständigkeiten ermöglichen. Das SaaS-Team prüft seine Integrationsfähigkeit und zeigt einen konkreten Übergabefall. Ob daraus ein Kauf entsteht, bleibt offen; die Untersuchung hat vor allem den entscheidenden Arbeitszusammenhang und die Grenzen eines passenden Angebots sichtbar gemacht. Mehr dazu im Leitfaden Der Status quo als wichtigster Wettbewerber.
Aus Erkenntnissen überprüfbare Entscheidungen ableiten
Ordne die Interviewergebnisse nach wiederkehrenden Umständen, Aufgaben und Hindernissen. Bewahre widersprechende Fälle auf. Verwende die Muster anschließend für eine konkrete Entscheidung: Segment enger wählen, Demoablauf verändern oder eine Integrationsannahme prüfen. Eine Jobformulierung ersetzt weder Marktgröße noch Wirtschaftlichkeitsprüfung. Sie hilft, Angebote und Botschaften an nachvollziehbaren Situationen auszurichten. Weise jeder Ableitung einen Beleg und eine offene Frage zu. So kann das Team erkennen, welche Erkenntnis aus mehreren Fällen stammt und wo lediglich eine plausible Hypothese für die nächste Forschungsrunde vorliegt. Mehr dazu im Leitfaden Kaufauslöser im B2B erkennen und sinnvoll einordnen.
Häufige Fehlanwendungen vermeiden
Verwandle Interviews nicht in eine Abstimmung über eure Roadmap. Kunden können wertvolle Situationen schildern, ohne eure beste technische Lösung vorzugeben. Vermeide außerdem die Vorstellung, ein Unternehmen habe nur einen einzigen Job oder alle Beteiligten verfolgten identische Ziele. Prüfe regelmäßig, ob neue Kundengruppen unter anderen Bedingungen handeln. Wenn ein Muster nur bei zufriedenen Referenzkunden erscheint, ergänze verlorene und vertagte Entscheidungen. Ein brauchbares Ergebnis ist eine präzise Erklärung mit Grenzen und Konsequenzen für den nächsten Test, kein universeller Satz, der dauerhaft auf jede Präsentation geschrieben wird.
INTERAKTIV / VOM LESEN ZUR ANWENDUNG
Drei Prüfpunkte für eure Umsetzung
Wähle einen Punkt und halte deinen persönlichen Lesefortschritt fest. Die Häkchen werden weder gespeichert noch übertragen und sind keine Bewertung eures Unternehmens.
PRÜFPUNKT 01
Job, Ergebnis und Lösung auseinanderhalten
Beschreibe zunächst die Aufgabe unabhängig von eurem Produkt.
Im Artikel vertiefen ↗PRÜFPUNKT 02
Hypothetisches Beispiel: verlässliche Übergaben
Ein fiktiver IT-Dienstleister sucht vermeintlich ein neues Ticketsystem.
Im Artikel vertiefen ↗PRÜFPUNKT 03
Aus Erkenntnissen überprüfbare Entscheidungen ableiten
Ordne die Interviewergebnisse nach wiederkehrenden Umständen, Aufgaben und Hindernissen.
Im Artikel vertiefen ↗Häufige Fragen
Ein Job pro Persona?
Nicht zwingend. Dieselbe Rolle kann in unterschiedlichen Situationen verschiedene Fortschritte suchen.
Sind Featurewünsche wertlos?
Nein. Nutze sie als Anlass, nach Aufgabe, Kontext und gewünschter Verbesserung zu fragen.
Reichen erfolgreiche Kunden?
Sie erklären erfolgreiche Fälle. Ergänze andere Entscheidungsverläufe, bevor du ein Muster verallgemeinerst.
Wie lässt sich „Eine Situation statt einer Persona untersuchen“ praktisch umsetzen?
Beginne bei einem kürzlich durchlaufenen Entscheidungsfall. Eine Rollenbeschreibung wie IT-Leitung erklärt noch nicht, warum gerade jetzt etwas verändert werden soll. Frage nach dem letzten schwierigen Arbeitsablauf und danach, welche Konsequenzen daraus entstanden.
Was ist bei „Die Entscheidung als zeitlichen Ablauf erfassen“ besonders wichtig?
Lass dir den Weg vom ersten Unbehagen bis zur Entscheidung erzählen. Welche Zwischenlösung wurde ausprobiert? Wann kam eine weitere Abteilung hinzu?
