Product Owner: Rolle, Verantwortlichkeiten und Aufgaben

Product Owner als Rolle im Scrum-Team 

Das Scrum-Team ist eine „geschlossene Einheit von Fachleuten“ (Scrum Guide). Innerhalb des Scrum-Frameworks arbeitet es selbstorganisiert und verteilt die Verantwortung auf die drei Rollen Scrum Master, Entwickler*innen und Product Owner. Es existiert keine Hierarchie zwischen den Rollen. Alle Teammitglieder arbeiten auf Augenhöhe an einem gemeinsamen Ziel, nur mit unterschiedlichen Verantwortlichkeiten und Aufgaben.

Das crossfunktionale Team verfügt idealerweise über alle fachlichen Kompetenzen und Fähigkeiten, die für die Entwicklung der jeweiligen Lösung notwendig sind und kann deswegen weitgehend eigenständig agieren.

Product Owner: Rolle und Verantwortlichkeiten

Im Scrum-Team ist der Product Owner Vertreter der Kund*innen und Schnittstelle zwischen Team und allen internen sowie externen Stakeholder*innen. Sein oberstes Ziel ist, mit dem zu entwickelnden Produkt einen Mehrwert für Kund*innen zu schaffen. Hierbei sucht der Product Owner immer einen Ausgleich zwischen Kundenbedürfnissen und den Geschäftsinteressen des Unternehmens: Neben seinem breiten Wissen über die Zielgruppe und die Marktsituation bezieht er die strategischen Zielsetzungen und den Nutzen für seine Organisation in alle Überlegungen ein.

Benjamin Britten, Lead Product Owner bei Shop Apotheke, erklärt dies im Interview so: „Wenn ich 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. Ich finde es unfassbar befriedigend, etwas zu erschaffen, das Wert schafft, weil es meiner Tätigkeit einen Sinn gibt.“

Die wichtigsten Aktivitäten des Product Owners sind:

• Langfristiges Ziel definieren: Entwicklung einer Produktvision
• Interessen sichtbar machen: Informationen von Kund*innen und allen anderen Stakeholder*innen sammeln und strukturieren (z. B. durch Interviews)
• Produktelemente (Inkremente) ableiten: User oder Job Stories schreiben und als Einträge im Product Backlog einbringen, Verfeinern der Einträge mit dem Team (z. B. im Backlog Refinement) und Formulierung von Akzeptanzkriterien für die einzelnen Einträge
• Qualitätsstandards definieren: Anforderungen formulieren, Definition of Done und Definition of Ready mit dem Team erarbeiten
• Prioritäten festlegen: Priorisierung der Backlog-Einträge, Festlegung der Reihenfolge, in der die Einträge bearbeitet werden (im Dialog mit dem Team)
• Releases managen: Entscheidung über die Veröffentlichung von Produktbestandteilen

Product Owner hat keine hierarchische Verantwortung

Im Vergleich zu Projektleiter*innen oder klassischen Führungskräften nehmen Product Owner eine komplett neue Rolle ein: Sie sind nicht der Vorgesetzte, der hierarchische Verantwortung für das Team und die Arbeitsergebnisse übernimmt. Ihre Verantwortung liegt auf dem Produkt und dessen Wertsteigerung. Die ganzheitliche Verantwortung liegt im Team.

Kunden kennen

Kundenzentrierung ist einer der wichtigsten agilen Werte und spielt in der Produktentwicklung mit Scrum eine zentrale Rolle: Voraussetzung für die Entwicklung eines bedarfsgerechten Produkts ist ein tiefes Wissen über die Kund*innen und ihre Bedürfnisse. Der Product Owner setzt sich deswegen permanent mit der Zielgruppe und den Marktanforderungen auseinander.

In vielen Scrum-Teams unterstützen UX-Expert*innen den Product Owner hierbei. Sie recherchieren die notwendigen (Kunden-)Informationen und Markterkenntnisse, aus denen der PO die Bedürfnisse und Interessen der Kunden ergründet und im Product Backlog verarbeitet.

Wert für Unternehmen stiften

