Product Owner ist eine agile Rolle aus dem Scrum Framework. Als Product Owner trägst Du die Verantwortung für die erfolgreiche und wirtschaftlich sinnvolle Umsetzung eines Vorhabens. Das kann die Entwicklung und der kommerzielle Betrieb eines Produktes, die Umsetzung eines Projektes oder die Erbringungen einer Dienstleistung sein. 

In diesem Artikel stelle ich dir die wichtigen Aufgaben eines PO vor und zeige Dir, was in meinem Verständnis einen guten Product Owner auszeichnet.

Definition Product Owner 

Ursprünglich stammt die Rolle des Product Owners aus dem Scrum Framework. Mittlerweile wird die Bezeichnung aber auch über Scrum Teams hinaus im Kontext agiler Organisationen verwendet. Je nach Kontext wird der PO auch als Project Owner oder Service Owner bezeichnet. 

Product Owner	Dauerhafte Entwicklung und Betrieb eines Produktes oder einer technischen Plattform.
Project Owner	Umsetzung eines Projektes, das heißt es gibt ein absehbares Projektende.
Service Owner	Dauerhafte Erbringungen einer externen oder internen Dienstleistung.

Der Einfachheit halber bleibe ich in diesem Artikel bei der Bezeichnung des Product Owners oder auch einfach PO. Du übersetzt das bitte immer in den für Dich passenden Kontext.

Produkte, Projekte und Services

Ein Projekt hat in Abgrenzung zu einem Produkt per Definition ein absehbares Ende. Dagegen arbeitest Du solange an einem Produkt oder einem Service solange es strategisch und wirtschaftlich sinnvoll ist. Und als Service Owner arbeitest Du im Vergleich zu einem Product Owner an der Erbringung einer Dienstleistung statt der Entwicklung eines Produktes. Über diese typologischen Unterschiede hinaus hast Du in all diesen Rollen die gleiche Verantwortung und Aufgaben. 

	Zeitspanne	Typ
Produkt	Dauerhaft	Digitales oder physisches Produkt
Service	Dauerhaft	Interne oder externe Dienstleistung
Projekt	Zeitlich begrenzt	Aufbau einer neuen Fähigkeit oder Design eines neuen Prozesses.

Abgrenzung Produkt- und Projektmanager

Ein Product Owner hat in (m)einem agilen Verständnis deutlich mehr Befugnisse und eine grundlegend andere Haltung als ein Produkt- und Projektmanager. Auch wenn das im weiteren Verlauf des Beitrags hoffentlich sehr deutlich wird, hier schon einmal die wesentlichen Unterschiede:

1. End-to-End: Als PO bist Du in einer end-to-end Verantwortung, als Projekt- oder Produktmanager bist Du oft nur mit einem Ausschnitt der Leistungserbringung beschäftigt. 
2. WIE vs WARUM: Als PO setzt Du dich vor allem damit auseinander, ob eine Leistung bzw. ein Produkt überhaupt angeboten werden sollte. Als Projekt- oder Produktmanager dagegen bist du primär mit dem WIE, weniger mit dem WARUM beschäftigt.
3. Als Projekt- oder Produktmanager vergibst Du Arbeitspakete. Dagegen setzt Du als PO auf Selbstverpflichtung der umsetzenden Projektmitglieder und Entwickler.

Jene Unternehmen, die ihre Produktmanager nun als PO bezeichnen, ohne jedoch Befugnisse zu erweitern, haben agile Werte und Prinzipien nicht verstanden. Diese vermeintlichen PO’s haben zwar nun einen neuen Namen, sind in ihrer Rolle aber immer noch Produkt- und Projektmanager. Das heißt, Du hast die Umwelt, die Kultur ist aber noch die gleiche. Das ist in etwa so, wie ein morsches Haus zu streichen. Mag gut aussehen, ist aber wirkungslos. 

Product Owner Aufgaben und Verantwortungen

