Product Owner Definition: Interview mit Benjamin Britten (Shop Apotheke)

Hallo Benjamin. Du bist aktuell Lead Product Owner bei der Shop Apotheke. Zuvor warst du einige Jahre lang Chief Product Owner bei der digitalen Versicherung nexible. Was unterscheidet diese Rollen von einem „normalen“ Product Owner (PO)?

Chief oder Lead Product Owner bilden die Klammer um die Produktentwicklung durch mehrere Product Owner für ein gesamtes Produkt oder einen größeren Produktbereich. Das heißt: Ich übernehme die Verantwortung für die gesamte Plattform oder einen Produktbereich, während weitere Product Owner darin definierte Subprodukte eigenständig weiterentwickeln. Meine Arbeit ist daher eher koordinativ und strategisch und weniger in einem Entwicklungsteam. Meine Aufgabe ist es, dafür zu sorgen, dass die einzelnen Teilprodukte einer gemeinsamen Strategie und Zielen folgen.

Solche Rollen können mit und ohne disziplinarische Verantwortung sein. Bei nexible berichten alle Mitarbeiter (ca. 45) direkt an die Geschäftsführung, ich habe aber das Product Ownership mit aus- und aufgebaut, also zum Beispiel Kollegen eingestellt. Bei Shop Apotheke habe ich 3 bis 4 Product Owner in meinem Team in der Verantwortung.

Wie bist Du Product Owner geworden?

Ich bin während meiner Zeit in der Digitalagentur ecx.io Product Owner geworden. (ecx.io gehört mittlerweile zu IBM und firmiert unter IBM iX – Anm. des Verf.). Nach dem Studium der digitalen Medien an der Universität Bremen bin ich in Düsseldorf bei den argonauten G2 in die Software- und Webentwicklung eingestiegen. In unterschiedlichen Positionen im Bereich Kundenberatung und Projektmanagement habe ich eine Dekade praktische Erfahrung gesammelt. Bei ecx.io war ich zunächst in der Kundenberatung als Senior Account Manager tätig. Durch meine Erfahrung bin ich aber oft tief mit in die jeweiligen Kundenprojekte eingestiegen und habe eng mit dem Projektmanagement zusammengearbeitet. So bin ich dann Head of Project Management geworden.

2015 wollte die Geschäftsleitung Scrum einführen. Ich habe aus meiner Rolle heraus die agile Transformation für den Düsseldorfer Standort mit übernommen und wurde zum Scrum Master und Product Owner ausgebildet. Ich habe sofort Feuer gefangen für die agile Produktentwicklung und viele Kollegen und Kunden gecoacht, Agilität zu verstehen und in Scrum-Projekten zu arbeiten. Meinen Projektmanagern habe ich geholfen, die PO-Rolle in ihren Kundenprojekten zu übernehmen.

Irgendwann bin ich aber in einen gewissen Rollenkonflikt gekommen. Der Agenturkunde kauft eine Dienstleistung ein und die Agentur baut das Produkt nach Maßgabe und Vorgabe des Kunden. So ist in der Regel auch das Vertragswerk gestaltet. Somit ist eigentlich der Kunde Product Owner und verantwortlich für das Produkt. Das hat es für mich schwierig gemacht, denn eine notwendige Vertragsrevolution ist schwierig umzusetzen.

Ich wollte selbst in der Rolle sein, das Produkt zu ownen und kundenzentriert zu entwickeln. Deswegen bin als Product Owner zu Stepstone gewechselt. Hier konnte ich tatsächlich so als Product Owner arbeiten, wie ich es mir vorgestellt habe. Vieles von meinem PO-Wissen habe ich aus meiner Zeit bei Stepstone. Dort war agile Produktentwicklung schon sehr idealtypisch umgesetzt. Vor allem der Ansatz, datengetrieben und nach Business Value priorisiert vorzugehen, war sehr etabliert.

Was unterscheidet den Product Owner vom klassischen Projektmanager oder anderen „traditionellen“ Rollen im Unternehmen?