Darüber hinaus entwickelt der PO bei der Gestaltung des Produkts, Services oder der Lösung des Teams eine Balance zwischen den Interessen der Kund*innen, Nutzer*innen, des Unternehmens sowie der übrigen Stakeholder*innen. Somit hat der Product Owner immer die Unternehmensstrategie im Fokus. Von seiner Haltung sollte der PO deswegen auch immer selbst ein Unternehmer sein und sich folgende Fragen stellen: Wie zahlt unser Produkt auf die übergeordneten Ziele ein? Wie profitiert unser Unternehmen von dem Produkt?

Ein Hilfsmittel, die Unternehmensstrategie in den Teamalltag zu integrieren, ist das Lean Strategy Board.  Das Canvas-Tool visualisiert die zentralen Elemente der Strategie, aktuelle Herausforderungen und die strategischen Zielbilder. Hiermit behalten agile Teams die Strategie immer im Blick. Durch die integrierten Objective & Key Results (OKR) und Initiativen können Teams das Board zudem nutzen, um die Strategie ins operative Geschäft zu übersetzen und ihren Anteil daran zu messen.

Darüber hinaus ist der PO im ständigen Austausch mit Vertreter*inen aus dem Unternehmen, die wichtigen Input liefern können. Das können Ansprechpartner*innen aus der Unternehmensführung sein. Genauso gefragt sind aber auch beispielsweise Gespräche mit dem Vertrieb oder der Kommunikationsabteilung, die wichtige Hinweise zu Verkaufs- oder Vermarktungsmöglichkeiten geben.

Bei der Pflege des Backlogs und der Priorisierung der Anforderungen muss der Product Owner also immer die Ebenen Kundenbedürfnisse und Unternehmensziele einbeziehen und miteinander abwägen.

Entscheidungsverantwortung für den Produktwert

Als Produktverantwortlicher steht der Product Owner für die Qualität des zu entwickelnden Produkts ein. Das bedeutet auch: Innerhalb der Organisation muss er selbstbestimmt und unabhängig entscheiden können. Natürlich ist er offen für Argumente und Meinungen, letztendlich trägt der PO aber die Entscheidungsverantwortung hinsichtlich der Produktentwicklung.

Der PO entscheidet, welche Anforderungen in das Product Backlog aufgenommen werden und in welcher Reihenfolge die Backlog-Einträge bearbeitet werden. Auch wenn die Priorisierung in der Praxis oft im Dialog mit dem Team geschieht, liegt die endgültige Entscheidung bei ihm. Möchte jemand die Backlog-Items ändern oder Einfluss auf die Priorisierung nehmen, muss er den PO von der Notwendigkeit und dem Mehrwert überzeugen. In seiner Rolle muss der Product Owner damit auch die Bereitschaft mitbringen, „unbequeme“ Entscheidungen zu treffen, die nicht jedem innerhalb der Organisation gefallen. Sein Fokus liegt dabei immer darauf, Mehrwert für Kund*innen und das Unternehmen zu schaffen.

Aufgaben des Product Owners

Neben dem oben beschriebenen Rollenverständnis und Verantwortlichkeiten hat der Product Owner im Wesentlichen drei Aufgabenbereiche, die er im Scrum-Team wahrnimmt:

• Backlog-Management: Der PO entwickelt eine Produktvision und erstellt die Backlog-Items. Zudem priorisiert er diese „Unteraufgaben“ und sorgt für einen transparenten, sicheren und verständlichen Product Backlog.
• Stakeholder-Management: Als Schnittstelle steht er im ständigen Austausch mit Stakeholder*innen des Produkts (Kund*innen, Unternehmensvertreter*innen) und bezieht deren Interessen und Anforderungen ein.
• Release-Management: Das Team kann während des Scrum-Sprints jederzeit ausliefern. Der PO hat immer im Blick, wann entwickelte Produkt-Inkremente veröffentlicht werden (können).

Backlog-Management: mehr als nur Anforderungen sammeln und priorisieren

