Ein ermächtigter Produt Owner, der kollaborativ mit einem ermächtigten Development Team iterativ und inkrementell Ergebnisse liefert, ist das Gütesiegel eines jeden agilen Produktentwicklungsprozesses.

-  von Geoff Watts: "Product Mastery: From Good to Great Product Ownership“

In meinen Augen kommt Ownership mit Entscheidungsbefugnissen. Die Frage, die sich also jeder Product #Owner stellen sollte, lautet: Wie viel Entscheidungsbefugnisse habe ich und wie viel möchte ich haben, um das Potenzial meiner Rolle voll ausleben zu können?  

Für die Reflexion darüber, wie viel Entscheidungsbefugnis zu hast, kannst du die 7 Delegation Level des Delegation Poker (eine Praktik aus dem Management 3.0) nutzen. Ich habe im folgendem Level 1 und Level 2 zusammengefasst, da du in beiden Situationen nicht in der Entscheidungsfindung beteiligt bist. 

Auf der #AgileCologne am 27.03.2020 habe ich mich mit einigen Teilnehmern genau hierzu ausgetauscht. Am Anfang steht die Bewusstmachung, welche Entscheidungen überhaupt getroffen werden. Anschließend haben wir diese Entscheidungen den sieben Leveln zugeordnet, um herauszufinden, wie viele Freiheit die Product Owner bei den einzelnen Entscheidungen haben. 

Erkenntnisse die wir hatten:

• Wie viel Befugnisse eine Product Owner hat, ist Abhängig von der konkreten Entscheidung.
• Mehr Befugnisse bei Entscheidungen die nur lokalen Einfluss haben vs. weniger Freiheit bei Entscheidungen die übergreifenden Einfluss haben. 
• Weniger Befugnisse bei Entscheidungen zur konkreten Budgetverwendung.  
• Weniger Freiheit, wenn Entscheidungen direkt den Endkunden betreffen (z.B. Preise, Verschiebung Release) 
• Ungeschriebene Best Practices oder stille Erwartungen sorgen für Unklarheit darüber, wie viel, was und wann ein Product Owner entscheiden kann.  
• Vielen Product Ownern ist nicht klar, welchen Idealzustand sie gerne hätten, sondern sie akzeptieren unbewusst die gegebene Situation. 
• Es werden meistens keine konkreten Absprachen mit den Führungskräften und Stakeholdern zu Entscheidungsbefugnissen getroffen. 

Entscheidungsbefugnisse sind sehr oft nicht klar geregelt und Erwartungen nicht ausdrücklich kommuniziert. In der Zusammenarbeit mit dem direkten Vorgesetzten schon eher. Schwierig fande ich es immer in der Zusammenarbeit mit Stakeholdern.

Beispiel: Ich war PO für eine Service-App. Jetzt sollte es einen neuen Prozess zur Buchung von Produkten in der App geben, den es auf der Website bereits gab.

Welche Entscheidungen treffe ich und welche treffen Personen aus den folgenden Bereichen? 

• Kundenservice (ist ja eine Service App)
• Produktmanagement (verantwortet die zu buchenden Produkte) 
• Web (verantworten den Prozess im Web)
• Digital Business (verantworten übergreifend die Performance von digitalen Bestellstrecken)  
• Brand / CI (Kundenansprache, Markenauftritt, ...) 

Die Priorisierung der Features war weniger das Problem, die ließ sich sehr gut aus den Unternehmenszielen ableiten. Es war eher unklar, welche inhaltlichen Entscheidungen ich als Product Owner selbst treffe und welche nicht.

Als Product Owner bin ich kein Subject Matter Expert und auf den Input der genannten Stakeholder angewiesen. Doch wer trifft am Ende die Entscheidung? Im Falle von ADVICE würde ich die Stakeholder konsultieren und am Ende selbst entscheiden. Im Falle von CONSULT würde ich den Stakeholdern einen Vorschlag unterschreiben und diese entscheiden.

Und möchte ich als Product Owber überhaupt die eine andere inhaltliche Entscheidung überhaupt treffen oder stark involviert sein? Oder lieber von mir aus gewisse Entscheidungen delegieren?  

Im aufgeführten Beispiel hat sich das Vorgehen herauskristallisiert, große Konzeptworkshops zu veranstalten, in dehnen ich Stellvertreter aus allen Bereichen eingeladen habe. Ich präsentiert meine Konzeptideen oder wir erarbeiteten diese gemeinsam und jeder Stellvertreter beschränkte sich mit seinen Anforderungen (STRONG ADVICE) auf seinen Kompetenzbereich. Ich folgte diesen "starken Ratschlägen" der Experten, insofern sie nicht im Konflikt mit den Anforderungen anderer Stakeholder (einschließlich UX/ UI und Development Team) standen.   

Mache dir den aktuellen Zustand bewusst: Nutze als Product Owner die sieben Delegation Level, um für dich zu reflektieren, welche relevanten Produktentscheidungen, unter Beteiligung welcher Personen, wie getroffen werden. Definiere dann, wie für dich der Idealzustand aussehen sollte und bestimme für jede Entscheidung dein Ziellevel. Diskutiere dann deine Wahrnehmung und Wünsche mit den beteiligten Personen und versuche mit ihnen eine Vereinbarung zu treffen, damit du deinem Idealzustand näher kommst.  

Wenn es um die Ermächtigung von Product Owner und Teams geht, ihre eigenen Entscheidungen zu treffen, ist eine der größten Herausforderung, dass andere Personen ihre Entscheidungsgewalt loslassen und übertragen müssen. Sollten deine Wünsche also nicht direkt auf offene Ohren stoßen, kann es daran liegen, dass sich deine Führungskräfte und Stakeholder vielleicht fragen: „Ist das Team vertrauenswürdig genug, um ihm diese oder jene Entscheidung zu übertragen?“. Der Lean-StartUp Zyklus aus Build-Meassure-Learn kann dir hierbei helfen. Ihr könntet ein Delegation-Experiment vereinbaren, indem dir für eine gewisse Zeit mehr Befugnisse zugesprochen werden und ihr nach dieser Zeit in einer Retrospektive besprecht, wie du den erweiterten Spielraum genutzt hast. Ihr vereinbart dann, den Entscheidungsspielraum weiter ausweiten oder wieder etwas zurück zujustieren. So könnt ihr einem gemeinsamen Idealzustand über die nächsten Sprints erreichen. 

Ich habe die für mich wichtigsten Inhalte aus dem Kapitel "Empowering" aus dem Buch "Product Mastery: From Good to Great Product Ownership“ von Geoff Watts in diesem Blogbeitrag zusammen gefasst.