Ein Vergleich ist gar nicht so einfach: Der Product Owner ist eine Rolle aus dem Scrum-Framework, beim Projektmanager handelt es sich aber um eine Position oder ein Berufsbild.

Der Product Owner ist von den klassischen Rollen noch am ehesten vergleichbar mit einem (technischen) Produktmanager (PM) Sowohl der PM als auch der PO müssen wissen, warum und wofür ihr Produkt benötigt wird. Sie finden heraus, welcher Bedarf am Markt besteht und wie dieses Bedürfnis erfüllt werden kann.

Ein Produktmanager entwickelt und betreut ein Produkt. Er befasst sich stark mit dem Produkt, dem Markt, den Bedürfnissen sowie der Vermarktung und dem Vertrieb. Als Produktverantwortlicher sorgt er dafür, dass das Produkt gebaut wird und hat dabei auch unternehmerische Ziele im Blick. Die Produktentwicklung kann beispielsweise in einem Projekt passieren. Dann benötigt er wahrscheinlich auch einen Projektmanager, der den Zeitplan und alles weitere Wichtige rund um das Projekt koordiniert. Im Vergleich zum Produktmanager beschäftigt sich der Projektmanager nicht inhaltlich mit dem Produkt.  Er bekommt gewisse Rahmendaten, z. B. ein Budget oder zeitliche Vorgaben, und arbeitet darauf hin, dass das Projekt innerhalb dieses Rahmens fertiggestellt wird. Der Return on Invest spielt für ihn oft keine Rolle. Er hat das erfolgreich umgesetzte Projekt im Blick. Ob das Projekt sinnvoll war oder nicht, ist meist nicht von Relevanz. Der Produktmanager (und auch der PO) hat einen umfassenderen Blick auf das Produkt. Während der Produktmanager die inhaltliche Verantwortung trägt, hat der Projektmanager eher eine koordinative Rolle oder Verantwortung.

Und was unterscheidet den Product Owner vom Produktmanager?

Ich bin mir gar nicht sicher, ob es dafür offizielle Definitionen gibt, aber mein Verständnis ist wie folgt: Ein Produktmanager managed den kompletten Lifecycle eines Produkts mit allen Facetten und ist wirtschaftlich verantwortlich. Die PO-Rolle entwickelt ganz spezifisch ein Produkt (weiter) und verantwortet dabei nur die Werthaltigkeit dieser Entwicklung (und nicht einmal die Lieferung, denn dafür ist ja bekanntlich das Entwicklungsteam verantwortlich). Das kann insbesondere auch ein Teilprodukt des betreffenden Produktangebots sein. So würde ich zumindest mal die Kernrollen beschreiben. Wie immer lassen sich solche Rollen oder auch Positionen interpretieren. Gemeinsam haben beide Rollen den Fokus auf die Befriedigung von Kundenbedürfnissen und die damit verbundene Wertoptimierung.

Ich möchte gerne ein Beispiel machen. Angenommen ein Produktmanager ist verantwortlich für die Entwicklung, Produktion und Vermarktung eines Stuhls. Durch seine Analysen gelangt er zu der Erkenntnis, dass der Online-Vertriebskanal am interessantesten ist. Jetzt könnte er zwei Product Owner in seinem Team beschäftigen. Einen zum tatsächlichen Bau des Stuhls und einen, um die digitale Vertriebsplattform zu bauen. Er selbst muss jedoch auch noch dafür sorgen, dass es Produktmarketing, Logistik, Kundenbetreuung, Controlling etc. für den Stuhl gibt, um das Produktangebot zu realisieren.

