Somebody Else’s Problem im Produktmanagement

Somebody Else’s Problem

SEP – Somebody Else’s Problem – ist eines dieser wundervollen Konzepte aus Douglas Adams „The Hitchhiker’s Guide to the Galaxy“, das in seiner vermeintlich überzogenen Darstellung exakt die Wahrheit widerspiegelt:
„The Somebody Else’s Problem field… relies on people’s natural predisposition not to see anything they don’t want to, weren’t expecting, or can’t explain.“
In dem Buch wird ein riesiges Raumschiff für die Besucher eines Cricket Spiels unsichtbar. Das Phänomen lässt sich aber auch in unserer Galaxy beobachten. In dem bekannten ‚the invisible gorilla‚ Experiment wird die Aufmerksamkeit während des Ansehens eines Videos so stark auf einen einzelnen Aspekt fokussiert, dass die Hälfte der Beobachter einen durch das Bild tanzenden Gorilla nicht wahrnimmt. Der Gorilla wird zum Somebody Else’s Problem. Der eigene Fokus darauf, die Pässe der weißen Mannschaft zu zählen, lässt alles andere unsichtbar werden.

SEP im Produktmanagement

Das SEP ist insbesondere auch im Produktmanagement ein maximal relevantes Problem. Eine zentrale Aufgabe des Produktmanagements ist es, Kundenprobleme zu identifizieren und zu lösen. Sowohl Design Thinking Ansätze als auch das Lean Product Playbook unterscheiden daher den Problem Space und den Solution Space. Der Problem Space beschreibt die Kundenperspektive und wie der Name schon sagt das zu lösende Problem. Erst wenn für diesen Bereich eine ausreichend klare Hypothese vorliegt, wird der Solution Space bearbeitet, d.h. eine Lösung erarbeitet. Die Lösung wird dann am Ende wieder mit dem Problem abgeglichen. So kann über mehrere Iterationen eine für das Problem passende Lösung erarbeitet werden. Dies folgt der Devise:
Verliebe Dich nicht in die Lösung, sondern in das Problem!
Lösungen wirken aber leider wie das oben zitierte Somebody Else’s Problem field für den Problem Space. Sobald wir eine Lösung im Kopf haben, vergessen wir das Problem. Das Kundenproblem wird zu Somebody Else’s Problem, der Kunde zu Somebody Else. Damit ist die Gefahr groß, dass wir an dem Kunden als eigentlichem Adressat unsere Produkte vorbei arbeiten und damit keinen Wert schaffen. Wir beschäftigen uns mit der Lösung, in die wir uns verliebt haben, das Problem verkommt zur Nebensache. Ohne das Problem können wir aber nicht mehr bewerten, ob unsere Lösung eine gute ist. Vielmehr tendieren werden wir dazu, die Fertigstellung der Lösung an sich zu feiern. Das ist der Grund, warum es soviel Produkte und Feature gibt, die nicht genutzt werden.

Hintergrund

Ein Ansatzpunkt für das SEP Phänomen lässt sich in „Thinking, Fast and Slow“ von Daniel Kahneman finden. Dieser unterscheidet (deutlich vereinfacht dargestellt) unseren Geist in ein System 1 und ein System 2. System 1 stellt die eher unterbewusst laufenden Prozesse da, System 2 die aktiven Denkprozesse, wobei beide Systeme nicht getrennt sind, sondern ein Gesamtgefüge darstellen. System 1 ist vor allem darauf ausgerichtet einen möglichst hohen Grad an Kongruenz zu erzeugen. Dabei ist System 1 anfällig dafür Lügen als Wahrheit zu akzeptieren, solange sie gut in den Gesamtzusammenhang passen. Um das zu verhindern, muss System 2 aktiv werden. Er schreibt dazu:

„System 1 is gullible and biased to believe, System 2 is in charge of doubting and unbelieving, but System 2 is sometimes busy, and often lazy.“

Wir tendieren also mit unserem System 1 dazu, unsere Lösung als die Lösung für ein Kundenproblem zu bewerten. Das Problem dabei immer wieder in den Vordergrund zu rücken und zu prüfen, ob Problem und Lösung wirklich übereinander passen, ist eine Anstrengung, die das grundsätzliche faule System 2 ausführen muss. Wenn wir das SEP Phänomen also bekämpfen wollen, um so wertvollere Produkte zu entwickeln, dann brauchen wir Tools, die unser System 2 immer wieder aufs neue aktivieren.

Lösungsansätze

User Stories sind ein geeignetes Format, um das SEP field zu durchbrechen. Das klassische Format einer User Story lautet:
Als <Benutzerolle>
will ich <das Ziel>,
so dass <Grund für das Ziel>.
Dabei kann die <Benutzerrolle> als Kunde betrachtet werden, der <Grund für das Ziel> als Problem. Beides zusammen bildet die Basis für den beschriebenen Problem Space. Das <Ziel> repräsentiert die Lösung bzw. den Solution Space. Der Trick ist nun, dass in agilen Methoden durch das Format der User Story vor allem die Lösung zur Diskussion gestellt wird. Agile Teams setzen nicht einfach die gefragte Lösung um. Sie hinterfragen, ob es basierend auf dem dargestellten Problem Space, nicht vielleicht noch eine bessere Lösung gibt. User Stories werden so zu einem Tools, das die Interaktion von Individuen unterstützt und sind damit voll im Einklang mit dem agilen Manifest.
Auch Minimum Viable Products (MVP) sind ein geeignetes Tool,  um sich auf Kundenprobleme zu fokussieren. Richtig angewendet zielen diese darauf ab, ein Produkt zu entwicklen, dass so gerade eben ausreicht, um die Problemlösungskompetenz eines neuen Produkts oder Feature vom Kunden einwerten zu lassen. Der Build-Measure-Learn Zyklus führt dabei die Erkenntnisse aus dem User Feedback immer wieder zurück auf die nächste Produkt-Iteration. Leider gilt aber sowohl beim MVP als auch beim Einsatz von User Stories: A fool with a tool is still a fool.

Fazit

Der Kampf gegen das Somebody Else Problem im Produktmanagement ist ebenso schwierig wie notwendig, wenn wir wertvolle Produkte erstellen wollen. Menschen neigen dazu, sich in Lösungen zu ergehen. Gegen diesen Drang müssen wir sehr aktiv ankämpfen. Selbst Leute vom Fach, die Agilität und Kundenzentrierung im Grundsatz verstanden haben, müssen immer wieder auf das Problem fokussiert werden. Vielleicht hilft es ja ein Handtuch griffbereit zu haben, das mit der Aufschrift „don’t panic and mind the problem“ versehen ist.

Kommentar verfassen