Der Product Owner ist „Hüter des Backlogs“. Im Product Backlog werden alle User Stories, Anforderungen und Aufgaben gesammelt, die notwendig für die Entwicklung des Produkts sind. Eine der wichtigsten PO-Aufgaben ist das Management und die Pflege des Backlogs. Dies umfasst folgende Tätigkeiten:

• Entwicklung und Kommunikation einer Produktvision
• Erstellung und Kommunikation der Product-Backlog-Einträge
• Festlegung der Reihenfolge der Einträge (Priorisierung)
• Sicherstellung, dass das Product Backlog transparent, sichtbar und verstanden ist

Teile dieser Aufgaben kann der Product Owner ans Team delegieren (beispielsweise die Erstellung der Backlog-Items). Dabei bleibt er aber weiterhin ergebnisverantwortlich für den Produkt-Mehrwert. Wichtig ist, dass der PO über alle Einträge informiert ist. Wenn andere Teammitglieder Backlog-Items erstellen, sollten sie sich zuvor mit ihm absprechen. In der Praxis erfolgt die Formulierung der Einträge in enger Abstimmung zwischen PO und Entwicklungsteam. Ein geeigneter Rahmen, um darüber zu sprechen und die Items weiter zu verfeinern, ist das Backlog Refinement.

„Ich muss das ‚große Ganze‘ im Blick haben“, erklärt Andreas Schneider, Product Owner in der Zukunftswerkstatt der DEVK Versicherungen. „Ich muss dafür sorgen, dass wir die nächsten Sprints planen können, mit Stakeholder*innen sprechen, Anforderungen aufnehmen, Stories schreiben und unser Backlog im Blick halten. Dabei versuche ich, das Backlog vorausschauend genug zu planen, sodass Stories für circa die nächsten drei Monate vorbereitet und gepflegt sind. “

Entwicklung einer Produktvision

Eine der wichtigsten Aufgaben des Product Owners ist die Entwicklung und regelmäßige Aktualisierung einer Produktvision. Dieses Zielbild vom finalen Produkt bildet den Grundstein für die Produktentwicklung, alle Aktivitäten sind darauf ausgerichtet.

Bei der Formulierung der Produktvision stehen drei Überlegungen im Vordergrund:

• Kund*innen/Zielgruppe: Welche Zielgruppe sprechen wir an? Wer sind unsere Kund*innen?
• Kundenbedürfnisse: Welche Probleme möchten wir mit unserem Produkt lösen? Welche Vorteile bietet es? Und was ist unser Versprechen an die Nutzer*innen (Value Proposition)?
• Wert für das Unternehmen: Welche Unternehmensziele unterstützen wir mit der Entwicklung des Produkts? Wie zahlen wir mit dem Produkt auf die Unternehmensstrategie ein?

Die Produktvision ist ein Statement, das den zentralen Wert der Lösung betont. Sie ist eindeutig formuliert, einfach zu verstehen, motivierend und handlungsweisend.

Eine gute Vision fördert die Bindung des Teams an das Produkt und die Identifikation mit den gemeinsamen Zielen. Sie ist damit ausschlaggebend für die erfolgreiche Entwicklung. Sie sollte offen kommuniziert und idealerweise mit den Zielen und Aufgaben verbunden werden: Jedes Teammitglied muss die Vision kennen und auf sie hinarbeiten. Wir empfehlen, die Produktvision jederzeit für das Team sichtbar zu machen. Sie kann quasi als „Überschrift“ über dem Backlog fungieren. Wenn Sie mit einem physischen Board arbeiten, platzieren Sie die Produktvision an prominenter Stelle, damit das Team sie immer vor Augen hat.

Die Vision hilft dem Team,

• die wichtigsten Merkmale des Produkts zu verstehen,
• die Aufgaben zu priorisieren sowie einzuschätzen, welche Features umgesetzt werden müssen, um einen Mehrwert für Kunden zu schaffen und
• zu erkennen, wie die Entwicklung des Produkts die Strategie und Ziele des Unternehmens unterstützt.

Erstellung der Product-Backlog-Einträge