Ich habe mich übrigens in einem noch komplexeren Kontext bei nexible bewegt. Denn anstelle eines Stuhls haben wir eine Dienstleistung – die Versicherung – online vertrieben. Dazu müssen Versicherungsexperten und Digitalexperten wie ich eng zusammenarbeiten, denn die Versicherung muss in dem Fall auf den Vertriebskanal abgestimmt sein und umgekehrt. Ohne einander kann es keinen Erfolg geben! Im Finanzsektor hat die ING dies vor Jahren erfolgreich vorgemacht: Einfache Finanzprodukte mit transparenten und vertrauenswürdigen Prozessen ermöglichen kostenreduzierten, digitalen Erfolg.

Was reizt dich an der Rolle? Warum bist du gerne Product Owner?

In meiner Rolle als Product Owner schaffe ich Win-Win-Situationen: Ich setze mich intensiv mit meinem Produkt und meiner Zielgruppe auseinander. Wer nutzt mein Produkt? Warum möchten sie es haben und was bringt es ihnen? Wenn ich das herausfinde und es schaffe, ein Produkt zu entwickeln, das einen Mehrwert für Kunden schafft und ihre Bedürfnisse erfüllt, dann empfinde ich das als Erfolg. Denn es entsteht eine echte Win-Win-Situation: der Kunde hat etwas davon und ich und mein Unternehmen ebenfalls, da wir damit Geld verdienen. Ich finde es unfassbar befriedigend, etwas zu erschaffen, das Wert schafft, weil es meiner Tätigkeit einen Sinn gibt.

Generell finde ich es spannend, mich mit Menschen und ihren Bedürfnissen zu beschäftigen und nach möglichen Lösungen zu suchen. Zudem liebe ich es, eigenverantwortlich zu arbeiten und daten- und faktenbasiert zu entscheiden. Das ist das Tolle an der PO-Rolle: Ich bin verantwortlich für ein Produkt und darf Entscheidungen treffen, die das Produkt nach vorne bringen. Ich tue dies aber immer datenbasiert, mit dem Ziel einen tatsächlichen Mehrwert zu schaffen.

Gleichzeitig ist die Entwicklung von Digitalprodukten immer Teamwork. Es ist absolut super, in einem funktionierenden Team zu arbeiten und sich hier gegenseitig zu inspirieren. Das liebe ich generell in der agilen Produktentwicklung: Es ist echtes Teamwork gefragt, gleichzeitig gibt uns die iterative Vorgehensweise die Möglichkeit, Dinge auszuprobieren. Alles, um ein großartiges Produkt für unsere Kunden zu erschaffen.

Was waren bisher deine größten Herausforderungen als Product Owner?

Im Unternehmen prallen oft zwei Bilder aufeinander: Da ist einmal das Selbstverständnis des Product Owners, wie er als Rolle in Scrum definiert wird, und zum anderen das Bild, das von außen auf die Rolle projiziert wird. Das führt häufig zu Missverständnissen, weil oft etwas anderes vom PO verlangt wird – nicht selten aus Unwissen. Viele Vorgesetzte oder Kollegen im Unternehmen wissen nicht, was in der PO-Verantwortung liegt und erwarten somit Dinge, die nicht zu den Kernkompetenzen eines PO gehören. Zum Beispiel die oben bereits beschriebene „Lieferung“ des Produkts. Häufig wird vom PO auch eine Verantwortlichkeit für das Gesamtprodukt verlangt. Damit wäre er dann jedoch ein Produktmanager und kein Experte für z.B. die digitale Produktentwicklung.

Eine andere Herausforderung ist, dass der Product Owner eigenverantwortlich arbeiten können muss. Er entscheidet, was entwickelt wird. Das bedeutet, dass er auch mal „Nein“ sagt. Gerade wenn Agilität und Scrum implementiert werden, sich die Rahmenbedingungen aber nicht ändern, führt dies oft zu Problemen. Häufig erhält der PO dann Aufträge „von oben“, zu denen er aus Hierarchie-Gründen nicht „nein“ sagen kann. Dann ist es mit der Eigenverantwortlichkeit und öfter auch mit der Werthaltigkeit nicht weit her.