Die zentrale Aufgabe des Product Owners ist eine andauernde Beurteilung, ob und wie das ihm anvertraute Vorhaben einen Nutzen stiftet. Das erfordert eine ständige Abwägung von Kundenbedürfnissen mit den wirtschaftlichen Interessen des Unternehmens. Damit hast Du als Product Owner folgende Aufgaben und Verantwortungen.

Den Kunden in- und auswendig kennen

Deine erste wichtige Aufgabe als Product Owner ist eine Auseinandersetzung mit den Bedürfnissen deiner Kunden. Denn nur auf dieser Basis kannst Du eine bedarfsgerechte Lösung entwickeln, die Werte für den Kunden und dein Unternehmen schafft. Das erfordert Gespräche sowie einen intensive Auseinandersetzung mit dem Kunden. Erst auf Basis dieses Verständnisses entwickelst Du Ideen, wie es gelingt Probleme des Kunden zu lösen. Dabei helfen Dir Werkzeuge wie Design Thinking, Customer Journey Mappings oder auch die Beschreibung von Personas. Schließlich bist Du als Product Owner immer auch Servant Leader, Design Thinker und hast gelernt in den Schuhen deiner Kunden zu laufen.

Die Kundenbrille bei internen Projekten

Sofern Du als Product Owner ein rein internes Vorhaben betreust, z.B.die Umstellung eines Prozesses, hast Du gleich mehrere Kunden. Zum einen natürlich den “echten” Kunden, schließlich soll das Kundenerlebnis mit Einführung neuer Abläufe nicht leiden. Das heißt Du berücksichtigst immer auch die Auswirkungen auf den “echten” Kunden. Darüber hinaus gehören auch interne Anwender zu deinen Kunden, denn diese Kollegen beglückst Du ja ebenfalls mit deinem Vorhaben. Und im besten Fall verbesserst Du den Prozess zum Wohl der internen Anwender deiner “echten” Kunden. 

Den Business Impact verstehen

Die zweite wichtige Aufgabe als Product Owner ist zu verstehen, wie dein Projekt, Produkt oder dein Service auf die Ziele deiner Organisation einzahlt. Das heißt, als Product Owner kennst Du die Strategie deines Unternehmen. Du erkennst, wie dein Vorhaben auf die Ziele und das Portfolio deines Unternehmens einzhalt. Daraus kannst Du eine hohe Zuversicht ableiten, dass dein Unternehmen dauerhaft in die Umsetzung des Vorhabens investiert. Je Wichtigkeit des Vorhabens bist Du als Product Owner sogar eine tragende Säule für die Gestaltung der Unternehmensentwicklung. Das Business Model Canvas hilft Dir als Product Owner zu verstehen, wie dein Vorhaben zur Entwicklung des Unternehmens beiträgt.

Du ownst den ROI deines Vorhabens 

Die Verantwortlichkeit für den Business Impact bedeutet auch, dass Du wirtschaftliche Aspekte deines Vorhabens verttritts. Das heißt, Du bist in der Rolle des Product Owner für den Return on Invest (ROI) eines Produktes, Projektes oder Services verantwortlich. Aus dieser Position heraus, hast Du auch einen wesentlichen Einfluss auf die Entscheidung, ob das Vorhaben unter Umständen auch eingestellt werden sollte. 

Leistungsmerkmale formulieren und priorisieren

Die dritte wichtige Aufgabe des Product Owners ist die Formulierung und Priorisierung von Leistungsmerkmalen und Funktionalitäten. Denn aus den Bedürfnissen deiner Kunden und den Zielen deines Unternehmens, kannst Du Anforderungen an die Umsetzung deines Vorhabens ableiten. Dabei hast Du natürlich eine hohe Zuversicht, dass die Anforderungen einen Nutzen für den Kunden und deine Organisation stiften. Um auch die wirtschaftlichen Interessen Rechnung zu tragen, stellst Du dem erwarteten Nutzen den Aufwand der Umsetzung entgegen. Bei der Formulierung von Anforderungen und Leistungsmerkmalen helfen Dir z.B. User Stories. 

Leistungsmerkmale priorisieren