Das Product Backlog ist keine fixe Liste, die einmal aufgestellt, priorisiert und dann abgearbeitet wird. Es ist dynamisch und verändert sich über die Zeit: Durch die Erkenntnisse aus den Sprints und (zusätzliche) Anforderungen der Stakeholder*innen erweitert sich das Backlog. Es kommt aber natürlich auch vor, dass Backlog-Items entfernt werden, wenn sie nicht mehr notwendig sind.

Aufgabe des Product Owners ist es, dies immer im Blick zu haben. Er schreibt neue Backlog-Items, aktualisiert bestehende, stellt Akzeptanzkriterien für die Items auf und löscht Einträge, die obsolet geworden sind. All dies geschieht in enger Abstimmung mit dem Entwicklungsteam.

Backlog-Items erklären, was gemacht werden soll und bündeln Anforderungen der Kund*innen und Stakeholder*innen an das Produkt in Epics, User Stories, Tasks oder Bugs:

• Epic: Ein Epic ist eine größere Anforderung, die nicht in einem Sprint erledigt werden kann. Es wird in der Regel in mehrere User Stories aufgesplittet oder in kleinere Items unterteilt.
• User Story: Hierbei handelt es sich um eine Anforderung, die innerhalb eines Sprints abgeschlossen werden kann und Mehrwert für den Nutzer liefert. User Stories sind aus der Sicht des Endkunden verfasst.
• Task: Ein Task ist eine einzelne Aufgabe innerhalb einer User Story, die üblicherweise von einer Person bearbeitet werden kann.
• Bug: Bugs sind funktionale Fehler, die die Nutzung des Produkts erschweren oder behindern. Der Begriff “Bug” stammt aus der Softwareentwicklung. Aber auch in der Entwicklung physischer Produkte kann es zu Fehlern kommen, die die Nutzerfreundlichkeit erschweren und durch eine neue Lösung oder Fehlerbeseitigung behoben werden müssen.

„Als Product Owner nehme ich die Anforderungen aus dem Geschäft und die Kundenbedürfnisse auf“, erklärt Mathias Kruse, Product Owner bei Giesecke+Devrient im Gespräch. „Die User Stories schreibe ich gezielt so, dass die Entwickler zwar die Richtung sehen, in die es gehen soll, aber selbst die Entscheidung treffen können, wie sie dahin kommen.“

Backlog Refinement: gemeinsames Verständnis gewinnen

Product Owner und Entwicklungsteam können die Backlog-Items zu jedem Zeitpunkt erstellen. Damit sich das Team synchronisiert und ein gemeinsames Verständnis für das Product Backlog besteht, empfiehlt sich ein regelmäßiges Backlog Refinement. In diesem Meeting bereitet das Team die Backlog-Items für das Sprint Planning vor: Ein gut gepflegtes Backlog macht das Planungstreffen deutlich effizienter.

PO und Entwickler*innen besprechen die hoch priorisierten Einträge und arbeiten diese weiter aus. So werden beispielsweise neue User Stories aufgenommen und formuliert oder bestehende mit neuen Informationen angereichert. Das Team nimmt unter Umständen auch eine Neu-Priorisierung des Backlogs vor, falls sich die Situationen geändert hat oder neue Informationen vorliegen.

Priorisierung der Backlog-Einträge

Eine der wichtigsten Aufgaben des Product Owners ist die Priorisierung der Backlog-Einträge. Er legt die Reihenfolge der Bearbeitung fest und sortiert das Backlog so, dass die Items mit dem höchsten Kundennutzen oben stehen. Diese Priorisierung ist immens wichtig, um die Arbeit des Scrum-Teams effektiver zu gestalten und Störungen von außen möglichst zu vermeiden.

Die Verantwortung für die Priorisierung liegt beim Product Owner, für eine effektive Zusammenarbeit sollte das Team den Entscheidungen folgen und sie akzeptieren. Aus diesem Grund nimmt der PO die Priorisierung oft gemeinsam bzw. im Austausch mit den Entwickler*innen vor.

