• Decisive: Willing and able to make decisions with incomplete information, and to allow others to make decisions too.
•  Ruthless:  Maintaining a relentless drive to maximise value and minimise risk while staying focused on the vision.
• Informed:  Cultivating a voracious appetite to know the most possible about your product’s domain while being prepared to act with incomplete information.
• Versatile:  Being responsive to changing circumstances, both in terms of product development techniques and also leadership style.
• Empowering:  Creating a sense of shared ownership amongst all stakeholders and bringing people along with you on the journey.
• Negotiable:  Having faith in one’s vision while also being open to feedback and change.

Als Product Owner in einem Multi-Stakeholder Umfeld stehst du vor der Herausforderung, dass es immer mehr Anforderungen gibt als das Team Kapazitäten hat. Demnach musst du irgendwie mit den Stakeholdern aushandeln bzw. verhandeln, welche Wünsche in welcher Reihenfolge implementiert werden und welche gar nicht umgesetzt werden. Auch musst den Menschen klar machen, dass es nicht zielführend ist, solange alle Anforderungen zu entwickeln bis das Feature oder das Produkt nach ihrer Ansicht „perfekt“ ist. Stattdessen muss klar werden, dass es darum geht, ein hochwertiges Feature / Produkt in einer angemessenen Zeit, zu wirtschaftlichen Kosten zu liefern. Verhandeln bedeutet nicht zwangsläufig Kompromisse einzugehen oder Konsens erreichen zu müssen. Im Blogbeitrag Decisive - Als Product Owner entscheidungsfreudig sein wurde deutlich, dass du als Product Owner auch bereit sein musst, entgegen der Wünsche der Stakeholder zu entscheiden, wenn es im Sinne des Produktes ist. Strebe nach Exzellenz, doch lege den Wunsch nach Perfektion ab, im Sinne deiner Kunden und deines Unternehmens.

Als Product Owner repräsentierst du die Wünsche vieler Parteien und gleichzeitig, muss dir bewusst sein, dass du es nicht allen recht machen kannst. Sir Alec Issigonis der britische Designer des Mini sagte einst „A camel is a horse designed by a committee“. Damit wollte er ausdrücken, dass wenn du alle möglichen Wünsche zulässt, du am Ende ein Produkt erhältst, was viele Menschen gerade so zufrieden stimmt, aber niemanden so richtig glücklich macht. (Ob dies bei einem Kamel wirklich der Fall ist, kann ich nicht sagen. Für den Warenverkehr in Wüsten sind sie aber wohl ganz gut geeignet.)  

Ein Multi-Stakeholder Umfeld bietet viel Potential für Konflikte. Dies ist vor allem für „People Pleaser“ eine schwierige Herausforderung, da sie üblicherweise die Belange anderer vorne anstellen und alles vermeiden, was andere Menschen unzufrieden macht und was zu einem Konflikt oder zu Disharmonie führen könnte. Menschen denen das Nein sagen schwer fällt, können sich folgende Fragen bewusst machen:

1. Was denkst du passiert, wenn du Nein sagst?
2. Wie wahrscheinlich sind die Konsequenzen, wenn du realistisch darüber nachdenkst?
3. Wenn diese Konsequenzen eintreten würden, ist dein Nein dann wirklich die tatsächliche Ursache?

Bist du perfektionistisch veranlagt und stolz darauf? Verfeinerst du immer wieder das Design und wirst mit deinen Features nicht fertig, weil dir immer wieder eine neue Optimierung einfällt, die auch noch wichtig ist, bevor das Feature an die Kunden geliefert werden kann? Dann hindert dich diese Einstellung vermutlich gerade daran, ein exzellentes Produkt entwickeln. Als Product Owner musst du fähig sein zu entscheiden was wirklich wichtig ist und was nicht, um dein Produkt iterativ und inkrementell zu liefern. Exzellenz entsteht über die Zeit, indem du Nutzerfeedback verarbeitest und immer mehr lernst.

Wenn du einen starken Perfektionismus hast, dann fokussierst du dich vermutlich sehr auf das angestrebte Endergebnis und kannst die vielen guten Zwischenschritte auf dem Weg bis dahin nicht richtig genießen. Wenn du dir hohe Ziele setzt, ist das gut, um großartige Ergebnisse zu erreichen. Doch wenn diese Ziele unrealistisch werden, kann das schnell frustrierend werden und du verlierst die Freude. Wenn dir ein solches Verhalten bei dir auffällt, dann hole dir Hilfe aus dem Team, indem du jemanden bestimmst, der besonders darauf achtet, wo Dinge vereinfacht werden können. Entsprechendes Feedback kann diese Person z.B. im Refinement äußern. 