Eine deiner wichtigsten Werkzeuge und Aufgaben als Product Owner ist eine klare Priorisierung der Anforderungen. Wenn Du Anforderungen priorisierst, die kaum Wert in Aussicht stellen, aber lange in der Umsetzung brauchen, leidet dein ROI. Das heißt, als guter Product Owner triffst Du immer eine klare Priorisierung auf einer Aufwand- und Nutzenabschätzung. Ein gutes Hilfsmittel für die Priorisierung deiner Leistungsmerkmale ist z.B. die WSJF Methode. Damit stellst Du sicher, dass das umsetzende Team an den werthaltigsten Anforderungen arbeitet und ihr Einsatz jede Minute wert war.  

Die Geschichte deines Vorhabens erzählen

Die vierte wichtige Aufgabe als Product Owner ist die Geschichte deines Vorhabens zu erzählen. Du kennst den Kunden in und auswendig und verstehst wie dein Vorhaben auf die Ziele deines Unternehmens einzahlt. Darauf basierend kannst Du eine überzeugende Vision und Strategie für dein Vorhaben ableiten. Dabei zeigst Du auf, wie dein Produkt, Projekt oder Service auf die kurz-, mittel- und langfristigen Ziele deines Unternehmens einzahlt. Und ganz nebenbei kannst Du den ROI deines Vorhabens noch darlegen. Als Kapitän und Galionsfigur zugleich, steuerst Du das Vorhaben in eine vielversprechende Zukunft.

(D)Ein Produkt vom Markt nehmen

Nicht alle Geschichten haben ein Happy End. Und damit kommen wir zur fünften und sicher auch extremsten Verantwortung des Product Owners. Nämlich der Entscheidung, ob ein Vorhaben noch eine Daseinsberechtigung hat oder vielleicht doch lieber eingestellt werden sollte. Lass uns diese extreme Überlegung als Ausgangspunkt nehmen, um die Rolle des Product Owner abzurunden. Denn damit schließt sich der Kreis zu all den bis hier skizzierten Aufgaben. Wer wenn nicht der Product Owner, kann eine sinnvolle Empfehlung geben, ob eine Leistung noch benötigt wird? 

Der Product Owner als finaler Entscheidungsträger

Wenn Du als Entscheidungsträger deinem Product Owner die Entscheidung über die Einstellung nicht zutraust, dann setzt Du möglicherweise auf den falschen PO. Dann suchst Du vielleicht einen Produkt- oder Projektmanager aber keinen Product Owner. Nehmen wir also an, Du hast dieses Zutrauen und räumst deinem PO diese Entscheidung unter der Bedingung ein, dass er sich vor einem solch drastischen Schritt mit Dir und anderen Kollegen berät (Beraterprinzip). Damit gibst Du der Rolle des Product Owners einerseits die Bedeutung, die die Rolle erfordert. Andererseits vermeidest Du ungewollte Alleingänge im Interesse deiner Organisation. Wichtig ist dabei vor allem, dass ein gemeinsames Verständnis darüber herrscht, dass eine solche gewichtige Entscheidung immer auf Augenhöhe gemeinsam mit dem Product Owner getroffen wird. 

Der Product Owner im Scrum Framework

Durch die Einbettung in das Scrum Framework kannst Du die Rolle des Product Owners noch weiter konkretisieren. Diese Aufgaben sind eine Fortführung der oben genannten Aufgaben, die sich konkret aus dem Scrum Frameworks ergeben. 

Pflege und Organisation deines Backlog 

Die erste und vielleicht wichtigste Aufgabe als Scrum Product Owner in einem Scrum Team ist die Pflege und Priorisierung des Backlog. Dabei repräsentiert das Backlog alle Ideen und Anforderungen für die weitere Entwicklung des Vorhabens. In sogenannten Refinement-Meetings schärft der Product Owner die Anforderungen mit den Entwickeln, die den Aufwand der Umsetzung schätzen. Dazu greifen Scrum Teams auf agile Schätzverfahren wie z.B. das Planning Poker zurück. Auf Basis dieser Aufwandseinschätzung kann der Scrum Product Owner eine Kosten-Nutzen Abwägung treffen. Um damit die Anforderungen am höchsten im Backlog zu priorisieren, die den meisten Wert versprechen. Damit stellst Du als Product Owner sicher, dass die Entwickler immer an den werthaltigsten Aufgaben arbeiten. Nämlich genau jenen, die den meisten Nutzen für die Kunden und das Unternehmen versprechen. Die Pflege, Priorisierung und Organisation des Backlogs ist dabei dein wichtigstes Werkzeug.

