Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03199.jsonl.gz/51

Wie du Product Owner werden kannst, weisst du bereits dank unseren Beiträgen (Teil 1, Teil 2), welche du bestimmt gelesen hast. Auch hast du dich mental auf deinen ersten Tag als Product Owner eingestellt - dank unserem Beitrag kennst du die Herausforderungen. Doch was sind deine Hauptverantwortungen? Welche Eigenschaften und Fähigkeiten werden von dir implizit erwartet?
Basierend auf langjährigen Erfahrungen und dem exzellenten Buch "Essential Scrum - A practical guide to the most popular agile process" von Kenneth S. Rubin, möchte ich dir eine Übersicht geben über die Hauptverantwortungen und vorteilhaften Merkmale eines Product Owners, eine Antwort auf die Frage nach einem sinnvollen Beschäftigungsgrad für einen Product Owner, eine Empfehlung aussprechen, wer sich zum Product Owner eignet, und zeigen, welche Möglichkeiten der Rollen-Kombination nach Scrum sich anbieten:
Der Product Owner ist das Zentrum der Produktentwicklung: Er ist durch die Organisation bemächtigt, Entscheidungen hinsichtlich der Maximierung der Wertschöpfung im Rahmen des Produkts zu fällen. Der Product Owner ist eine der drei kooperierenden Rollen, welche jedes Scrum-Team ausmachen (die anderen Rollen sind das Entwicklungs-Team und der Scrum Master).
Der Product Owner schaut gleichzeitig in zwei Richtungen - in die Richtung des Marktes als auch in jene der Produktentwicklung:
Auf der einen Seite muss der Product Owner die Bedürfnisse und Prioritäten der Stakeholder und der Kunden so gut verstehen, dass er als ihre Stimme fungieren kann. In diesem Moment nimmt der Product Owner die Rolle eines Product Managers ein und stellt sicher, dass die richtige Lösung entwickelt wird.
Anderseits steht der Product Owner mit dem Entwicklungs-Team im stetigen Austausch, berücksichtigt dessen Inputs und übernimmt die Priorisierung der Anforderungen. Er spezifiziert Test- und Abnahmekriterien und verifiziert diese am Produkt-Inkrement. Der Product Owner schreibt keine Detailtests, sondern stellt sicher, dass die High-Level-Tests geschrieben werden. In dieser Hinsicht ist der Product Owner teils Business Analyst und teils Tester.
Dies ist eindeutig eine Vollzeitbeschäftigung mit erheblicher Verantwortung:
Wenn Du nachstehende Grafik betrachtest, wirst du vermutlich denken, dass es als Einzelperson nicht möglich ist, wenn bloss eine Person all diese Verantwortungen übernimmt. Kann eine Person all diese Attribute haben, welche gefordert werden? Wirklich?
In den meisten Fällen kann - und sollte! - eine einzelne Person die Rolle übernehmen. Der Scrum Guide gibt einen Hinweis darauf:
"Der Product Owner ist eine einzelne Person, kein Komitee."
Unter bestimmten Umständen - je nachdem, wie gross das Produkt ist - kann es jedoch sinnvoll sein, die Aufgabe auf ein Team zu verteilen und mit mehreren Product Ownern zu operieren, wie z. B. mit einem Product Owner und mehreren Area Product Ownern wie bei LeSS Huge oder mit einem Chief Product Owner und mehreren Product Ownern wie bei Scrum@Scale o. Ä. Agilen Frameworks der Skalierung.
Quelle: Essential Scrum - A practical guide to the most popular agile process" von Kenneth S. Rubin
Nachstehende Grafik veranschaulicht wichtige Eigenschaften und Fähigkeiten, welche vorteilhaft für einen Product Owner sind:
Quelle: Essential Scrum - A practical guide to the most popular agile process" von Kenneth S. Rubin
Es mag weitere Merkmale eines guten Product Owners geben. Absolut. Jene, welche mir geläufig sind, lassen sich in vier Kategorien einteilen: Domänenkenntnisse, Soziale Kompetenzen, Entscheidungskompetenz und Verantwortung:
Der Product Owner ist ein Visionär, der eine Produktvision synthetisieren und das Team so leiten kann, dass das Team diese Vision erreicht. Eine Vision zu haben, bedeutet nicht, dass jedes Detail der Vision, oder der Weg zur Erreichung der Vision, völlig klar ist. Ein guter Product Owner weiss, dass nicht alles im Voraus klar ist, und ist bereit, das Vorgehen anzupassen, wenn Änderungen erforderlich sind. Iterativ und adaptiv halt.
Um bei der Entwicklung und Realisation von Visionen effektiv zu sein, sollte ein Product Owner über entsprechende Geschäfts- und Domänenkenntnisse verfügen. Denn es ist schwierig, ein effektiver Product Owner zu sein, wenn man neu und unerfahren in der Produktdomäne ist: Wie kann man Prioritäten zwischen konkurrierenden Anforderungen setzen, wenn man die Domäne nicht kennt? Genau.
Vorteilhaft ist, wenn der Product Owner gekonnt mit Methoden zur Entwicklung von Produkt-Visionen hantieren kann. Er sollte in der Lage sein, Visionen in konkrete Anforderungen überführen zu können, sodass die Anforderungen stets in Verknüpfung mit der Produkt-Vision stehen. Methoden wie Design Thinking, Business Model Canvas, Value Proposition Canvas, Story Mapping oder Personas unterstützen, um "from Vision to Task" Anforderungen zu entwickeln. Nachvollziehbarkeit ist das Ziel.
Ein Product Owner ist auch "die Stimme des Kunden". Dies erfordert ein gutes Verhältnis zu den Interessengruppen. Da es häufig mehrere Interessenvertreter gibt, welche widersprüchliche Bedürfnisse haben können, muss der Product Owner ein guter Verhandlungspartner und Konsensgeber sein. Methoden wie die Konsententscheidung aus Sociocracy 3.0 oder die gemeinsame Entwicklung von Ideen anhand der Methode "1-2-4-All" aus Liberating Structures unterstützen ihn dabei.
Der Product Owner ist das Bindeglied zwischen den Interessengruppen und dem Scrum-Team. In dieser Position benötigt der Product Owner:
um mit allen Seiten (Interessengruppen vs. Scrum-Team) zu arbeiten und Informationen an jede Gruppe in der entsprechenden Sprache zu übermitteln.
Ein guter Kommunikator weist folgende Eigenschaften auf:
Ein Product Owner ist ein starker Motivator. Wenn es hart auf hart kommt, kann der Product Owner die Leute daran erinnern, warum sie die Mühen in die Produktentwicklung investieren, und den Leuten helfen, eine enthusiastische Einstellung zu bewahren.
Ein starker Motivator "brennt" für das Produkt. D.h. aber auch, dass nicht jedes Produkt zu jedem Product Owner passt. Interessiert dich die Entwicklung eines Online-Fahrplans nicht? Dann solltest du nicht Product Owner dafür sein. Denn es wird dir schwerfallen, dich mit der notwendigen Empathie in die Herausforderungen der Nutzenden zu versetzen. Schwierig.
Der Product Owner muss von der Organisation befugt sein, auch kritische Entscheidungen zu treffen. Ein häufiges Hindernis für Unternehmen, die neu mit Scrum arbeiten, ist, dass die Person, die als Product Owner ausgewählt wurde, nicht befugt ist, wichtige Entscheidungen zu treffen. Eine solche Person kann nicht der Product Owner sein, diese Rolle entsprechend den Vorstellungen von Scrum wahrnehmen.
Die Organisation muss dem Product Owner die für die Entwicklung des Produkts notwendige Entscheidungsgewalt übertragen. Will die Organisation ein Konzept und ein Pflichtenheft umgesetzt sehen, ist sie mit der Rolle eines Product Owners - so wie es nach Scrum verstanden wird - falsch bedient. Es ist angezeigt, einen Projekt Manager zu suchen, denn:
Der Product Owner muss ermächtigt und fähig sein, schwierige Entscheidungen zu treffen. Dies geschieht in der Regel in Abstimmung mit den Interessengruppen. So muss er ständig eine Balance zwischen dem gewünschten Produkt-Umfang (Scope), der verfügbaren Zeit für die Entwicklung des Produkts (Time) und den zur Verfügung stehenden Ressourcen (Budget) verhandeln und finden. Diese Entscheidungen müssen rechtzeitig getroffen werden und sollten nicht ohne triftigen Grund rückgängig gemacht werden. Mit anderen Worten, der Product Owner sollte ein "entscheidender Entscheidungsträger" sein.
Weiter muss der Product Owner das richtige Gleichgewicht zwischen den Geschäftsanforderungen (Wichtigkeit) und dem technisch Machbaren (Machbarkeit) wahren. Obwohl das Scrum-Team als Ganzes für das Produkt und dessen Qualität verantwortlich ist, können naive Entscheidungen des Product Owners oft ein wesentlicher Faktor für einen schlechten Product/Market-Fit sein. Gekonntes Priorisieren ist gefragt.
Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.
Diese Verantwortung entbindet andere Mitglieder des Scrum-Teams nicht von ihrer eigenen Verantwortung, an der Generierung eines guten Return on Investment mitzuwirken. Der Product Owner steht jedoch im Fokus, wenn es darum geht sicherzustellen, dass die Ressourcen wirtschaftlich sinnvoll genutzt werden. Er muss dafür die Verantwortung übernehmen. Um dies sicherzustellen, hat der Product Owner viele Möglichkeiten, den Product Backlog aufzubauen und zu ändern, Prioritäten neu zu setzen, den Entwicklungsaufwand zu reduzieren oder das Vorhaben komplett zu stoppen.
Der Product Owner ist Mitglied des Scrum-Teams und ist sich daher bewusst, dass gute wirtschaftliche Ergebnisse ohne die Zusammenarbeit des gesamten Scrum-Teams nicht möglich sind. Der Product Owner versteht sich als Teil des Scrum-Teams und behandelt das Entwicklungs-Team und den Scrum-Master respektvoll. Er vertraut darauf, dass sie Partner sind, welche die Erreichung des gewünschten Ergebnisses unterstützen. Alle Mitglieder des Scrum-Teams sollten die Haltung der drei Musketiere teilen:
Einer für alle, alle für einen.
(Alexander Dumas d.Ä., aus dem Roman: "Die drei Musketiere")
Der Product Owner, der Scrum-Master und das Entwicklungs-Team sind eine Einheit, die gemeinsam am gleichen Ziel arbeiten. Halt einfach ein sog. Scrum-Team.
Ein Product Owner zu sein, ist ein Vollzeitjob: Zu versuchen, ein Product Owner in Teilzeit zu sein, ist ein Rezept fürs Scheitern. D. h. auch, dass der Product Owner sich dafür einsetzen muss, zur selben Zeit ein (1) Product Backlog zu pflegen.
Unternehmen, die nicht nach Scrum arbeiten, werden kaum bestehende Rollen mit der Bezeichnung "Product Owner" haben. Auch keine Titel. Es stellt sich dann die Frage: Wer innerhalb des Unternehmens soll die Rolle des Product Owners dann besetzen?
Wie erwähnt, muss der Product Owner in zwei Richtungen schauen: Einerseits hin zu den Stakeholdern und Kunden und anderseits hin zum Entwicklungs-Team. Die Rolle des Product Owners ist eine Verschmelzung von Autorität und Verantwortung, die historisch gesehen in mehreren traditionellen Rollen gefunden wird. Die Rolle des Product Owners umfasst Elemente der Rollen Produktmanager, Produktvermarkter, Projektmanager, Business Analyst und "Akzeptanz-Tester".
Wer genau die Rolle des Product Owners übernehmen soll, ist individuell - it depends ;). Und hängt definitiv von den beschriebenen Fähigkeiten ab.
Eine Möglichkeit, prädestinierte Kandidaten zu identifizieren, kann z. B. anhand der Strategie, welche für die Produktentwicklung eingeschlagen wird, gemacht werden:
|Art der Produktentwicklung||Prädestinierte Kandidaten|
|Produkte für den internen Gebrauch||Vertreter aus dem Geschäftsbereich, für den das Produkt entwickelt wird.|
|Produkte für den kommerziellen Gebrauch||Stellvertreter der eigentlichen Kunden und Benutzer, typischerweise Produktmanager, Produktvermarkter oder Projektmanager.|
|Ausgelagerte Produktentwicklung||Vertreter des Unternehmens, welches die Lösung bezahlt und für welches das Produkt entwickelt wird.|
|Komponentenentwicklung (Software-Architektur)||Typischerweise eine technische Person, welche technische Anforderungen am besten priorisieren kann.|
In extrem seltenen Ausnahmefällen - und wenn es die Kapazität erlaubt - kann ich mir vorstellen, einen Product Owner für zwei Scrum-Teams zu etablieren.
Voraussetzungen: Viel Erfahrung in der Bekleidung der Rolle eines Product Owners, etwa denselben Entwicklungsaufwand pro Entwicklungs-Team und thematisch eine enge "Verwandtschaft" der Produkte (Domäne). Ist das nicht gegeben? Abstand von der Idee nehmen!
Die Kombination dieser beiden Rollen liegt zwar nahe: Man weiss, was zu tun ist (Was?) und arbeitet an der Umsetzung mit (Wie?). Dies scheint auf den ersten Blick wenig problematisch zu sein.
Schauen wir uns die Hauptverantwortungen, die Eigenschaften und Fähigkeiten eines Product Owners an, wird es jedoch kapazitiv "eng". Im selben Moment noch die geniale, technische Lösung auszudenken und umzusetzen... hm, ja. Der Tag hat 24 Stunden... aber: Ich spreche keine Empfehlung aus. Dies scheint mir die "gangbarste" der drei Möglichkeiten zu sein. Aber auch eine schlechte.
Die Kombination dieser beiden Rollen mündet meistens in einem Interessenkonflikt: Als Product Owner will man mit allen - auch unschönen, "unlauteren" - Mitteln, Wertmaximierung betreiben. Als Scrum-Master ist man "der Hüter des Prozesses" von Scrum und strebt eine saubere Umsetzung des Frameworks an.
Beispiel gefällig: Der Product Owner kommt mit der Idee auf, das Sprint-Backlog während des laufenden Sprints zu erweitern, weil der Markt drückt. Als Scrum-Master versucht man, genau das zu verhindern, sodass fokussiert und mit Zug (Flow) an der Umsetzung eines Teil-Zieles gearbeitet werden kann. Ups. Schön doof. Also, sicherlich keine gute Kombination. Überhaupt nicht!
Ich empfehle dringend, einen Product Owner pro Produkt zu etablieren. Eins zu eins. Ich empfehle, die Rolle des Product Owners nicht zu unterschätzen und sie über die Zeit zu "entwickeln". Auch wenn ich eine Zertifizierung zum Product Owner grundsätzlich empfehlen kann: Dies ist der Startschuss für die verantwortungsvolle Rolle. Ähnlich einem Bootsschein: Wer den Bootsschein frisch machte, hat noch sehr wenig Erfahrung im Navigieren und Steuern eines Bootes. Wer schon einmal eine Segeljacht am Steg anlegen musste, kennt das mulmige Gefühl des "Ersten Mals". Oder wie war das bei dir beim ersten Mal rückwärts und seitwärts parkieren mit dem Auto? Tja. Die Erfahrung macht den Unterschied! Oder siehst du das anders?
Digitale Technologien und Innovationen, Digitale Strategie und Wertschöpfung, Geschäftsmodell Innovation, Entwicklung von Digitalen Produkten, Change Management, Organisationsberatung und -entwicklung, Innovation und Leadership, Agile und Resiliente Organisationen - da fühlen wir uns von dot consulting AG zuhause und unterstützen dich mit Leidenschaft!