Anstatt an das perfekte Produkt zu denken, denke an das erste exzellente Teilstück des Produktes (minimal viable product). So kannst du ohne Kompromisse einzugehen, eine ganz bestimmte, wenn auch vielleicht kleine Gruppe von Menschen glücklich machen, anstatt eine große Gruppe von Menschen nur gerade so zufriedenzustimmen. Wenn du im Glauben das richtige zu tun, wohl bedacht und gleichzeitig schnell entschieden hast, dann hilft dir das Resultat dabei schnell herauszufinden was funktioniert und was nicht. Um den MVP zu definieren kannst du folgende Priorisierungstechniken nutzen:

• Pass the cards: Jedes Feature wird kollaborativ zusammen mit allen Stakeholder mit Prioritätspunkten bewertet (Details siehe unten)
• Free Market Priorisation: Eine Simulation eines Marktes, wo Stakeholder auf Features bieten können (Details siehe unten).
• Story Mapping für Releaseplanung des MVP, um Prioritäten transparent zu machen und zu verfeinern. Selbst wenn ein Feature durch die Priorisierung für das nächste Release vorgesehen ist, kann die Story Map mit weiteren Detailebene helfen, einzelnen Tasks und User Stories zu de-priorisieren, um den tatsächlichen MVP auszuarbeiten. 

Ablauf

1. Versammele eine gerade Anzahl an Stakeholden (mindestens acht).
2. Schreibe jedes zu priorisierende Feature auf eine Karte.
3. Verteile die ersten Karten, bis jeder Stakeholder genau eine Karte hat.
4. Die Stakeholder teilen sich in Paaren auf.
5. Die Paare diskutieren die beiden Featurekarten die sie haben.
6. Jedes Paar muss 9 Prioritätspunkte zwischen ihren beiden Karten aufteilen. Die vergebenen Punkte sollten den potenziellen Mehrwert des jeweiligen Features ausdrücken.
7. Wenn Karte A vermutlich mehr Wert liefert als Karte B, dann bekommt Karte A z.B. 7 und Karte B nur 2 Punkte. Die Punkte werden auf der Rückseite notiert.
8. Nun tauschen die beiden Personen die Karten unter einander und jeder sucht sich einen neuen Partner und bildet ein neues Paar.
9. Das Prozedere wird mindestens sieben Runden durchgespielt. Dann werden alle Punkte auf der Rückseite zusammengezählt und die Karten werden in der Reihenfolge der vergebenen Punkte geordnet.
10. Die restlichen Karten können ebenso priorisiert werden oder es wird versucht sie direkt einzuordnen, indem sie mit den ersten Referenzkarten verglichen werden.

Vorteile

• Eine simple, animierende und kollaborative Übung, die es jedem erlaubt Teilzuhaben und dennoch schnell Ergebnisse liefert.
• Anstatt dass jeder Stakeholder nur darüber spricht, wie toll seine Idee ist, muss er diese aus den Händen geben und sich mit anderen Ideen näher beschäftigen.