User Stories, Epics und andere PBI’s

In der Organisation des Backlogs finden sich sehr große und noch etwas unscharfe Anforderungen und teils sehr konkrete Ideen für neue Leistungsmerkmale. Für die Pflege deines Backlogs ist es deswegen ratsam den unterschiedlichen Product Backlog Items (PBIs) eine gewisse Taxonomie und Kategorisierung zu geben. Je nach Umfang eines Vorhabens ist die Einrichtung und Pflege einer geeigneten Plattform zur Pflege deines Backlogs sehr umfangreich. Deswegen ist es bei technischen Vorhaben und der Verwendung entsprechender Plattformen (z.B. Jira, MS Dev Ops) sehr ratsam, wenn Entwickler oder der Scrum Master sich ebenfalls mit der Konfiguration der Plattform beschäftigen. 

Sprint Planning vorbereiten und Ziele ausgeben

Auf Basis des priorisierten Backlogs kommst Du als Product Owner deiner zweiten wichtigen Aufgabe nach, nämlich der Planung anstehender Sprints. Dazu trifft das Scrum Team sich zu Beginn des Sprints in einem Planning. Als Product Owner hast Du eine genaue Vorstellung davon, an welchen neuen Anforderungen im kommenden Sprint gearbeitet werden soll. Auf Basis einer gemeinsamen Diskussion während des Sprint Plannings verpflichten sich die Entwickler auf die Umsetzung der von Dir priorisierten Aufgaben. Das heißt, als Product Owner teilst Du nicht etwa Aufgaben zu, sondern das umsetzende Team trifft eine autonome Einschätzung darüber was machbar ist und was nicht. Deine Aufgabe ist das Sprint Planning vorzubereiten und ein Sprint Ziel zu formulieren. Darüber hinaus erläutert Du als Product Owner immer wieder den Kontext, wie das aktuelle Sprint Ziel auf mittelfristige Product Goals und die Vision deines Vorhabens einzahlt.

Über Releases entscheiden und Sprints stoppen

Die dritte wichtige Aufgabe des Product Owners in einem Scrum Team ist die Entscheidung über Releases, also Veröffentlichungen fertiggestellter Leistungsmerkmale. Denn nicht alle neuen von Dir priorisierten Funktionen können in einem Sprint umgesetzt werden. Möglicherweise gibt es für Dich als Product Owner auch taktische und strategische Gründe Arbeitsergebnisse erst zu einem bestimmten Zeitpunkt zu veröffentlichen. Die Entscheidung über einen Release bzw. wann ein fertiggestelltes Leistungsmerkmal den Kunden zur Verfügung gestellt wird, trifft alleine der Product Owner. Schließlich verantwortest Du die strategische Ausrichtung und den ROI des Produktes, demnach kann eine solche Entscheidung final nur bei Dir liegen. Eine Entscheidung von ähnlicher aber umgekehrter Tragweite ist die Entscheidung über den Stop des aktuellen Sprints. Solltest Du während eines Sprints feststellen, dass die im Planning verabschiedeten Anforderungen keinen Wert mehr versprechen oder aus anderen Gründen obsolet sind, kannst Du als Product Owner den Sprint stoppen. 

In technische Stories und die Definition of Done investieren

