This blog post is also available in English

Frag zwei Teams zur Product Owner Rolle und du bekommst drei Meinungen. Kaum eine Entwicklungsorganisation, welche die Rolle nicht eingeführt hat. Doch die Meinungen über die Aufgaben gehen weit auseinander. Es gibt Versuche, die Rolle weiter auszudifferenzieren, um dies zu erklären. Von Proxy Product Owner, Component Owner oder Portfolio Owner ist dann die Rede.

Anstatt verschiedene Rollen zu vergeben, konzentriere ich mich lieber auf den Kontext, in dem der Product Owner tätig ist. Denn eine zentrale Deutungshoheit dieser Rolle gibt es nicht.

Kernaufgaben

Die Product Owner Rolle entwickelte sich aus dem Scrum Guide heraus. Heute ist sie sehr populär und in vielen Organisationen bekannt. Es gibt viele Publikationen, die sich mit der Frage beschäftigen, was ein Product Owner denn nun sei. Inzwischen haben auch andere Frameworks, z. B. SAFe, den Namen aufgegriffen und eigene Beschreibungen erstellt.

Doch ist der Versuch einer abschließenden Beschreibung überhaupt sinnvoll? Oder der Versuch, die Rolle weiter auszudifferenzieren? Ich glaube nicht. Und trotzdem ist es wichtig, sich vor Augen zu führen, dass Product Owner nicht gleich Product Owner ist. Denn unterschiedliche Kontexte erfordern unterschiedliche Aufgaben und Skills von dieser Rolle. Deshalb gilt: „Es kommt darauf an“!

Orientieren wir uns am Kapitel Product Owner im Scrum Guide[1], sind die Kernaufgaben:

Dabei trägt die Rolle die Ergebnisverantwortung für den Produktwert und dessen Maximierung.

Es folgen im Guide einige Relativierungen und dadurch viel Interpretationsspielraum.

Roman Pilcher beschreibt in seinem Artikel, Six Types of Product Owners[2], die folgenden Rollen:

Das Problem ist, dass diese Begriffe keine übergreifende Bedeutung haben. Jede Organisation hat ihr eigenes Vokabular.

Im Alltag und gegenüber Kunden ist es schwierig, mit diesen Begriffen zu arbeiten, weil:

Ich betrachte die Rolle deshalb lieber abhängig von ihrem jeweiligen Kontext. Dabei akzeptiere ich, dass ein Name verschiedene Bedeutungen hat. Die Bedeutung existiert nur in einem speziellen Kontext. Hierfür habe ich verschiedene „Schubladen“ für mich definiert.

Schublade 1: Markt-Produkt („Market Product“)

Öffnen wir die erste Schublade. Was wir vorfinden, ist ein digitales Produkt. Und zwar eines, für welches Kunden:innen zahlen.

Beispiele für Erlöse:

Julia übernimmt die Product Owner Rolle für diese Schublade. Sie wird in einem solchen Umfeld viel Zeit investieren, um den „Product Market Fit“ zu finden. Also den Punkt, an dem das Produkt eine starke Marktnachfrage befriedigt.

Schwerpunkte:

Julia ist ein Leuchtturm für ihr Team. Sie zeigt die Richtung auf, aber nicht den genauen Weg. Sie wird sich weniger mit Einzelanforderungen und dafür mehr mit Meilensteinen auseinandersetzen.

Es ist nicht ausgeschlossen, dass sie auch mal eine User Story für ihr Team erstellt. Wahrscheinlicher ist aber, dass sie das Backlog auf einer abstrakten Ebene verwaltet und priorisiert. Vielleicht sind es Epics, Features oder Themen. Wie auch immer die Hierarchie aufgebaut ist, sie kümmert sich überwiegend um die Strategie.

Um zu Backlog Items zu kommen, die umgesetzt werden können, wird Julia Unterstützung benötigen. Diese kann durch ein Product Owner Team erfolgen. Vielleicht gibt es dort Personen, die sich mit User Experience auseinandersetzen. Oder es gibt Personen, die sich mit rechtlichen Themen auseinandersetzen. Daraus entstehen dann umsetzbare Backlog Items. Das Entwicklungsteam wird in diesem Fall mit mehreren Personen interagieren müssen. Oder es übernimmt einige dieser Aufgaben selbst. Das funktioniert natürlich nur, wenn es auch über die notwendigen Skills verfügt.

Schauen wir uns nun Stellengesuche bei Indeed & Co. an, dann wird eins schnell klar: Solch ein Profil suchen nur wenige Unternehmen unter dem Titel Product Owner. Die Beschreibungen passen oft eher zu der Product Owner Rolle aus dem SAFe-Framework. Dort ist die Rolle sehr taktisch ausgerichtet. Teile der beschriebenen Tätigkeiten fallen dann eher dem Produktmanager zu. So ist, was Roman Pilcher als Aufgabe des Scrum Product Owner beschreibt, in SAFe eine geteilte Verantwortung zwischen den Rollen Product Owner und Produktmanager.

