Wenn die Praxis härter ist als die Theorie: Wie du als Product Owner einen Weg aus Zwickmühlen findest, wenn gängige Entscheidungsfindung versagt

Es ist kein Geheimnis: Das Studium bereitet einen nicht auf die wahre Arbeitswelt vor.

Zumindest hat es das bei mir nicht getan. Nach meinem Studium begann ich 2013 als Entwickler. Nur wenige Monate später bot sich mir die Gelegenheit, als Product Owner zu arbeiten. Diese Chance nutzte ich.

Ich habe einen Abschluss in Mathematik und Wirtschaftsinformatik und kam aus einer Welt der Einsen und Nullen – einer Welt, in der es richtige Lösungen gibt, sofern man nur lange genug darüber nachdenkt. Ich kam nicht aus einer Welt, die von menschlichen Bedürfnissen, zwischenmenschlicher Dynamik, Finanzen oder Unternehmenspolitik geprägt war.

In dieser neuen Welt war es nun meine Aufgabe, Entscheidungen zu treffen.

Das einzige Problem?

Ich hatte keine Ahnung, wie ich gute Entscheidungen treffe.

Ich wusste lediglich, dass die Aufgabe des Product Owners darin besteht, die bestmögliche Entscheidung zu treffen. Und worüber entschied ich? Über nicht weniger als die nächste Investition meines Unternehmens. Denn: Ich musste entscheiden, an welchem Feature die Entwickler als Nächstes arbeiten sollten.

Was mich unter großen Druck setzte.

Im Studium war das noch anders.

Während meines Mathematik- und Wirtschaftsinformatikstudiums erkannte ich schnell, dass ich eigentlich nicht durchfallen konnte. Die Antwort auf jede Prüfungsfrage stand in einem Buch. Um die Prüfungen zu bestehen, musste ich mich lediglich mit dem Inhalt dieser Bücher vertraut machen. In einigen Klausuren durften wir sogar Bücher mitbringen. Wenn ich an die Prüfungen zurückdenke, dann musste ich nie zwischen gleichwertigen Optionen abwägen. Ich musste mir nie überlegen, wie ich Entscheidungen treffe. Ich habe nicht daran gedacht, welche Kriterien mir dabei helfen könnten. Meine Aufgabe als Student bestand darin, die richtige Lösung zu finden. Ich verwende bewusst den Begriff „finden“, da ich sicher sein konnte, dass die richtige Lösung existierte.

Aber wie sollte ich mich entscheiden, wenn die Antworten in keinen Büchern zu finden waren?

Mehr noch:

Für die meisten Fragen gab es viele Antworten und alle schienen gleich gut – oder sollte ich eher sagen, gleich schlecht?

Ich erinnere mich noch an einen Sprint Review. Dort zeigte ich stolz einem Nutzer, dass er sich nun im System anmelden und einen Account erstellen kann. Der Key-User entgegnete daraufhin: „In diesem Zustand werde ich diese Anwendung niemals verwenden.“ Natürlich kamen mir daraufhin Zweifel. Habe ich die richtige Entscheidung getroffen? Hätte das Team stattdessen besser die Übersetzungsfunktion entwickeln sollen? Wäre dies als Sprint-Ziel lohnender gewesen?

Es gibt viele sinnvolle Methoden, die uns bei der Entscheidungsfindung helfen können.

Häufig befinden wir uns in Situationen, in denen wir tatsächlich eine Wahl haben. Doch es ist nicht direkt ersichtlich, welche Option die bessere Wahl ist. Für diese Situationen gibt es eine ganze Reihe nützlicher Methoden, die der ein oder andere vielleicht sogar im Studium gelernt hat.

Diese Methoden haben auch mir bei meiner Arbeit als Product Owner geholfen:

