Produkt Manager vs. Product Owner

Mann liest Wirtschaftsnachrichten

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.

Im Übrigen habe ich einmal einen Artikel zur Rolle des Product Owners in Scrum aus soziologischer Sicht verfasst.

Wenn Sie mit mir über dieses Thema sprechen möchten, freue ich mich wenn Sie mich kontaktieren.

6 Antworten zu „Produkt Manager vs. Product Owner“

  1. Avatar von Holger

    Hallo Timo,
    ich kann Dir was den Unterschied betrifft auch nicht komplett folgen. Der Tätigkeit eines Produktmanagers ist viel Umfangreicher als Du sie darstellst. Es gehören viele Themen aus dem Marketingprozess im Upstream Marketing (Marktanalyse, Bedarfsanalyse, Portfolioplanung, Def. von Absatz und Umsatzpotentialen, Positionierung des Produktes) und auch im Downstream Maketing (Umsatzanalyse, Vorteilsargumentation, Wettbewerbsbetrachtung, Briefing der Kommunikation-Teams, Launchplanung bis zur Mitarbeit an der Vertriebsstrategie hinzu). Die eigentliche Leitung eines Entwicklungsprojektes wird oft durch PMs durchgeführt ist jedoch nicht originärer Teil des Aufgabengebietes. Die Gleichung des Product Owners müsste daher eigentlich PO=PM-X sein. Wobei wenn man den Umfang des Arbeitsbereiches eines PMs betrachtet es sicher mehrere X sind.
    Richtig ist auch das Unternehmen die Rolle des PM sehr unterschiedlich auslegen. Oft hängt dies von den sonstigen Fähigkeiten und Ressourcen des Unternehmens ab. Im Kern bleibt es jedoch immer die Rolle der Schnittstelle die Informationen für ein neues Produkt in die Organisation hineinfügt und ordnet und nach dem Produkt-Launch diese auch wieder heraus gibt. Gepaart mit einer permanenten Beobachtung der Performance der eigenen Produkte und der Wettbewerbsprodukte am Markt.

    VG

    Holger

    1. Avatar von Timo
      Timo

      Hallo Holger,

      Danke für Dein Feedback. Vielleicht würde ich den Artikel heute etwas anders schreiben, damit vielleicht mein Punkt, den ich zu machen versuche, besser rüber kommt. Das ist nämlich folgender: Wenn man sich für die Produktentwicklung mit dem Scrum Framework entscheidet, und die Rolle des Product Owners einführt, sollte man sich bewusst sein, dass der Product Owner den Produktmanager vollständig ersetzen MUSS. Ansonsten macht es keinen Sinn (man lese dazu gerne den Scrum Guide). Letztlich folgt das aber einfach aus dem Ansatz, dass der P.O. die kommerzielle Verantwortung für das Produkt vollständig trägt. Wie könnte er das, wenn man ihm nicht überlässt, so Dinge wie Marktanalyse, Bedarfsanalyse, Portfolioplanung, Def. von Absatz und Umsatzpotentialen, Positionierung des Produktes zu verantworten (um Deine Beispiele zu nehmen)?
      Selbstverständlich kann ein P.O. solche Dinge delegieren aber muss sie Verantworten und unternehmerische Entscheidungen daraus treffen. Ansonsten bleibt er eine fremdgesteuerte „Priorisierungdrone“ oder Proxy-P.O., wie man das auch gerne nennt. Dann kann man das mit dem Scrum und dem P.O. auch lassen. Wir müssen da aber inhaltlich nicht übereinstimmen 😉

      Viele Grüße,
      Timo.

      1. Avatar von Benjamin
        Benjamin

        Das würde ich so unterschreiben.
        Ich bin auch der Meinung, dass bei der agilen Transformation vieles durcheinander geworfen wird. Man endet dann häufig bei Water-Scrum-Fall und ScrumBut etc…
        Agile Vorgehensweisen und Frameworks unterscheiden sich wesentlich von klassischen Management Methoden.

        Die Gleichung PO = PM + X ist somit falsch.
        Der PO führt das Team nicht im klassischen Sinne. Das Entwickler Team managt sich selber. Der Product Owner verhandelt mit dem Team und gibt keine! Arbeitsanweisungen. Die Aufgabe des PO ist herauszufinden was gemacht werden muss, damit das Produkt zum größtmöglichen Erfolg wird.
        Manager sind weisungsbefugt und verwalten Ressourcen.

        1. Avatar von Timo
          Timo

          Danke für Deinen Kommentar. Deiner Argumentation kann ich folgen. Aus der Perspektive, die Du beschreibst, hast Du Recht. Die Gleichung soll jedoch lediglich deutlich machen, dass ein P.O. in Bezug auf das Produkt eine mindestens ebenso große Verantwortung trägt, wie üblicherweise ein Produktmanager.

  2. Avatar von Timo
    Timo

    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?

  3. Avatar von Babak Hosseini

    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 zu Holger Antworten abbrechen

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.