In diesem Priorisierungsspiel erhalten die Stakeholder ein fiktives Budget „development dollars“ und können damit auf die Features bieten die sie umgesetzt haben wollen. Alle Stakeholder erhalten gleichviel Budget, wenn alle gleich gewichtet werden. Wenn die Belange einige Stakeholder für das Produkt höher zu gewichten sind als die anderer, können sie auch mehr Budget erhalten. Auch bei der Vergabe echter Budgets gibt es im Unternehmen vermutlich unterschiede, je nachdem wie wichtig ein Bereich für die strategischen Ziele des Unternehmens ist. Daher sind die Stakeholder womöglich schon an eine Gewichtung ihrer Bereiche gewöhnt. Falls nicht, kann dies zu Konflikten führen und sollte durch höheres Management offiziell unterstützt werden. Zu Beginn wird die gesamte Geldmenge festgelegt und verteilt. Eine Liste an Features liegt breit und jeder Stakeholder kann sein Budget beliebig für Gebote verteilen. Alle sehen, wer wie viel auf welches Feature bietet. Das eigene Gebot kann entsprechend angepasst werden. Hat jeder Stakeholder so viel Budget verteilt wie er wünscht, endet die Gebotsphase. Die Gebote für jedes Feature werden addiert. Die grundlegende Annahme ist, dass Features mit höheren Geboten auch den höheren Mehrwert liefern, gemäß den Einschätzungen der Stakeholder die darauf geboten haben. Für die Features, die ein Gebot erhalten haben, ermittelt das Development Team die Entwicklungskosten. Aus dem Gebot und den Kosten wird der Return on Invest errechnet (ROI = Gebot / Kosten). Die Features werden anhand ihrer ROI Werte im Backlog geordnet. Sobald ein Feature entwickelt und geliefert wurde, werden die dafür investierten „development dollars“ wieder frei und werden gleichmäßig bzw. anhand der Gewichtung an die Stakeholder verteilt. Es kann dann sein, dass ein Stakeholder weniger als seine bisher eingesetzten development dollar nach der ersten Iteration zurückbekommt. Dies ist gewollt. Für die nächste Iteration der Entwicklung wird der Priorisierungsprozess wiederholt, die Stakeholder können ihre bisherigen Gebote anpassen und so auf die geänderte Ausgangslage reagieren.

Beispiel mit Geboten und ermittelten ROI Werten

Nachdem Beispiel im Bild werden die Features E, C, und B implementiert. Ob zuerst E oder C entwickelt wird, muss noch festgelegt werden. Ich würde E als erstes entwickeln, da es von allen Stakeholdern als relevant eingeschätzt wurde.

Vorteile

• Gewichtung der Stakeholder bildet politische und strategische Lage im Unternehmen ab und macht diese transparent.
• Kürzere Diskussionen. Es werden nur die Features diskutiert und durch das Team analysiert, die ein Gebot erhalten haben. ROI-basierte Ordnung der Backlog minimiert endlose Diskussionen.
• Fairer Prozess. Wurde in einer Iteration für einen Stakeholder kein Feature umgesetzt, hat dieser in der nächsten Iteration mehr development dollars verfügbar, um seinen Featurewunsch zu pushen.
• Skalierbare Methode für viele Backlog Items und viele Stakeholder.
• Methode ist transparent und nachvollziehbar für alle. Die Gebote der anderen sind sichtbar und die Stakeholder können auf Gebote anderer reagieren. Development dollar können untereinander gehandelt, getauscht und verliehen werden.
• Als Product Owner kannst du in das Marktgeschehen eingreifen, auch wenn du dies nur selten tun solltest, indem du zusätzliche development dollar freigibst und selbst auf ein zwingend erforderliches Feature bietest.

• Für welche persönlichen Werte möchtest du einstehen, auch wenn die Situationen schwierig sind? Bei welchen Werten möchtest du keine Kompromisse eingehen, auch wenn die Stakeholder viel Druck ausüben und unzufrieden sind?
• Wenn du ganz ehrlich mit dir selbst bist, wie oft gehst du den schwierigen aber korrekten Weg? Wie denkst du von anderen, die den schweren Weg gegangen sind? Wie denkst von dehnen, die immer den leichten Weg gehen?
• Gibt es einen Unterschied in dem was dein Kopf sagt was richtig ist und was dein Herz sagt? Schenkst du beiden Stimmen Beachtung?
• Wen könntest du in Diskussionen hinzuziehen, um die Verhandlung um eine Priorisierung zu vereinfachen?
• Wie sehr würdest du von dir behaupten, dass du ein Perfektionist bist?
• Wie hat dich Perfektionismus daran gehindert dich persönlich oder dein Produkt weiterzuentwickeln?
• Sind in deinem Team unterschiedliche Meinungen vertreten, die dir helfen eine Balance zwischen übermäßigem Perfektionismus und zu starker Simplifikation zu finden?
• Wenn du vor der Herausforderung stehst ein gänzlich neues Produkt zu entwickeln, dann frage dich nicht, wie sieht das perfekte Produkt aus, sondern, wie sieht das erste perfekte Teilstück des Produktes aus.
• Hast du in der Vergangenheit einmal einen Fehler gemacht, für den du hinterher dankbar warst, weil du daraus viel gelernt hast? Wie könntest du mehr solcher wertvoller Fehler machen?