Ich nehme an, die meisten Organisationen würden die Rolle, die ich in dieser Schublade beschreibe, Produktmanager nennen. Vielleicht gibt es trotzdem eine Person, die explizit Product Owner genannt wird. Die Schwerpunkte würden sich dann aber denen aus einer der folgenden Schubladen ähneln. Schließen wir jetzt also diese Schublade und öffnen die nächste.

Schublade 2: Wegbereiter-Produkt („Enabling Product“)

Quietschend öffnet sich die nächste Schublade. Die Überschrift verschafft gleich Kopfschmerzen. Ich gestehe ein, auf Deutsch hört es sich sehr umständlich an. Deshalb nutze ich den englischen Begriff.

Enabling Product, so bezeichne ich eine Software, mit welcher der zahlende Kunde in Berührung kommt, aber nicht für die Software selbst zahlt. Denn für ihn ist die Software ein Touchpoint und nicht das Produkt.

Die Bezeichnung „Enabling“ habe ich dem SAFe-Framework entliehen. In meinen Worten beschreibt der Begriff dort Aktivitäten, die notwendig sind um zum Ziel zu kommen, aber nicht zum Produkt selbst gehören.

Ein ehemaliger und geschätzter Kollege von mir fragte den Projektmanager gerne dies: „Und, sind die Firewall-Regeln schon im Zeitplan enthalten“? Firewall-Regeln einrichten, das ist für mich ein „Enabler“.

Ich übertrage ihn und kombiniere ihn mit dem Begriff Produkt. Denn ich versuche etwas zu beschreiben, das Kunden:innen wahrnehmen, doch wofür sie nur indirekt bezahlen.

Beispiele:

Zahlen tut der Kunde aber für diese Produkte:

Heribert übernimmt für uns die Rolle Product Owner für ein „Enabling Product“. Er unterstützt das „Market Product“. Typischerweise hat er eher den Fokus auf einen spezifischen Teil. Etwa den Check-out in einem Webshop oder das Modul für Störungsmeldungen im Self-Service-Portal. In diesem Rahmen kann er viele Entscheidungen selbstständig treffen. Budgetgrenzen sind ihm aber vorgegeben oder zumindest sind sie von übergreifenden Budgetplänen abhängig.

Viele strategische Themen werden von anderen Personen übernommen und Heribert wird sie dabei unterstützen. Dadurch arbeitet er stärker taktisch. Er hat mehr interne Stakeholder, mit denen er Entscheidungen abstimmen muss. Etwa den Produktmanager oder einen Gesamtverantwortlichen für die IT-Landschaft.

Schwerpunkte:

Im Team übernimmt Heribert auch Analyseaufgaben und schreibt einige Backlog Items selbst. Er nimmt an den regelmäßigen Terminen im Team persönlich teil. Die Zeit, alle Anforderungen abschließend zu beschreiben, hat er jedoch nicht. Vom Team benötigt er deshalb Unterstützung.

Zum Beispiel durch

Schublade 3: Interner Service

Der interne Service ist das Rückgrat vieler Unternehmensprozesse. Ich nenne sie auch gerne Backoffice-Software. Sie sorgt für die Verwaltung der Mitarbeiter:innen, steuert Aufträge oder sorgt für das finanzielle Zahlenwerk.

Manchmal handelt es sich um Standardsoftware, manchmal um individuelle Entwicklungen. Vielleicht ist es auch eine Mischform, bei der Software eingekauft und dann angepasst wird.

Beispiele:

Im Vergleich zum „Enabling Product“ liegt das Thema tiefer innerhalb der Organisation. Stakeholder sind, von rechtlichen Gesichtspunkten mal abgesehen, überwiegend Menschen in der eigenen Organisation. Für den zahlenden Kunden stellt diese Software üblicherweise keinen Touchpoint dar.

Wir gehen für die weitere Betrachtung davon aus, dass es sich um eine individuelle Software handelt.

Marie übernimmt die Product Owner Rolle für einen internen Service.

Die Product Owner Rolle könnte auch eine Person aus dem Fachteam übernehmen, im Scrum Guide „Lead User“ genannt. Während alle in den Fachteams gerne zur Vision beitragen und Informationen und Ideen beisteuern, fehlt ihnen die Zeit und die notwendige Erfahrung, um alle Tätigkeiten zu übernehmen.

Dabei geht es insbesondere, um das fachgerechte Dokumentieren von Anforderungen.