Ich hatte jedoch auch schon einmal das Problem, dass das „physische Produkt“ erfolglos war und ich es mit meinem digitalen Vertriebsprodukt nicht erfolgreich machen konnte. Also wenn der Stuhl keinen Bedarf im Markt trifft oder schlechte Qualität besitzt, hilft auch der beste Onlineshop nur begrenzt, die Absatzerwartungen zu erfüllen. Leider braucht es dann oft sehr viel Überzeugungsarbeit, um die notwendige Konsequenz daraus zu ziehen.

Was muss ein guter PO deiner Meinung nach mitbringen? Und was macht einen guten PO aus?

Zunächst einmal strahlt er Begeisterungsfähigkeit für das Produkt, die Kunden und die Kundenbedürfnisse aus. Das bedeutet, dass er meiner Meinung nach ein gutes Stück Unternehmertum mitbringen muss – nur so kommt es zu Ownership: Der Product Owner macht das Produkt zu „seinem Ding“ und es treibt es voran.

Er sollte auch über ein gewisses Produktverständnis verfügen und einen fachlichen Hintergrund in dem Bereich haben, in dem er arbeitet. Gleichzeitig ist es hilfreich, eine gute Auffassungsgabe zu haben und sich schnell in Themen einarbeiten zu können. Das hilft beim Blick auf das Produkt: Was ist der Markt? Was ist die Zielgruppe? Wie kann ich einen USP herstellen?

Ein guter PO rückt das Produkt in den Vordergrund und nicht die eigene Karriere oder Position – sonst lässt man sich durch persönliche Beziehungen, Macht oder Geltungsbedürfnis leicht von der Sache und vom rechten Weg ablenken.

Ein guter Product Owner beherzigt natürlich alle 5 Scrum-Werte, meiner Meinung nach sind aber zwei davon besonders wichtig für ihn: Mut und Respekt. Er bringt den Mut auf, unliebsame Entscheidungen zu treffen und auch mal Nein zu sagen. Gleichzeitig geht er immer respektvoll mit allen Beteiligten um und zeigt Empathie. Dies tut er, indem er beispielsweise seine Entscheidungen erklärt und mit allen auf Augenhöhe kommuniziert. Sonst wird er es auf Dauer schwer haben in der Zusammenarbeit mit den Stakeholdern und mit seinem Standing im Unternehmen.

Und generell sollte er eine gewisse Ruhe und Ausgeglichenheit ausstrahlen und kommunikativ sein.

Worauf muss ein PO besonders achten?

Er sollte bei seinem Produkt immer auf die Wertorientierung fokussiert bleiben. Oft passiert es, dass Kollegen oder Stakeholder kommen und sagen: „Kannst Du das noch eben schnell bauen?“  Und dann kann es passieren, dass man das unhinterfragt umsetzt. Das ist suboptimal, weil man sich dadurch angreifbar macht. Der Fokus liegt immer auf dem Kundenwert, Anforderungen werden immer dahingehend geprüft. Man sollte idealerweise nichts umsetzen, nur um jemandem im Unternehmen einen Gefallen zu tun. Ich möchte jedoch auch einräumen, dass gute POs einen Ermessensspielraum haben, den sie insbesondere für die innere Politik in einem Unternehmen nutzen können und sollten.

Meine Empfehlung ist es zudem, seine Stakeholder aktiv zu managen: Im Idealfall bindest du deine Umwelt so tief ein, dass du nicht dauernd ins Kreuzfeuer der Anforderungen gerätst. Aus diesem Grund sollten alle Beteiligten deine Produktvision und Strategie kennen und wissen, wo du mit dem Produkt hinwillst. Kommunikation ist superwichtig. Geh du zu deinen Stakeholdern, bevor sie zu dir kommen.

Durch aktives Stakeholder-Management baut man Vertrauen in die eigene Arbeit auf und erspart sich eine Menge Diskussionen.

Lass uns zum Abschluss noch einmal generell werden. Wie verstehst du Agilität und speziell das Scrum-Framework?