„Die Priorisierung erfolgt in Absprache mit den Entwicklern, die wichtige Perspektiven aus der operativen Arbeit einbringen. Die letztendliche Entscheidung treffe aber ich“, beschreibt Mathias Kruse das Vorgehen in seinem Team. „In der Praxis läuft das so, dass ich die Richtung vorgebe. Es gibt einen groben Phasenplan, den wir im Team besprechen. Zusätzlich machen wir eine Aufwandschätzung im Team, was im jeweiligen Sprint umgesetzt werden kann. Wenn im Doing dann rauskommt, dass wir das in der gegebenen Zeit nicht schaffen, dann müssen wir die Priorisierung ändern oder anpassen.“

Basis der Priorisierung ist eine Aufwand- und Nutzenabwägung. Ist der Nutzen (für Kund*innen/das Unternehmen) groß genug, dass sich der Aufwand in der Umsetzung lohnt? Bei der Priorisierung der einzelnen Backlog-Items helfen beispielsweise das Kano-Modell, die MoSCoW-Priorisierung oder auch die Eisenhower-Matrix.

• Kano-Modell: Hierbei handelt es sich um eine vom japanischen Wissenschaftler Noriaki Kano entwickelte Befragungsmethode. Das Kano-Modell der Kundenzufriedenheit ermittelt die Wünsche und Erwartungen von Kund*innen an ein Produkt und teilt diese in 5 Merkmale ein (Basismerkmale, Leistungsmerkmale, Begeisterungsmerkmale, unerhebliche Merkmale, Rückweisungsmerkmale).

• MoSCoW-Priorisierung: Mit dieser Methode lassen sich Anforderungen und Ideen an ein Produkt oder Projekt in vier Kategorien einteilen: M (Must have), S (Should have), C (Could have) und W (Won´t have).

• Eisenhower-Matrix: Eine schnelle und eindeutige Priorisierung ist mit der Eisenhower-Matrix möglich (auch Eisenhower-Prinzip, benannt nach dem ehemaligen US-amerikanischen Präsidenten Dwight D. Eisenhower). Die Matrix teilt Aufgaben in die zwei grundlegenden Kriterien „Wichtigkeit“(wichtig/unwichtig)  und „Dringlichkeit“ (dringend/nicht-dringend) ein. Die Eisenhower-Matrix ermöglicht vier Kombinationsmöglichkeiten (wichtig/dringend, wichtig/nicht-dringend, unwichtig/dringend, unwichtig/nicht-dringend), nach denen Aufgaben eingeteilt und priorisiert werden können. Die am höchsten priorisierten Aufgaben finden sich in der Matrix demzufolge im Feld „wichtig/dringend“. Für den Scrum-Kontext ist es eventuell sinnvoll, die Matrix anzupassen und in die Kriterien „Nutzen“ (hoch/gering) und „Aufwand“ (hoch/gering) umzubenennen.

Vorbereitung des Sprint Planning

Ein gut gepflegtes und priorisiertes Backlog ist die beste Vorbereitung für das Sprint Planning. In diesem Scrum-Event plant das Scrum-Team den anstehenden Sprint. Der Product Owner bereitet für das Planungstreffen ein Sprintziel vor und definiert die Backlog-Items, die zum Erreichen des Ziels im Sprint umgesetzt werden sollen.

Hierbei ist es wichtig, dass der PO bei der Vorstellung des Sprintziels und der umzusetzenden Items auch immer den Kontext erklärt, wie diese Auswahl auf die langfristige Produktvision einzahlt.

Die Entscheidung über das endgültige Sprintziel treffen die Entwickler*innen und der Product Owner gemeinsam im Sprint Planning. Auch über die Umsetzung der vorgeschlagenen Backlog-Einträge diskutieren sie im Planungstreffen. Der PO teilt diese Aufgaben nicht zu, das Team entscheidet am Ende eigenständig, wie viel Arbeit es im Sprint übernimmt.

Stakeholder-Management: ständiger Austausch mit Interessensgruppen

