Jobstories – Die Kundenperspektive einbrennen

Sharing: facebook, twitter

JTBD

Anforderungsmanagement ist schwierig. Ganze Regalmeter kann man dazu lesen und doch nicht wissen was man machen soll und wie das geht. Und doch geht es in den meisten Büchern um die Details. Immerhin: Inzwischen haben sich User Stories als kundennahes Beschreibungsformat durchgesetzt.

Als <Rolle> möchte ich <Aktion>, um <Nutzen>

Template Userstory

Zentrales Merkmal von User Stories ist, dass sie Lösungen beschreiben. Sie haben aber auch zwei Probleme: sowohl die Rolle (Persona) als auch die gewünschte Aktion (Feature) sind meistens geraten, Annahmen. Damit sind sie ein gutes Tool zur Beschreibung von Features, die wir entwickeln lassen wollen und haben damit einen guten, natürlichen Platz nah am Ende des Prozesses, direkt bei der Erstellung des Produktes. (Auch hier muss man allerdings sagen, dass sie nicht für alle Anforderungen geeignet sind, sondern eben nur für funktionale Anforderungen. Ein reines visuelles Redesign beschreibt man besser anders: eben visuell.) Was aber machen wir in frühen Phasen, in denen wir noch herausfinden müssen, welches Produkt wir bauen wollen / müssen? In diesen Phasen mit User Stories zu arbeiten ist üblich, bringt aber die riesige Gefahr mit sich, den ohnehin schon vorhandenen Drang, hin zu früher Lösungsorientierung, noch weiter durch das Tool zu zementieren. Hier kommen Jobstories ins Spiel: Sie bilden erkannte, zu befriedigende Kundenbedürfnisse ab und sind damit eine gute Lösung für frühe Projekt- oder Produktphasen.

Lösungsorientierung – der Killer

Lösungsorientierung ist die Hölle der Produktentwicklung. Aber wir alle bekommen Lösungsentwicklung in unserer Ausbildung eingebrannt: „Ich will keine Probleme hören, ich will Lösungen!“ Dementsprechend schwer fällt es uns allen, dieser Falle aus dem Weg zu gehen.

Uns allen fällt es schwer, sich ständig von den von sich schon klammheimlich sich aufdrängenden Lösungen fern zu halten. In unseren Workshops beobachten wir es auch immer wieder: Sich erst einmal auf die Probleme zu fokussieren ist und bleibt schwer. In Lösungen zu denken liegt uns mehr.

Auch bei Kundeninterviews ertappe ich mich und andere immer wieder dabei, wie wir oftmals Bestätigung für unsere gedachte Lösung haben wollen, anstatt einfach zuzuhören und ganz offen wahrzunehmen, welche Probleme und Bedürfnisse eigentlich ganz offen ausgesprochen werden. Ein moderner Klassiker.

Auf einer anderen Ebene ist es so, dass Vorgesetzte oft direkt die Lösungen delegieren. „Ich war auf Messe XYZ, alle bauen gerade an ZZZ, wir brauchen das auch.“ Hier wird schon deutlich, dass die Reflektion warum wir etwas „auch brauchen“, also das Verständnis, was das Feature bewirken soll, entweder nicht da ist oder nicht kommuniziert wird. Das heißt aber oft, dass wir uns an Lösungen abarbeiten ohne dass das Problem klar und tief verstehen zu können. Dann können wir in der Umsetzung nicht gut mitdenken. Manchmal ist auch nicht klar, ob die von uns so verlangte Lösung überhaupt ein Problem löst. Besser wäre es, das erkannte und validierte Problem zu delegieren und das Team die beste Lösung finden zu lassen.

Kurz: Wir lieben Lösungen! Das hilft aber nichts, wenn wir nicht wissen welche Probleme wir lösen, warum wir sie lösen und für wen wir sie lösen. Aber nur aus diesem Verständnis heraus können wir erfolgreich nachhaltig Produkte – ansonsten warten wir auf den Zufall. Weil mir das immer wieder begegnet, habe ich darüber nachgedacht, wie man dem begegnen kann und was mit dabei geholfen hat ist das einfache Konzept der Jobs To Be Done (JTBD).

Ein Job To Be Done ist das was ein Produkt für einen Kunden erledigt, die so dass es dem Kunden es den Kunden wert sind, Geld für dieses Produkt oder diesen Service zu bezahlen. Genauer noch ist es so, das der JTBD das ist was der Kunde als mentales Bild (bewusst oder unbewusst) zu diesem Produkt abgespeichert hat. Umgekehrt: Wenn ein Kunde für einen Service oder ein Produkt bezahlt, dann weil man für ihn in einem bestimmten Kontext bei der Erfüllung eines Bedürfnisses eine große Hilfe ist. Man erledigt einen Job für ihn, den JTBD. JTBD ist ein wunderschönes, einfaches Konzept von Clayton Christensen, um sich auf den Wert zu konzentrieren den man für Kunden schafft. Weil es so einfach ist, wirkt das Ganze erst einmal abstrakt und / oder trivial zugleich. Ein aufschlussreicher Klassiker, der dies einfach verständlich macht ist dieses folgende Video von Clayton Christensen zum Thema Milk Shakes.

So schreibt man einen JTBD als Anforderung in Form einer Jobstory auf:

When ______ (Situation), I want to _____ (Motivation), so I can ______(Outcome)