Ich bin ein großer Fan von Scrum: Ich glaube, wenn man das Vorgehensmodell so anwendet, wie man es sollte, erzielt man bessere Ergebnisse. Ich glaube aber auch, dass Scrum und Agilität an sich oft falsch verstanden werden.

Zunächst einmal: Scrum ist anstrengend. Es gibt keine Pausen, Sprint folgt auf Sprint. Das wird meines Erachtens oft unterschätzt.

Ein zweiter Punkt: Bei Agilität zählen in erster Linie die Werte (Commitment, Offenheit, Mut, Respekt, Fokus). Es geht zunächst einmal darum, wie ich arbeite und nicht darum, welches Werkzeug ich benutze. Das wird in vielen Unternehmen falsch gedacht und gemacht. Vielerorts wird breitflächig Scrum eingeführt und dann geht man davon aus, dass es nun besser und schneller geht. Das ist wohl ein fundamentaler Fehler.

Was sind die Gründe dafür?

Agilität wird in vielen Organisationen mit Scrum gleichgesetzt. Aber: Scrum passt natürlich nicht auf alle Bereiche. Scrum ist ein Produktionsprozess. Das Vorgehensmodell funktioniert super für Teams, die Produkte oder Lösungen entwickeln. In anderen Bereichen eignen sich andere Frameworks oder Arbeitsweisen besser. Hier sollte man sich vor allem an den eben schon genannten agilen Werten orientieren.

Scrum wird so in vielen Organisationen missverstanden. Wer Scrum überall einsetzt, auch da, wo es gar nicht passt, fährt nicht die Erfolge ein, die er gerne haben möchte. Das führt dazu, dass Mitarbeitende aber auch Führungskräfte dann sagen: „Das mit der Agilität funktioniert ja doch nicht.“ Und schon ist Agilität dort verbrannt.

Wenn Unternehmen anfangen, Agilität methodisch einzuführen (Scrum, Kanban oder was auch immer), werden immer nur bestimmte Aspekte eingeführt. Das, was gerade so gewünscht ist. Es werden bestimmte Positionen umgedichtet, damit Kollege X sich nicht untergeordnet fühlt. So wird dann aus dem Projektmanager oder Teamleiter plötzlich der Product Owner, obwohl es eigentlich ganz andere Anforderungen an diese Rolle gibt.

In Scrum ist der Product Owner eine Rolle. In vielen Unternehmen wird er zur Position und so auch oft in eine Management-Rolle gedrückt. Das haben wir ja eben schon angesprochen: Oft wird vom Product Owner verlangt, dass er „liefert“. Aber das ist nicht die Rolle vom Product Owner. Er stellt sicher, dass das richtige gebaut wird. Der PO ist nicht der Vorsteher des Teams, er ist „nur“ verantwortlich dafür, dass das Produkt Wert erzeugen kann. Für den „Lieferprozess“ ist das gesamte Team verantwortlich. Das wird oft missverstanden.

Und wie kann es funktionieren?

Meines Erachtens ist es in der Transformation sehr wichtig, das Team in den Vordergrund zu rücken und die Rahmenbedingungen seines agilen Arbeitens zu schaffen. Lange habe ich geglaubt, dass ein Big Bang bei der Einführung super wäre. Heute bin ich überzeugt, dass man agiles Arbeiten besser erst einmal mit einem einzigen Team und mit Menschen, die Lust darauf haben, ausprobiert. Es ist schwierig genug, überhaupt das Verständnis und die Rahmenbedingungen zu schaffen. Da ist es besser, mit dem Erfolg eines Teams zu überzeugen und einen Flächenbrand auszulösen. Andernfalls übernimmt man sich schnell mit dem Change und kann nicht alle Mitarbeiter mitnehmen. Dann läuft man Gefahr, viele „agile Gespenster“ in der Organisation zu haben.

„Agile Gespenster“? Was meinst Du damit?

Ich habe im Laufe der Zeit festgestellt, dass es in Bezug auf agiles Arbeiten drei Gruppen von Menschen gibt.