Neben der Pflege, Kommunikation und Priorisierung des Product Backlogs ist das Stakeholder-Management eine weitere zentrale Aufgabe des Product Owners. In der Regel haben viele Stakeholder*innen Interesse an der Entwicklung des Produkts:

• Kund*innen
• Konsument*innen
• Partner*innen
• Unternehmensführung
• Management
• Fachexpert*innen
• spezielle Gruppen, wie Bewerber*innen, Presse, Politik oder die allgemeine Öffentlichkeit

„Meine Empfehlung ist es, seine Stakeholder aktiv zu managen: Im Idealfall bindest du deine Umwelt so tief ein, dass du nicht dauernd ins Kreuzfeuer der Anforderungen gerätst“, sagt Benjamin Britten, Lead Product Owner bei Shop Apotheke. „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.“

Bedürfnisse ermitteln

Der Product Owner steht in ständigem Kontakt mit diesen Gruppen. Er kategorisiert sie nach Relevanz (beispielsweise durch Stakeholder Mapping oder mithilfe einer Stakeholder-Matrix), baut Beziehungen zu ihnen auf und erarbeitet Bedürfnisse und Anforderungen. Durch die Aufnahme aller relevanten Anforderungen sorgt er für ein sinnvoll strukturiertes und priorisiertes Backlog.

Der Product Owner holt beispielsweise fachliche Anforderungen aus den Fachbereichen des Unternehmens ein. Dies geschieht beispielsweise über Briefings oder Workshops. Zu seinen Aufgaben gehört es hier, die relevanten Aspekten herauszufiltern und ins Backlog zu überführen. Das kann auch bedeuten, dass er widersprüchliche Anforderungen aufdecken und hierfür Lösungen mit den Staheholder*innen entwickelt. Dies kann beispielsweise in Problem-Solution-Workshops passieren.

Wissen über die Kund*innen, Konsument*innen oder die Zielgruppe können der Product Owner und das Scrum-Team mit unterschiedlichen agilen Methoden aufbauen. So können sie die Eigenschaften, Bedürfnisse und Herausforderungen ihrer Zielgruppe beispielsweise mithilfe von Umfragen (z. B. mit dem kostenlosen Online-Tool SurveyMonkey) oder Tiefeninterviews herausarbeiten. Wichtige Daten finden sich in Online-Quellen wie z. B. beim Statistischen Bundesamt oder Statista. Helfen können auch Vorgehensmodelle wie Design Thinking oder Methoden wie Empathy Maps oder Personas.

Erwartungsmanagement

Zu seiner Aufgabe gehört es auch, die festgelegte Priorisierung der Backlog-Einträge gegenüber den Stakeholder*innen zu erklären. Es mag nicht immer allen Kolleg*innen im Unternehmen gefallen, welche Anforderungen wann entwickelt werden. Jede*r Stakeholder*in hält seine Idee in der Regel für die wichtigste und dementsprechend sollte sie auch umgehend umgesetzt werden. Letztendlich entscheidet der PO (gemeinsam mit dem Team) über die Umsetzung – und muss dies auch gegenüber den Anspruchsgruppen kommunizieren.

DEVK-Product-Owner Andreas Schneider erklärt seine Aufgabe so: „Ich versuche dem Team den Rücken freizuhalten, damit es sich auf die Aufgaben des aktuellen Sprints fokussieren kann. Ich sitze in vielen Runden als Teamvertreter. Nicht als ‚Chef‘, der Entscheidungen trifft, sondern um die gemeinsamen Interessen des Teams zu vertreten.“

Release-Management: Entscheidung über die Veröffentlichung

Im Sprint-Zyklus existieren keine festen Releasedaten. Der feste Rahmen bedeutet nicht, dass das Team nur am Ende des Sprints ein oder mehrere Produkt-Inkremente ausliefern muss. Idealerweise gibt es mehrere Releases während des Sprints. Der Product Owner muss immer wissen, wann die Releases stattfinden und im Blick haben, wann die entwickelten Lösungen dem Nutzer zur Verfügung stehen.