• Pro- und Kontraliste: Bei einer Pro- und Kontraliste notieren wir in separaten Spalten alle Argumente und Fakten, die für oder gegen eine Entscheidung sprechen. Die beste Entscheidung ist diejenige, die die meisten Pro- und die wenigsten Kontraargumente hat.
• Kosten-Nutzen-Analyse: Ein Spezialfall der Pro- und Kontraliste ist die Kosten-Nutzen-Analyse. Hier ermitteln wir die Kosten und den Nutzen jeder Alternative. Die beste Entscheidung ist diejenige, die den größten Nutzen bei gleichzeitig geringsten Kosten birgt.
• Die 10-10-10-Methode: Diese Methode hilft, die langfristigen Konsequenzen einer Entscheidung abzuwägen. Man fragt sich, welche Auswirkungen die Entscheidung in 10 Minuten, in 10 Monaten und in 10 Jahren haben wird. Die beste Entscheidung ist diejenige mit den langfristig positivsten Auswirkungen.
• Kritischer-Pfad-Analyse: Der kritische Pfad bestimmt die Mindestdauer, bis das Projektziel erreicht werden kann. Die Vorgänge auf dem kritischen Pfad hängen zeitlich oder logisch voneinander ab. Deshalb müssen sie nacheinander oder pünktlich abgeschlossen werden, sonst ist die geplante Projektdauer gefährdet. Die beste Entscheidung berücksichtigt die Elemente auf dem kritischen Pfad.

Als Product Owner haben wir jedoch selten eine echte Wahl.

Ein Beispiel:

Die Entwicklung eines neuen Features wird wahrscheinlich einen zusätzlichen Umsatz von 50 000 EUR erzeugen, da wahrscheinlich 5 % mehr Neukunden gewonnen werden. Die geschätzten Entwicklungskosten für das Feature betragen 10 Arbeitstage. Wird ein Compliance-Feature bis zum Ende des Monats nicht entwickelt und veröffentlicht, wird wahrscheinlich eine Strafe von 25 000 EUR fällig. Die geschätzten Entwicklungskosten betragen ebenfalls 10 Arbeitstage.

Was würdest du jetzt tun? Würdest du dich für die wahrscheinliche Umsatzsteigerung entscheiden oder versuchen, die Strafe zu vermeiden?

Ich weiß, was du denkst:

Selbst wenn wir eine Wahl haben, sind beide Alternativen schlecht.

Genau darauf will ich hinaus.

Anders als im Studium haben Product Owner oft keine echte Wahl.

Bei vielen unserer Entscheidungen stecken wir in einer Zwickmühle: einer Situation, die zwei Entscheidungsmöglichkeiten bietet, die beide zu einem unerwünschten Ergebnis führen.

Betrachten wir noch einmal das Beispiel, das ich dir geschildert habe. Entscheidest du dich für die Entwicklung des neuen Features, wirst du wahrscheinlich im kommenden Monat eine Strafe zahlen müssen. Lässt du das Compliance-Feature entwickeln, wirst du weniger Neukunden gewinnen. Egal, wie man es dreht und wendet, dieser Monat wird unangenehm enden. Du wirst dich wahrscheinlich vor dem Management erklären müssen.

Aussichtslos, oder?

Genau dies charakterisiert eine Zwickmühle.

Eine solche Situation lähmt dich. Sie lähmt dein Handeln, erstickt deine Kreativität und raubt dir die Motivation, dich dem Konflikt zu stellen.

Gibt es einen Ausweg aus der Zwickmühle?

Ja. Ich verrate ihn dir:

Du musst die Situation transformieren.

Transformation ist die einzige Möglichkeit, da du einer echten Zwickmühle nicht ausweichen kannst. Nehmen wir noch mal das Beispiel von oben. In unserer Situation würde Ausweichen bedeuten, die Entscheidung zu vertagen. Dies ist jedoch keine Option, da die Strafe bereits am Monatsende fällig sein kann. Wenn du nicht ausweichen kannst, erfordert die Lösung Kreativität und den Mut, neue Alternativen in Betracht zu ziehen.

Das meine ich mit „Transformation“.

Oder anderes ausgedrückt: Du musst deinen Handlungs- und Entscheidungsraum erweitern.

Erweitere deinen Handlungsraum: Die Tetralemma-Methode

Ein bewährtes Denkwerkzeug für bessere Entscheidungsfindung.

Es geht auf den buddhistischen Philosophen Nagarjuna des 2. Jahrhunderts zurück. Wir können das Tetralemma als eine sich verändernde Landschaft verstehen. Wir durchwandern diese Landschaft. Dadurch verändern wir sie. Dies können wir in fünf Schritten tun.

Eine kleine Vorwarnung: Ab dem dritten Schritt sind viel Kreativität und Fantasie gefragt:

