Produkt Manager vs. Product Owner

In vielen großen Unternehmen, die agile Methoden einführen oder eingeführt haben, findet man neben der Rolle des Product Owners auch die des Produkt Managers. Warum ist das so und ist das sinnvoll?

Nun, in meinem agilen Weltbild gehen die Aufgaben eines Produkt Managers nahezu vollständig in der Rolle des Product Owners auf, wobei einige Teilaspekte vom selbstorganisierten Entwicklungsteam übernommen werden bzw. an dieses delegiert werden können. Einige Dinge, wie das Erstellen eines Lasten- oder Pflichtenheftes, entfallen vollständig. Jedoch ist die Rolle des Product Owners definitiv keine einfache und es kommen neue Verantwortlichkeiten hinzu. Roman Pichler hat das in einem – wie ich finde sehr treffenden – Blog-Artikel beschrieben und wie folgt zusammengefasst:

Product Owner = Product Manager + X

Im Zuge einer Transformation hin zum Agilen ist es wiederum völlig normal, dass tayloristische Rollen und agile Rollen parallel existieren und dass der Übergang zu einer vollständig agilen Organisation erst nach und nach geschieht. Zwar ist ein “Nebeneinander” dieser verschiedenen Philosophien eher ein Auslöser für Chaos, aber natürlich müssen die Menschen auch erst lernen, wie sich die Aufgaben und Verantwortlichkeiten von den alten Rollen auf die neuen Rollen verteilen.

Bedenklich wird es meines Erachtens erst dann, wenn in einem Unternehmen die klassischen Rollen zusätzlich zu den agilen Rollen installiert werden, weil man zu der Überzeugung gekommen ist, dass die Aufgaben “zu komplex für agil” sind, oder weil – im Falle eines Product Owners – “das ja eine Person überhaupt nicht schaffen kann”.

Insbesondere in skalierten Umgebungen, in denen mehrere Teams an einem hinreichend großen Produkt arbeiten, ist letzteres ein gängiges Phänomen. Man erkennt, dass ein einzelner Product Owner überfordert ist, da das Produkt groß und kompliziert ist. Eine häufige Reaktion ist dann, die Aufgaben des Product Owners auf mehrere Köpfe zu verteilen. Eine vollkommen natürliche Reaktion in meinen Augen. Problematisch wird es, wenn daraus eine Aufgabenteilung entsteht, in der der ein Produkt Manager der Stratege ist (also die Marktkenntnis besitzt) und sozusagen das Stakeholder Management betreibt, und den Product Owner dann “managt”. Der Product Owner empfängt dann Anweisungen, wie er Anforderungen zu priorisieren hat und wird zum “Backlogpriorisierer” degradiert. Das alte Rollenbild ist wieder da: Einer denkt, der andere macht. Einer verspricht den Kunden etwas, was er aber von jemand anderem herstellen lässt. Das “Contract Game” beginnt …

Letztlich bringt diese Vorgehensweise auch wieder mehr Distanz zwischen das Umsetzungsteam und die Nutzer. Ich unterstelle, dass Sie genau das bei Ihrer agilen Transformation nicht wollten.

Dass die Aufgaben eines Product Owners für ein hinreichend großes Produkt zu vielfältig und zu zeitaufwändig werden, und dass er in einem solchen Fall entlastet werden muss, lässt sich nicht wegdiskutieren. Bevor man aber zu “mehr Management” greift, sollte man sich einmal vergegenwärtigen, was einen Product Owner eigentlich viel Zeit kostet, und was die Hauptaufgabe eines Product Owners ist:

Die Hauptaufgabe eines Product Owners ist, den Mehrwert für den Kunden – und damit die Wertschöpfung durch das Produkt – zu maximieren. Das tut er, in dem er die Umsetzung durch Priorisierung der Backlog Items entsprechend steuert. Er priorisiert die Backlog Items am höchsten, in denen er die größte Wertschöpfung sieht.
Er muss letztlich also wissen, in welchen Backlog Items die größtmögliche Wertschöpfung steckt. Dieses Wissen erlangt er, in dem er seinen Markt kennt, Nähe zu seinen Stakeholdern und Kunden hat, und deren Bedürfnisse versteht.  Alleine schon deshalb macht es keinen Sinn, die Verantwortung zur Marktkenntnis und die des Stakeholder-Management auf eine andere Person als den Product Owner zu verlagern.

Anstatt dem Product Owner also einen Manager vor die Nase zu setzen kann es aber hilfreich sein, innerhalb des Teams einen Business Analysten zu haben, der aus dem Team heraus den Product Owner beim Formulieren und Schneiden von User Storys massiv unterstützen kann. Auch ein Business Analyst hat Produkt- und Marktverständnis einerseits, andererseits aber auch technisches Verständnis, sodass er mit dem Team zusammen großen Mehrwert stiften kann.