Die vierte und in meinem Verständnis oft unterschätzte Aufgabe des Product Owner ist in technische Stories und die Leistungsfähigkeit des Team zu investieren. Zwar willst Du als Product Owner am liebsten nur neue Features und sichtbare Ergebnisse für den Kunden priorisieren. Doch oft leidet darunter die technische Qualität und Du baust still und heimlich technische Schulden auf. Statt also nur in neue Features zu investieren, priorisierst Du in Absprache mit deinen Entwicklern auch technische Stories. Auch wenn Du kurzfristig einen geringeren Output hast, erntest Du mittel- und langfristig höhere Geschwindigkeit und Qualität in der Umsetzung. Zudem solltest Du als Product Owner auch darauf hinarbeiten, dass alle Teams unabhängig voneinander gegen die Definition of Done arbeiten können. Denn je mehr Teams unabhängig voneinander gegen die Definition of Done arbeiten können, desto mehr Wert kannst Du als Product Owner realisieren. 

Dein Beziehungsnetzwerk als Product Owner

Die Rolle des Product Owners ist sehr anspruchsvoll. Je größer und umfangreicher ein Produkt, ein Service oder Projekt, desto weitreichender und größer sind die Anforderungen und desto größer dein Beziehungsnetzwerk. Durch die Pflege deines Beziehungsnetzwerk stellst Du einerseits sicher, dass Du verschiedene Perspektiven kennenlernst, die dich für die weitere Entwicklung des Vorhabens vielleicht inspirieren. Zudem helfen Dir stabile Beziehungen, dass Du auch auf Hilfe zurückgreifen kannst, um in die Rolle des Product Owners hinein zu wachsen und darin aufzublühen.

Kunden

Deine erste und wichtigste Anspruchsgruppe sind natürlich Kunden. Als Product Owner pflegst und investierst Du in diese Beziehung als wären es deine Kinder. Du verstehst die Bedürfnisse deiner Kunden, kennst ihren Lebensalltag und kannst diese in Balance zu den Interessen deines Unternehmens in konkrete Anforderungen übersetzen. Um ein guter Product Owner zu sein, reicht es oft empathisch zu sein und die Bedürfnisse des Kunden in wirtschaftliche sinnvolle Anforderungen zu übersetzen. 

Diese Auseinandersetzung und Beziehungspflege mit echten Kunden ist übrigens nicht delegierbar. Auch wenn interne oder auch externe Partner Dich supporten können ist direkter und authentischer Kundenkontakt die wichtigste Säule in deinem Beziehungsnetzwerk.

Management

Die zweite wichtige Anspruchsgruppe ist das Management in deinem Unternehmen. Auch wenn Du als Product Owner eine hohe Autonomie genießt, darfst und sollst Du dich in deinen Überlegungen von deinen Kollegen begleiten, unterstützen und auch inspirieren lassen. In regelmäßigen Gesprächen mit dem Management lernst Du zu verstehen, wie dein Produkt, Service oder Projekt auf die Ziele und die Strategie deines Unternehmens einzahlt. Zudem darfst Du organisatorische Hürden und Blockaden gerne auch an das Management delegieren und sie bitten mit dazu beizutragen, dass dein Vorhaben noch mehr Wert schafft. In der Rolle als Product Owner bist Du außerdem der Ansprechpartner für das Management für inhaltliches Feedback zu deinem Vorhaben. Und als Product Owner in einem Scrum Team achtest Du natürlich darauf, dass die für dich wichtigen Stakeholder regelmäßig bei Demos und Reviews dabei sind. 

Entwickler 

Als Product Owner gibst Du durch die Priorisierung deines Backlog dem umsetzenden Team Arbeit. Das heißt, schlussendlich bist Du verantwortlich gegenüber den Entwicklern, dass sie nicht an sinnfreien Aufgaben arbeiten. Deine Beziehung zu Entwicklern ist dabei natürlich von Wertschätzung und Respekt geprägt. Sie helfen Dir deine Ideen und Anforderungen zu schärfen und geben Dir mit ihrer Schätzung zur Umsetzung überhaupt erst eine Basis, um eine sinnvolle Priorisierung zu treffen. Lass Dir von Entwicklern helfen technische Stories zu identifizieren und gemeinsam zu entscheiden, in welchem Ausmaß ihr in Kompetenzen und in gemeinsame Infrastruktur investiert. Bei sehr umfangreichen Produkten und vielen Teams, darfst Du Entwickler auch auffordern, ihre Rückfragen zu umsetzenden Aufgaben direkt mit Anwendern und Kunden zu klären, damit Du als Product Owner bei auftretenden Rückfragen nicht zum Bottleneck wirst.