1. Das eine: Entscheidung für Alternative A.
2. Das andere: Entscheidung für Alternative B.
3. Beides: Entscheidung für Alternative A und B. Hierzu gehören nicht nur der Kompromiss, sondern auch der Scheingegensatz, die übersummative Verbindung, die paradoxe Verbindung usw.
4. Keines: Entscheidung, weder Alternative A noch Alternative B zu wählen. Durch die Änderung des Kontexts verlieren Alternative A und B ihre strikte Geltung.
5. Keine der bisherigen und auch keine weiteren Alternativen: Der Kontext der ursprünglichen Zwickmühle wird ganz verlassen und erfordert keine Entscheidung mehr, sondern löst sich auf.

Diese Schritte sind sehr abstrakt formuliert. Ich wende sie jetzt auf unser Beispiel an. So kannst du sie sofort nachvollziehen.

1. Das eine: Du entscheidest dich für die Entwicklung des neuen Features, das 50 000 EUR zusätzlichen Umsatz bringt. Die Strafe von 25 000 EUR für das Fehlen des Compliance-Features wird als Betriebskosten akzeptiert.
2. Das andere: Du entscheidest dich für die Entwicklung des Compliance-Features, um die Strafe von 25 000 EUR zu vermeiden. Der mögliche zusätzliche Umsatz durch das neue Feature wird auf später verschoben.
3. Beides: Du schaffst es, beide Features parallel oder in einem übersummierenden Ansatz entwickeln zu lassen. Du könntest etwa externe Softwareentwickler anheuern oder Überstunden einplanen.
4. Keines: Das Team könnte eine einfachere und kostengünstigere Lösung entwickeln, um die Compliance kurzfristig ohne ein vollständiges Feature zu erfüllen. Etwa durch die vorübergehende Deaktivierung bestimmter Funktionen, die nicht Compliance-konform sind.
5. Keine der bisherigen und auch keine weiteren Alternativen: Änderung des Produktangebots, welche die Notwendigkeit für beide Features überflüssig macht. Zum Beispiel durch eine Neuausrichtung auf B2C statt wie bisher B2B.

Dieses Beispiel zeigt die Tetralemma-Methode in Aktion.

Im Sprint von damals habe ich mich für die Möglichkeit zur Anmeldung entschieden. Die Übersetzungsfunktion hatte ich erstmal als weniger wichtig eingestuft. Die negativen Auswirkungen meiner Wahl erfuhr ich direkt durch die Rückmeldung des Key-Users. Ich nehme an, dass er sich auch beschwert hätte, wenn wir die Übersetzungsfunktion zuerst entwickelt hätten, da er sie nur eingeschränkt hätte nutzen können, wenn er sich nicht im System hätte anmelden können.

Eine typische Zwickmühle.

Da ich damals die Tetralemma-Methode noch nicht kannte, habe ich die Zwickmühle „gelöst“, indem das Team eine Funktion nach der andern entwickelt hat und wir für einige Zeit mit den negativen Konsequenzen der Entscheidung lebten. Rückblickend war es vertretbar, da die Zwickmühle ein weniger großes Risiko für das Unternehmen darstellte, anderes  als das fiktive Beispiel des Compliance-Features.

Hätte ich die Tetralemma-Methode bereits gekannt, dann hätte ich mir allerdings andere Fragen bei der Entscheidungsfindung gestellt. Und hoffentlich eine Wahl getroffen, die mir einige über Monate verärgerte Key-User erspart hätte, dessen Vertrauen in unser Produkt ich wieder mühsam herstellen musste. Ich hätte mich nicht gefragt, ob die Anmeldungs- oder die Übersetzungsfunktion in diesem Sprint das Ziel darstellen soll.

Sondern:

Wenn wir weder die Anmeldungs- noch die Übersetzungsfunktion entwickeln, wie kann der Nutzer dann sein Problem lösen? Oder was können wir davon lernen, wie die zukünftigen Nutzer das Problem bereits jetzt lösen?

Diese Frage eröffnet neue Denkansätze, erfordert aber auch Kreativität und Mut bei der Beantwortung. Damit hätte aber der Entscheidungsraum erweitert und vielleicht die Zwickmühle verlassen werden können, um doch noch zu einer gute Entscheidung zu kommen. Zu einer Entscheidung, die alle Parteien von Anfang an zufrieden gestellt hätte.

Dieser Mut, kreativ neue Wege zu gehen, das macht am Ende die Arbeit eines Product Owners wirklich aus.

Wenn du mehr darüber lernen möchtest, dann besuche mein „Professional Scrum Product Owner - Advanced“-Training. Dort widmen Peter Götz und ich diesem Thema einen ganzen Nachmittag.