Aber setzen wir doch einmal von einer anderen Richtung an: Was kostet den Product Owner denn viel Zeit?  Mir fällt sofort ein, dass der Product Owner aus Sicht eines Entwicklungsteams eine hohe Verfügbarkeit an den Tag legen sollte, um fachlich-/inhaltliche Fragen zu Produktanforderungen klären zu können. Wen fragt das Team, wenn es Rückfragen zu User Storys gibt?  Klar, den Product Owner!

Auch hier können Sie ansetzen. Sie können dafür sorgen, dass die Entwicklungsteams enger mit Stakeholdern oder ggf. auch Kunden und Nutzern zusammenarbeiten.  Laden Sie zum Beispiel einige davon in Ihre Refinement Meetings ein und sprechen Sie über User Storys. Ich verspreche Ihnen, das wirkt Wunder und Ihr Team wird das lieben.  Führen Sie gelegentliche Produktworkshops mit Kunden, Nutzern und dem Entwicklungsteam durch. Die Teams bekommen so ein besseres Verständnis für die Bedürfnisse Ihrer Nutzer und werden längerfristig weniger Hilfe des Product Owners einfordern. Das entlastet ihn.

Natürlich birgt ein solches Vorgehen auch Schwierigkeiten. Zum Beispiel erhöht sich das Risiko des “Scope Creep”, also dass aus einer eigentlich einfachen User Story ein Anforderungsmonstrum wird, dass man anschließend wieder überarbeiten muss.  Man sollte daher den Product Owner von diesem Prozess nicht vollkommen entkoppeln. Es können so z.B. auch neue Storys entstehen, in die der Product Owner wieder Arbeit investieren muss, aber mittel- bis langfristig ergeben sich durch diese Vorgehensweise viele Vorteile. Der Product Owner kann in geringerer Detailtiefe mit den Produktfeatures arbeiten und sich auf andere Aufgaben konzentrieren.

Eine Schwierigkeit dieses Vorgehens besteht natürlich auch in der Verfügbarkeit der Nutzer und Stakeholder für Workshops und Refinement Meetings. Teams die unternehmensinterne Entwicklung betreiben, haben hier oft einen Vorteil, wahrscheinlich sitzen deren Nutzer sogar im selben Gebäude. Bei echten Endkundenprodukten hingegen ist die Lage schon schwieriger. Aber in einer solchen Situation sollten Sie zumindest Zugriff auf andere Stakeholder haben. Vielleicht aus dem Marketing oder auch im Kreise anderer Kolleginnen und Kollegen, die dieses Produkt privat nutzen. Seien Sie kreativ!

Zu guter Letzt möchte ich aber noch hinzufügen, dass die Besetzung eines Product Owner – gerade in einem großen Unternehmen mit einem hinreichend komplizierten Produkt – keine einfache Aufgabe ist. Sie brauchen hier die oder den Richtige(n). Die Priorisierung nach Wertschöpfung oder gar Geschäftswert ist letztlich nämlich eine Tätigkeit bei der unternehmerische Entscheidungen getroffen werden müssen. So etwas wollen Sie nicht an jemanden delegieren, dem Sie nicht die nötigen Fähigkeiten und ein gewissen Maß an Loyalität unterstellen. Aber auch hier gilt: Inspect and adapt, denn wenn Sie meine oben genannten Ratschläge beherzigen, wissen Sie sehr schnell ob Ihr Product Owner in die richtige Richtung steuert oder nicht.

In diesem Sinne – wenn Sie mit mir über dieses Thema sprechen möchten, freue ich mich wenn Sie mich kontaktieren.

2 thoughts on “Produkt Manager vs. Product Owner

  1. Danke für Ihr Feedback. An welcher Stelle wird Ihrer Meinung nach „manage“ negativ und „Owner“ positiv konnotiert?

    PO ist übrigens eine Rolle im Scrum Framework. Ein agiles Team braucht nicht notwendigerweise einen Product Owner.

    Welche Missverständnisse haben Sie noch gefunden?

  2. Leider ist dieser Artikel voll von Missverständnissen. Das fängt schon alleine damit an, dass das englische Wort „manage“ negativ und „Owner“ positiv konnotiert wird. Würde kein Muttersprachler ubterschreiben. Lesen die bitte die Fachliteratur (zB Marty Cagan) zum Thema Produkt Management. Darin wird klar beschrieben, dass ein PM viel holistischer arbeitet als ein scrum PO. PO ist eine Rolle in einem agilen Team. PM ist eine Job Beschreibung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.