Scrum Master

Schließlich ist der Scrum Master dein Coach, begleitet und befähigt dich wirksam in der Rolle des Product Owners zu arbeiten. Auch beim Scrum Master kannst Du Hilfe in Anspruch nehmen und ihn z.B. darum bitten dich bei der Organisation des Backlog und administrativen Aufgaben zu unterstützen, damit Du in der Rolle als Product Owner wirksam arbeiten kannst.

Product Owner Zertifizierung

Du kannst Dich offiziell als Product Owner zertifizieren lassen. Weltweit anerkannte Zertifikate werden von der scrum.org, der Scrum Alliance sowie der Scrum Inc. angeboten. Neben der Zertifizierung erhältst Du ein digitales Badge und wirst in die Liste der jeweiligen Organisation als professioneller Product Owner aufgenommen. So kannst Du leichter von potentiellen Arbeitgebern gefunden werden. In dieser Übersicht haben wir die alle Product Owner Zertifizierungen mit den jeweiligen Titeln und Prüfungsleistungen zusammengestellt.

Scrum Inc.

Die Scrum Inc. wurde 2006 von Jeff Sutherland, Mitbegründer des Scrum Framework, gegründet. Sutherland nimmt teilweise als Gastredner an den Kursen teil.

• Registered Product Owner™ (RPO)
• Gültigkeit 1 Jahr

Scrum Alliance

Die Scrum Alliance wurde von Ken Schwaber, Mitbegründer des Scrum Frameworks, im Jahr 2001 gegründet. 2009 verließ Ken Schwaber die Scrum Alliance und rief scrum.org ins Leben.

• Certified Scrum Product Owner (CSPO)
• Advanced Certified Product Owner (A-CSPO)
• Certified Scrum Professional Product Owner (CSP-PO)
• Zertifikate, Gültigkeit 2 Jahre

scrum.org

scrum.org ist seit 2009 die “Homebase” von Ken Schwaber, Mitbegründer des Scrum Frameworks.

• Professional Product Owner I (PSPO I)
• Professional Product Owner II (PSPO II)
• Professional Product Owner III (PSPO III)
• Zertifikate, lebenslang gültig

Die Scrum Inc. und Scrum Alliance setzen neben der Prüfung den Besuch eines Kurses voraus. Auf den Seiten der Scrum Inc., Scrum Alliance und scrum.org findest Du zertifizierte Anbieter von Kursen, die dich auf die Prüfungen vorbereiten. scrum.org empfiehlt den Besuch eines Kurses, setzt ihn aber nicht voraus.

Fazit – Don’t be Mr. Nice

Der Product Owner ist eine sehr umfangreiche und verantwortungsvolle Aufgabe. Aus Sicht des Unternehmens ist dabei der größte Wert, dass Du eine verantwortliche Person in eine end-to-end Verantwortung für ein Produkt oder ein Projekt bringst. Als Entscheidungsträger bist Du also bereit wichtige Entscheidungen von hoher Tragweite zu dezentralisieren bzw. in die Hände des Product Owners zu legen. Für dein Unternehmen kann das ein wichtiger Schritt sein, um schneller und anpassungsfähiger zu werden. 

Sofern Du die Rolle eines Product Owners übernimmst, wirst Du der Rolle möglicherweise viel Respekt entgegenbringen, schließlich geht damit viel Freiheit aber auch Verantwortung einher. Dabei erfordert die Rolle des Product Owners die Bereitschaft auch mal Entscheidungen und Priorisierungen zu treffen, die möglicherweise nicht allen Stakeholdern in deinem Unternehmen gefallen. Aber am Ende ist dein Auftrag den Wert eines Vorhabens aus Sicht deiner Kunden und deines Unternehmens zu maximieren. Da ist es ausgeschlossen der “Mr. Nice” für jedermann zu sein. Denn wie sagt schon Henry Mintzberg “No trade off, no strategy.” 

Viel Erfolg dabei.