Die Entwickler*innen entscheiden, wie ein Backlog-Item umgesetzt wird und wann es „fertig“ ist. Hierfür beziehen sie sich in der Regel auf die im Team festgelegte Definition of Done. Diese führt Kriterien auf, wann ein Eintrag als umgesetzt gilt. Da der Product Owner die strategische Zielsetzung des Produkts verantwortet, liegt die letztendliche Entscheidung über die Veröffentlichung bei ihm.

Diese Entscheidungsautorität führt auch dazu, dass der Product Owner der Einzige ist, der einen Sprint vorzeitig stoppen kann. Es kommt vor, dass der PO oder die Entwickler*innen im Sprint feststellen, dass die geplanten Anforderungen (aus unterschiedlichen Gründen) nutzlos geworden oder überholt sind. Dann kann der Product Owner „die Reißleine ziehen“ und den Sprint beenden.

Product Owner: Fähigkeiten und Kompetenzen

Der Product Owner übernimmt im Scrum-Team zahlreiche Verantwortlichkeiten und Aufgaben. Ein Product Owner sollte demnach einige Fähigkeiten und Kompetenzen mitbringen, um die Rolle auszufüllen:

• Fachliche Expertise und breites Produkt-Wissen: Der Product Owner ist ergebnisverantwortlich für die Produktentwicklung. Er muss also das Produkt in der Tiefe verstehen. Gleichzeitig sollte er den Wert des Produkts für das Unternehmen, Markterfordernisse und Kundenbedürfnisse erkennen und bewerten können. Dies erfordert eine tiefe fachliche Expertise und breites Wissen über Produkt und die Marktanforderungen.
• Analytisches Denkvermögen: Ein Product Owner trägt viele Informationen zusammen und analysiert, gewichtet sowie priorisiert sie: Anforderungen aus dem Unternehmen an das Produkt, Bedürfnisse und Probleme der Kund*innen, Erkenntnisse über den Wettbewerb. Sein analytisches Denkvermögen hilft ihm dabei, die relevantesten Informationen herauszufiltern und zu effektiven Entscheidungen zu kommen.
• Kommunikationsfähigkeiten: Der PO kommuniziert mit vielen Gruppen: Er schwört sein Team auf die Produktvision ein und spricht mit Unternehmensvertretern und Kund*innen. Er sollte somit über gute Kommunikationsfähigkeiten verfügen und ein Empathievermögen für verschiedene Anspruchsgruppen besitzen. Eine gute Kommunikation in alle Richtungen ist entscheidend für eine erfolgreiche Produktentwicklung. Dazu gehört, dass er auch „Nein“ zu bestimmten Anforderungen sagen muss (und dank dem Prinzip der Selbstführung agiler Teams auch kann).
• Methodenwissen: Darüber hinaus sollte der PO ein gutes Verständnis von agilen Methoden mitbringen für die Team-Zusammenarbeit, die Erforschung von Kundenbedürfnissen und zum Aufbau von Produktvision und -strategie (hierbei helfen beispielsweise das Wardley Mapping oder das Value Proposition Canvas). Auch Wissen zu Modellen aus der Verhaltensforschung (z. B. das Fogg Behavior Model oder das Hook-Modell) sind wichtig für die PO-Rolle.
• Übernahme von Verantwortung: Der Product Owner übernimmt die Verantwortung für den Mehrwert des Produkts. Er engagiert sich für die Vision, das Produkt, Team, Unternehmen und Kund*innen. Als Verantwortlicher übernimmt er Ownership über den Prozess, nimmt an allen Meetings zum Thema teil und arbeitet mit allen Teammitgliedern zusammen.

Wie werde ich Product Owner?

Zunächst einmal können Sie sich auf eine ausgeschriebene Stelle als Product Owner bewerben, wenn Sie die beschriebenen Fähigkeiten mitbringen und die Anforderungen des Unternehmens erfüllen. Oft werden PO-Stellen in Unternehmen auch durch geeignete Mitarbeitende besetzt.

Natürlich spielt „Learning on the Job“ auch beim Product Owner eine wichtige Rolle. Insofern ist ein Quereinstieg in die Rolle möglich. Viele Unternehmen verlangen allerdings eine offizielle Schulung zum Product Owner, die über eine Zertifizierung nachgewiesen werden kann.