Gruppe 1 sind Menschen mit einem ausgeprägtem Wertesystem, das hohe Deckung mit den agilen Werten hat.  Diese Menschen brennen sofort für Scrum, da es sehr ihrem Bedürfnis zu arbeiten entspricht. Sie verstehen die Idee und das Prinzip der Arbeitsweise sofort. Die Anwendung der Methodik ist daher kinderleicht für sie. Meist sagt man diesen Menschen auch das viel zitierte „Agile Mindset“ nach.

Auf der anderen Seite sind Menschen, die agiles Arbeiten ablehnen, weil es nicht ihren Bedürfnissen oder Vorstellungen zu arbeiten entspricht. Das ist nichts Negatives. Beispielsweise kann Scrum für Menschen, die nach dem DISG-Modell zum Typ „Gewissenhaft“ gehören, totaler Stress und Überforderung bedeuten, da sie oft gern allein ihre Aufgaben abarbeiten. Allein aus diesem Grund kann Scrum nicht als Performance-Allheilmittel herangezogen werden. Zu dieser zweiten Gruppe zähle ich auch Menschen, die die Idee agilen Arbeitens offenkundig nicht verstehen. Meist wollen sie es auch gar nicht, was ebenfalls ok ist.

Die dritte Gruppe ist nun die der agilen Gespenster. Es gibt Menschen, die glauben die Idee von Agilität verstanden zu haben – ja wollen es gar verstehen – tun es aber leider nicht. Ihr alltägliches Handeln geht oft zuwider der agilen Idee oder den Scrum-Prozessen und stellt damit oft ein Impediment für den Erfolg agiler Teams dar. Das sind sozusagen die netten Gespenster, weil sie wollen, aber (noch) nicht können. Für Coaches und das Leadership ist zunächst die größte Herausforderung, diese „netten Gespenster“ zu identifizieren, um Ihnen dann idealerweise zu helfen, in Gruppe 1 zu gelangen. Ideal wäre es für diese Personen in bereits reife Teams aufgenommen zu werden, da dort die beste Chance zu lernen ist, ohne aber den Erfolg des Teams zu gefährden. (Das reife Team sollte der Theorie nach selbst so sattelfest im agilen Arbeiten sein, dass es eine Blockade durch einzelne Mitglieder nicht zulässt und in Retrospektiven die Weiterentwicklung selbständig aufnimmt.)

Gibt es noch weitere „Gespenster“?

Leider gehören zu Gruppe 3 auch Menschen, die zwar die Idee von Agilität/Scrum grundsätzlich verstehen. Sie lehnen diese Art zu arbeiten aus diversen Gründen jedoch ab, geben es aber nicht preis. Die Motive dafür sind ebenso vielzählig wie nachvollziehbar. Das reicht von der Verlustangst des Arbeitsplatzes bis zur Angst, das Gesicht zu verlieren, weil man den Trend nicht mitgeht. Aber auch Machtverlust im Unternehmen gehört dazu. Das Problem ist, diese Kollegen zu identifizieren, da sie ja genau das zu verhindern versuchen. Meiner Meinung nach sind hier sehr viel Erfahrung und Fingerspitzengefühl im Leadership notwendig, um diesen Gespenstern aus der Verschleierung zu helfen. Gelingt dies jedoch nicht, ist agiles Arbeiten nachhaltig gefährdet, da diese Gruppe die Transformation stetig bremst oder gar blockiert.

Aus diesem Grund ist es also besser, mit Menschen in die Agilität zu starten, die sich bewusst dafür entscheiden und Freude daran haben. Denn ist der Erfolg des ersten Teams erst einmal sichtbar, kann man andere Kollegen auch besser davon überzeugen oder hat die Zeit, mit betroffenen Kollegen der Gruppen 2 und 3 Lösungen zu erarbeiten.

Wenn man es genau betrachtet, wäre das ein „agiles Einführen von Agilität“, da es iterativ, transparent, wertschaffend, lernend und respektvoll passiert.