Template für Jobstories

Die Jobstory sieht also ähnlich aus wie eine Userstory, macht aber etwas ganz anderes: Sie formuliert ein Kundenproblem oder Bedürfnis, dessen Lösung weder klar noch erarbeitet ist! Man startet von einer relativ stark validierten Problemhypothese, formuliert als persönliches Problem, und hat nun die Möglichkeit, das gesamte Team (und mehr) in die Erarbeitung der Lösung zu involvieren. Das sorgt zum einen für ein hochgradiges und tiefes Verständnis der Kundenprobleme im Team, zum anderen aber auch für hohes Committment bei der Lösungsumsetzung (Entwicklung), da man sich ja bei der Definition der Lösung einbringen konnte.

JTBD sind wirklich einfach zu verstehen. Eine schöne Eigenschaft von JTBD ist, dass sie uns auch dabei helfen können, vollkommen gegensätzliche Kundenaussagen in einen Kontext zu bringen und damit den scheinbaren Widerspruch aufzulösen. Nehmen wir etwa einen Bankkunden, der meist von der Bank in Ruhe gelassen werden will, in bestimmten Situationen aber ganz eng von der Bank betreut werden will. Die Bank verwirrt die Unterschiedlichkeit der Kundenerwartung, weil für die Bank Kunden die kommen einfach Kunden sind, sie eben kommen. Der Kunde selbst aber kommt in vollkommen unterschiedlichen Situationen zur Bank:

  • Einfach Geld abheben: „Der Bankberater soll mich einfach in Ruhe lassen.“
  • Kreditberatung beim Wohnungskauf: „Lieber Berater, erledige so viel wie möglich für mich, mach alles für mich und weise mich auf alle Möglichkeiten und Risiken hin“.

Stufen von Anforderungsmanagement

Gehen wir einmal die Stufen von Anforderungsdefinitionen durch und welche Wirkung sie haben:

Klassisches Anforderungsmanagement

Hier rennt der PO durch das Haus, sammelt für eine vorgegebene Lösung Anforderungen aus allen Abteilungen zusammen, moderiert ein bisschen und am Ende gibt er die Anforderungen in Paketen an die Entwickler weiter. Das ist kein sehr erfüllender Job, und die Gestaltung des Produktes hat wenig mit einem selbst zu tun. Möglicher Erfolg oder Misserfolg ist auch kaum vom PO selbst zu beeinflussen. Tatsächlich ist in diesem Kontext ein PO am ehesten ein toter Briefkasten, eventuell ein Projektmanager.

Agiles Anforderungsmanagement

Teile des Jobs sind ähnlich wie im vorigen Beispiel. Immerhin werden die angebotenen Features jetzt aus Kundensicht formuliert. Das klingt schon mal kundenorientierter und es involviert in der Kommunikation die Entwickler besser. Im Kern ist eine User-Story aber oft noch eine (differenziertere) Lösungsbeschreibung.

Jobstories

Das Wesentliche an der Jobstory ist, dass sie direkt bei den Research-Ergebnissen und Kundenbedürfnissen startet und noch nicht in Richtung der Lösung schielt – diese ist noch – im besten Fall gemeinsam – zu erarbeiten.

Diese Form der Anforderungsdefinition sorgt für die richtige Perspektive in der Beschreibung und hilft uns, die Beschreibung des Kundenproblems zu erzwingen und ins Zentrum des Handels stellen. Zum anderen habe ich festgestellt, dass diese sehr positive Variante von Problembeschreibung den meisten wesentlich leichter fällt als die trockene, tiefe Beschreibung von Kundenproblemen als Problem Statements. Denn Jobstories scheinen schon mehr in die Richtung einer Lösung zu zeigen – ohne dies aber wirklich zu tun.

Der positivste Effekt im Umgang mit Jobstories ist allerdings, dass wir eine Umgebung schaffen, in der die erzwungene Beschreibung von Kundenproblemen dafür sorgt, dass wir generell Arbeiten ausgehend Kundenproblemen starten und nicht von erträumten Lösungen Fr die wir eventuell gar kein Problem identifiziert haben.

 Ein einfaches, kleines Framework

Jobstories framework

Insgesamt fügt sich das also wie folgt in einen Zusammenhang:

  • Wir starten mit Research, werden auf Verbesserungsmöglichkeiten aufmerksam (Hunch),
  • Diese validieren wir und formulieren den JTBD als Jobstory.
  • Dann suchen wir Heuristiken um den JTBD zu lösen
  • Aus den Heuristiken versuchen wir ein Rezept zu verallgemeinern
  • Der Rest der Arbeit ist dann, mögliche Lösungen für den JTBD zu finden und zu validieren.
  • Die Lösung, die wir am Ende bauen, stellen wir dann wieder als User Story dar.
  • Die Userstory wird implementiert.

Wenn man das einmal macht, hat man auch ein wunderbares Handwerkszeug um überzeugendes Storytelling vom Erkennen der Möglichkeit bis zur Lösung zu betreiben. Das sorgt dann für gemeinsames Verständnis vom Manager, der sein Committment gibt bis zu Operations, welche die fertige Lösung deployen.

Alles zusammen liefert ein wunderbares Framework welches Research in ein Produkt überführt, indem Probleme erkannt werden, denen eine Lösung gegenüber steht, jeweils ausgedrückt in Jobstory und Userstory.



Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>