Die bekanntesten sind die zwei Zertifikate von Scrum Alliance und Scrum.org:

• Certified Scrum Product Owner® (Scrum Alliance): Erforderlich für die Erlangung des Zertifikats sind eine Schulung durch einen Certified Scrum Trainer oder einen Certified Enterprise Coach mit anschließendem Test.
• Professional Scrum Product Owner™ (Scrum.org): Hier muss nur der Test bestanden werden. Wie Sie sich das Wissen hierfür aneignen, ist Ihnen überlassen.

Beide Organisationen bieten zudem weitere Fortbildungen für zertifizierte PO an: Bei der Scrum Alliance können Sie sich zum „Advanced Certified Scrum Product Owner“ zertifizieren lassen. Scrum.org bietet zusätzlich die Zertifizierung Professional Scrum Product Owner II und III an.

Mit diesen Schulungen lernen Sie die scrum-bezogenen Aufgaben eines Product Owners kennen. Damit Sie eine gute Vision entwickeln, die Bedürfnisse von Stakeholder*innen ermitteln und lernen, ein gutes Produkt zu entwickeln, braucht es jedoch mehr als eine zweitägige Schulung.

Konferenzen und Ausbildungen

Viele Product Owner bilden sich auf Konferenzen für ihre Aufgaben fort oder aus. Es gibt einige gute und anerkannte Formate, bei denen sich Product Owner das notwendige Wissen verschaffen können. Hier eine kleine Auswahl aus unserer Sicht empfehlenswerter Veranstaltungen:

• From Business to Buttons: Die Konferenz für User Experience and Service Design findet jährlich in Stockholm (Schweden) statt.
• UXLx User Experience Lisbon: Auf Europas größter UX-Konferenz im portugiesischen Lissabon treffen sich jährlich Product Owner, UX-Expert*innen oder Entwickler*innen.
• Mind the Product: Unter dem Banner “Mind the Product” finden jährlich mehrere Konferenzen zum Thema Produktmanagement statt. Die drei wichtigsten sind in San Francisco (USA), London (England) und eine regionale Konferenz in Hamburg (Deutschland).

Neben den oben genannten Zertifizierungen gibt es einige hilfreiche Ausbildungen, die Product Owner auf ihre Aufgaben vorbereiten:

• Die Product Owner Ausbildung von Me & Company: Unser eigenes Weiterbildungsformat setzt auf eine fundierte, berufsbegleitende Ausbildung mit insgesamt 14 Trainingstagen, verteilt auf sieben Monate. Damit bieten wir eine der inhaltlich umfangreichsten Fortbildungen für Product Owner im deutschsprachigen Raum an.
• Design Thinking – Professional Track: In dieser Fortbildung lernen Teilnehmende die Prinzipien des Design Thinking und die wichtigsten Tools der Innovationsmethode kennen.
• MAS Product Management: Das Programm vermittelt die fachlichen Grundlagen und Managementkompetenzen für ein erfolgreiches Produktmanagement.
• CAS Product Management: Kunden- und werteorientiert: Im Zentrum des Kurses stehen Produktmanagementmethoden und Führungswerte.

Zusammenfassung

Als eine der drei Scrum-Rollen entwickelt der Product Owner eine Vision für das zu entwickelnde Produkt. Zudem übernimmt er Verantwortung für die stetige Steigerung des Produktnutzens. Seine Hauptaufgaben sind das Management des Product Backlogs, der stetige Austausch mit Stakeholder*innen und das Release-Management. Der Product Owner ist nicht der Vorgesetzte des Scrum-Teams, sondern ein Teammitglied mit anderen Aufgaben und Verantwortlichkeiten.

Ein guter Product Owner ist Fachexpert*in in seinem Bereich. Er besitzt analytisches Denkvermögen und verfügt über gute Kommunikationsfähigkeiten. Zudem ist er bereit, Verantwortung im Team und Unternehmen zu übernehmen.