Marie unterstützt diese Personen. Sie ist Business Partnerin der Vertreter:innen dieser Teams. Ihre Aufgabe ist nicht, Anforderungen 1:1 zu übermitteln. Stattdessen hinterfragt sie diese und liefert für geschilderte Probleme auch eigene Vorschläge.

Requirements Engineering ist ihre primäre Tätigkeit.

Nur selten stehen Personen zur Verfügung, die auf Disziplinen wie User Experience Design und UI Design spezialisiert sind. Marie unterstützt diese Disziplinen deshalb nach bestem Wissen und Gewissen.

Schwerpunkte:

Mit dem Team arbeitet Marie auf täglicher Basis eng zusammen. Sie ist fast immer präsent und diskutiert auch schon einmal die Details einer Umsetzung mit aus.

Fazit

In jeder dieser Schubladen kann es die Rolle Product Owner geben. Die Verantwortlichkeiten und damit auch die Tätigkeitsschwerpunkte unterscheiden sich jedoch.

Abbildung 1 versucht, die verschiedenen Tätigkeitsbereiche zwischen den Kontexten zu gewichten.

Abbildung 1: Gewichtung der Tätigkeiten eines Product Owners
Abbildung 1: Gewichtung der Tätigkeiten eines Product Owners

Julia („Market Product“) wird intern vermutlich den Titel Produktmanagerin führen. Sie konzentriert sich auf die Vision bis zum Marktgang. Ihr Produkt ergänzt das Angebot ihres Unternehmens. Marktanalysen und Metriken stehen für sie an oberster Stelle. Ihrem Entwicklungsteam ist sie eher ein Leuchtturm, die genauen Details oder gar detaillierte Backlog Items sind von ihr nicht zu erwarten. Experten für UX und Business Analyse unterstützten sie dabei.

Ganz anders Heribert („Enabling Product”). Er steckt schon tiefer in den Details und kümmert sich auch um die Organisation des Backlog bis auf Ebene einzelner Backlog-Items. Für sein Produkt muss er ein klares Ziel entwickeln, das zur Vision passt. Marktorientierte Tätigkeiten, die Julia hauptsächlich betreibt, unterstützt er häufig oder muss diese für sein eigenes Produkt übersetzen. Deshalb bleibt ihm nicht ausreichend Zeit, sich um alle Details der Anforderungen und des Backlogs zu kümmern. Dafür ist er auf die Hilfe aus dem Entwicklungsteam angewiesen. Vielleicht kann er auch auf Experten für UX und Business Analyse zurückgreifen.

Marie hingegen steckt tief in den operativen Tätigkeiten und jongliert täglich das Backlog. Sie ist die Brücke zwischen den Businessteams und dem Entwicklungsteam. In einem recht klaren Aufgabenumfeld sorgt sie dafür, dass die Fachteams mit dem Produkt zufrieden sind. Dabei ist sie aber viel mehr als ein Proxy. Sie ist Partnerin des Fachbereichs. So führt sie regelmäßig Verhandlungen über die Wirtschaftlichkeit und Einhaltung von Budgets.

Alle drei haben auf dem Papier die gleiche Rolle und benötigen ein Stück weit ähnliche
Skills. Und doch gibt es auch wichtige Unterschiede. Könnten Marie und Julia 1:1 die Plätze tauschen? Vermutlich nicht und beide müssten aufgrund der unterschiedlichen Aufgaben einiges neu lernen. Je nach Beschaffenheit des Produkts, das die beiden „ownen“ sind strategische oder ganz operative Fähigkeiten gefragt.

Zusammengefasst kann man also sagen, dass als Product Owner:in meine Aufgaben und Schwerpunkte stark vom Kontext abhängen. Diesen zu beachten ist beim Ausfüllen meiner Rolle existenziell.
Bin ich für einen internen Service eingestellt und verhalte mich aber nicht dementsprechend, sind Konflikte (berechtigterweise) vorprogrammiert.

Danksagung

Vielen Dank an meine Kollegen:innen Lena Kraaz, Jan Körnich, Michael Schwarz, Joachim Praetorius und Rebecca Temme sowie meinen ehemaligen Kollegen Simon Dünhöft. Danke für das das gründliche Korrekturlesen, tolle Vorschläge, Hinweise und Kritik.

Quellenverzeichnis

  1. Schwaber, K. & Sutherland, D. (o. D.). Der Scrum Guide [Leitfaden; PDF]. scrumguides.org. https://scrumguides.org/docs/scrumguide/v2020/2020–Scrum–Guide–German.pdf  ↩

  2. Pichler, R. (2022, 28. April). Six Types of Product Owners. Roman Pichler. Abgerufen am 9. Januar 2023, von https://www.romanpichler.com/blog/six–types–of–product–owners/ (Original work updated 2022)  ↩

TAGS