Wenn jeder Stakeholder sein Thema zur höchsten Priorität erklärt, entscheidet der Product Owner darüber, woran das Team wirklich arbeitet. Genau hier zeigt sich, wie anspruchsvoll diese Rolle ist. Product Owner tragen die Verantwortung dafür, den Produktwert zu maximieren und gleichzeitig Markt, Stakeholder und Entwicklungsteam zusammenzubringen.
In diesem Artikel erfahren Sie, welche Aufgaben ein Product Owner übernimmt und welche Verantwortung damit verbunden ist. Sie lernen zentrale Anforderungen an Qualifikation, Product Backlog-Management und Nutzenmessung kennen.
Außerdem zeigt der Beitrag, welche Herausforderungen im Alltag auftreten und wie Sie damit umgehen können. So gewinnen Sie ein klares Bild dieser anspruchsvollen Rolle.
Product Owner maximieren den Wert eines Produkts und bringen Marktanforderungen, Stakeholder-Interessen und die Arbeit des Entwicklungsteams zusammen.
Zu den wichtigsten Aufgaben gehören Produktvision, Priorisierung, Stakeholder-Management und die kontinuierliche Pflege des Product Backlogs.
Gute Product Owner wägen Kosten, Zeit, Qualität und Produktnutzen gegeneinander ab und setzen klare Prioritäten.
Metriken zu Kundennutzen, Time-to-Market und Innovationsfähigkeit helfen Ihnen, den tatsächlichen Produkterfolg zu bewerten.
Zeitmangel, fehlende Entscheidungsgewalt und widersprüchliche Stakeholder-Interessen gehören zu den häufigsten Herausforderungen der Rolle.
Diese Kapitel warten auf Sie:
Los geht’s mit der Definition des Product Owner.
Product Owner Definition
Der Scrum Guide definiert: Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht. Wie dies geschieht, kann je nach Organisation, Scrum-Team und Einzelpersonen stark variieren.
Die Rolle des Product Owner kommt ursprünglich aus Scrum. Aber viele agile Entwicklungsteams haben jemanden, der die damit verbundenen Aufgaben wahrnimmt – auch wenn sie nicht nach Scrum arbeiten.
In Extreme Programming, einem anderen agilen Ansatz neben Scrum, gibt es beispielsweise die Rolle eines „On-Site Customers“ oder eines „Customer Proxy“ – also jemandem, der gegenüber den Developern die Kundensicht vertritt und dabei aber selbst Teil des Produktentwicklungsteams ist.
Die Notwendigkeit dafür leuchtet schnell ein: Die meisten agilen Teams befassen sich mit innovativen Lösungen. Dabei sind sie oft von der Entwicklung, Weiterentwicklung und Aufrechterhaltung, bis hin zur Ablösung, komplett für „ihr“ Produkt verantwortlich.
Sie brauchen also eine Person, die sich darum kümmert, dass diese Arbeit von Anfang an in die richtige Richtung geht. Das kann der Product Owner sein.
Die Rolle des Product Owner soll sicherstellen, dass das Produkt:
Um dieser sicherzustellen, sind wichtige Aufgaben des Product Owner im Detail:
Damit sorgt die Product Owner Rolle im umgekehrten, ergebnisoffenen Dreieck der agilen Welt die Hauptverantwortung für die Ausbalancierung und Priorisierung der Aspekte Inhalt, Kosten und Zeit.
Zusammen mit dem Team der Umsetzer ist ein Product Owner außerdem für die Einhaltung von Anforderungen an die Qualität zuständig. Einige Dreiecksmodelle nennen diese gerne als zusätzlich zu beachtende Dimension.
Insofern lässt sich tatsächlich sagen: Die Product Owner Rolle umfasst viel davon, was klassische Projektleitung beinhaltet.
Allerdings sind Projektmanagerinnen und Projektmanager auch für die Entwicklung des Projektteams, die Aufgabenverteilung an Projektmitarbeitende und deren Überwachung verantwortlich.
Sie können zudem bereits in der Projektinitiierung, wie etwa während der Projektauswahl oder Machbarkeitsprüfungen, in Erscheinung treten.
Dies ist bei der Product Owner Rolle meist anders:
Agile Product Owner kümmern sich um eine lösungsorientierte Produkt-Perspektive entlang des gesamten Lebenszyklus ihres Produkts. Sie denken an ihr Produkt und dessen Anwender:innen, inklusive betrieblicher Abläufe nach der Erstentwicklung. Dabei lösen sie sich von der reinen Projektdenke.
Eine frühe Aufgabe des Product Owner ist typischerweise das Erstellen eines initialen Backlogs (der Liste aller Anforderungen ans Produkt) zusammen mit den Stakeholdern – und eventuell dem Entwicklerteam oder Vertretern daraus.
Das Unterfangen wurde bereits z.B. durch das Produktmanagement entschieden, das im agilen Kontext meist eine übergeordnete Portfolioperspektive hat. Der Product Owner widmet sich hingegen der Umsetzung eines Produkts im Detail.
Teamentwicklung, Konflikte, Prozessgestaltung und Regeln für die Zusammenarbeit sind Sache agiler Coaches (in Scrum: Scrum Master). Sie helfen außerdem Product Ownern bei ihren Aufgaben, so dass diese bei Bedarf immer Unterstützung haben.
Die Aufgabenverteilung macht das selbstorganisierte Entwicklerteam unter sich aus. Auch übernimmt es dabei die Qualitätsverantwortung in den Iterationen weitgehend selbst. Das Team muss sich aber häufig mit dem Product Owner abstimmen, damit es hierbei nicht von Zielen, Anforderungen und Marktrealitäten abschweift.
Statt Berichtswesen zeigen die Developer anhand von regelmäßigen Demonstrationen ihrer Arbeitsergebnisse (z.B. neuen Funktionen im Produkt), wo sie stehen. Beim Product Review für die Stakeholder, am Ende der Iteration, tun Product Owner und Development dies nochmals gemeinsam für alle Personen außerhalb des agilen Produktteams. Gemeinsam übernehmen sie die Verantwortung für die eigenen Resultate.
Die wichtigste Verantwortung für die Product Owner Rolle ist es, verschiedene Faktoren gegeneinander abzuwägen und auszubalancieren:
Idealerweise können Product Owner in ihrer Rolle diese oftmals konträren Aspekte gut ausbalancieren. Das ist jedoch keine einfache Aufgabe. Um sie gut wahrzunehmen, sollten Personen in dieser Rolle Kenntnisse und Fähigkeiten erlangen und einsetzen, die auch für Projektmanager und Projektmanagerinnen wichtig sind.
Folgende Qualifikation, Kenntnisse und Fähigkeiten sollte ein Product Owner für seine Aufgaben haben:
Product Owner müssen also mehr können, als der Scrum Guide zu ihrer Rolle angibt.
Hierzu finden sich einige Aussagen im Scrum Guide. Dieser sagt Folgendes:
„Das Product Backlog-Management umfasst:
Natürlich reicht auch diese Liste im Scrum Guide allein für die Praxis nicht aus. Dazu ist sie auch keineswegs gedacht. Ein guter Product Owner ist jemand, der es schafft, Requirements Engineering im agilen Kontext zu betreiben.
Zur Verfeinerung des Product Backlogs gehören:
Was soll im Backlog stehen und was nicht? „Nein“ sagen zu können gegenüber Stakeholdern zu Anfragen, die zum gegenwärtigen Zeitpunkt unpassend oder unrealistisch sind. Ein Unternehmen muss Entscheidungen des Product Owner respektieren, auch wenn es manchmal schwerfällt. Dazu gehört zudem: Neue Einträge hinzufügen, sobald es nötig ist und überflüssig gewordene streichen.
Funktionsbeschreibungen, Spezifikationen, Bugfixes, nichtfunktionale Anforderungen etwa an Sicherheit, Skalierbarkeit, Wartbarkeit? Oder die ergebnisorientierte Lösungsbeschreibung aus Kundensicht (User Stories) in einem kurzen Satz? Sinnvoll ist die Mischung, da keiner dieser Eintragstypen alle Anforderungen an ein Produkt voll erfüllt.
Welche Anforderungen sind für welche Iteration und für welches Release vorgesehen? Konkret ist dies die Sache des gesamten Teams in der Iterationsplanung. Auch die meisten Stakeholder wollen hier gerne mitreden. Eine User Story Map kann hilfreich sein.
Das Einholen von groben, relativen Aufwandsschätzungen mit Story Points oder ähnlichem durch das Team. Denn auf Product Backlog-Ebene sind Anforderungen vor allem aus Anwendersicht formuliert. Das Herunterbrechen in Aufgaben erfolgt erst in der Iterationsplanung. Die Aufgaben kommen dann ins Iterations-Backlog.
Im Normalfall ist dies einfach eine lineare Liste im Product Backlog. Das heißt, die Priorität ergibt sich etwa aus der Reihenfolge: Dinge, die weit oben stehen, sind früher umzusetzen als Einträge weiter unten.
Unser Tipp: Formulieren und schätzen Sie nur die obersten Einträge im Backlog besonders gut. Nach unten hin ist dies weniger wichtig, denn diese Einträge könnten sich noch ändern oder ganz herausfallen.
Dieses Vorgehen nach dem „Just-in-Time“-Prinzip hilft Ihnen, Verschwendung durch Aufwand für nicht zeitnah anstehende Anforderungen zu vermeiden. Es folgt den DEEP-Kriterien.
Auf diese Weise stellen Sie sicher, dass Ihr Arbeiten mit Product Backlogs agilen Denkweisen folgt und nicht etwa eine Wasserfallplanung mit neuem Namen ist.
Unser Tipp: Wenn Ihnen eine flache, lineare Backlog-Priorisierung nicht ausreicht, können Sie sich mit User Story Mapping als erweiterte Technik zum mehrdimensionalen Backlog-Management auseinandersetzen.
Was sind Metriken zum Messen von Produktnutzen? Diese Frage ist in dieser oder ähnlicher Form beliebt in Product Owner-Zertifizierungsprüfungen wie etwa der Scrum.org.
Sie ist zunächst schwer verständlich: Wie messen wir als Team den Wert unseres Produkts? Rein anhand unserer Produktivität sicherlich nicht – diese kann hoch sein, aber wenn die Ergebnisse in die falsche Richtung gehen, bringt uns das kaum etwas.
Tatsächlich gibt das „Evidence-based Management“ einige Metriken vor, die noch teilweise unbekannt sind. Für Product Owner können sie jedoch sehr hilfreich sein.
Das Evidence-based Management kennt vier Hauptkategorien, in die einzelne Metriken fallen:
Er misst, wie das Produkt am Markt angenommen und genutzt wird. Aber es beachtet auch, wie gut die Stimmung im Team derer ist, die es entwickeln. Wie zufrieden sind mögliche Investoren?
Beispielmetriken: Die in diese Kategorie fallen, sind etwa: Kundenzufriedenheitsindizes (bspw. aus Umfragen und Produktfeedback generiert), Messungen der Nutzung einzelner Funktionen im Vergleich zur Kundenzufriedenheit mit diesen.
Er misst, wie lange es dauert vom Zeitpunkt, wenn eine neue Anforderung zum ersten Mal formuliert wird, bis der Urheber die Lösung in der Hand hält. Wie schnell lernen wir aus neuen Informationen und verwerten sie?
Beispielmetriken: Release-Häufigkeit, Integrationshäufigkeit, Durchlaufzeit von Backlog-Einträgen, Vorlaufzeit.
Dies ermittelt, wie innovativ die Lösungsfindung ist. Wie neuartig sind die Funktionen und das Produkt generell? Diese Frage sollte auch bei der Weiterentwicklung an gewachsenen Systemen in Großkonzernen gestellt werden.
Beispielmetriken: Nutzung einzelner Funktionen im Vergleich zu anderen, Aufwand oder Kosten für Neuentwicklung (in Prozent) gegenüber reaktiven Tätigkeiten wie Wartung, Messung der Zeit, die das Team tatsächlich am Produkt beschäftigt ist (im Vergleich zu anderen Aufgaben).
Hier geht es darum, welches Potenzial momentan noch nicht ausgeschöpft ist. Wie sinnvoll wäre es, sich damit einmal näher zu beschäftigen?
Beispielmetriken: Marktanteil, Erwartungen der Anwender im Vergleich zu dem, was sie bekommen.
Unser Tipp: Richtig wirkungsvoll sind solche Metriken, wenn Sie diese über längere Zeit hinweg erfassen. Dann können Sie Entwicklungen und Trends recht gut erkennen.
Lesetipp: 3 Jira Tipps für Product Owner, die Sie kennen sollten
Bislang haben Sie die Rolle des Product Owner und einige wichtige Werkzeuge und Aufgaben im Detail kennengelernt. Jetzt erfahren Sie, welchen Herausforderungen Product Owner in ihrem Alltag häufig begegnen.
Umfragen durch agile Coaches unter Product Ownern und Developern haben ergeben, dass das vor allem die folgenden Herausforderungen sind:
Mögliche Probleme: Die Rolle darf nicht in Vollzeit ausgefüllt werden, sondern muss noch neben Linienarbeiten stattfinden. Es sind zu viele Produkte und Teams gleichzeitig zu betreuen. Die Balance zwischen Zeit für Stakeholder und für die Teams ist schwer.
Mögliche Lösung: Ursachenanalyse: Was ist wirklich der Grund für die Zeitprobleme? Was lässt sich ändern? Gibt es Zeitmanagement-Methoden, die helfen könnten? Vielleicht hilft eine Repriorisierung von Projekten und Anforderungen?
Mögliche Probleme: Der Product Owner weiß zu wenig über die eigene Rolle und agile Entwicklung. Die Rolle wird oft einfach vergeben ohne weitere Erklärung oder Training.
Mögliche Lösung: Weiterbildung, Literatur wie etwa das sehr zu empfehlende Buch „Der professionelle Product Owner“ von Don McGreal und Ralph Jocham.
Mögliche Probleme: Der Product Owner kennt nötige / wichtige Dokumente und Metriken für seine Arbeit nicht.
Mögliche Lösung: Auseinandersetzung mit Tools zur Erstellung von Produktvisionen, Impact-, Story- und Roadmaps, Release-Planungsstrategien, Evidence-based Management, Stakeholderanalyse-Werkzeugen.
Mögliche Probleme: Der Product Owner ist nicht autorisiert zu entscheiden. Eskalationspfade sind zu kompliziert und langwierig.
Mögliche Lösung: Eskalation und Diskussion solcher Probleme auf Metaebene mit dem Management
Mögliche Probleme: Mangelnde Beteiligung und Interesse durch die Stakeholder, Konflikte unter Stakeholdern bzgl. Festsetzung von Prioritäten, zu viele Stakeholder.
Mögliche Lösung: Stakeholderanalyse, Moderationstechniken erlernen und anwenden, Anforderungsanalyse zusammen mit Stakeholdern, etwa m. H. eines Product Vision Canvas, Einbinden agiler Coaches.
Mögliche Probleme: Hohe Organisationskomplexität und Silo-Symptome
Mögliche Lösung: Verkürzen der Feedback-Loops mithilfe agiler Coaches
Mögliche Probleme: Projekte mit vielen verschiedenen Firmen als Beteiligte. Der Product Owner und die Developer gehören unterschiedlichen Firmen an.
Mögliche Lösung: Dies muss nicht automatisch ein Problem sein, es ist aber ein Thema, mit dem bewusst umgegangen werden sollte: Vertragsgestaltung und Teamvereinbarungen helfen.
Mögliche Probleme: Das Umfeld / die Branche erschwert leichtgewichtige Arbeitsweisen durch Prozessüberbau.
Mögliche Lösung: Situative Intelligenz und Konzentration auf eine gute Fehlerkultur und möglichst schnelles Lernen angesichts der äußeren Umstände.
Product Owner können und müssen all diese Probleme nicht allein lösen. Hier sind oft das Management und die Beteiligung aller Betroffenen sowie zusätzlich gutes Coaching gefragt.
Unser Tipp: Wenn in Ihrem Unternehmen einige der oben beschriebenen Probleme auftreten, lohnt es sich sicherlich, diese möglichst frühzeitig an die zuständige Stelle zu adressieren.
In diesem Artikel haben Sie unter anderem erfahren, welche Aufgaben und Verantwortungen ein Product Owner hat, welche Herausforderungen von ihm zu meistern sind, welche Metriken zur Messung von Produktnutzen es gibt und welche Inhalte das Product Backlog-Management umfasst.
Zusammenfassend lässt sich sagen: Gute Product Owner können ganz wesentlich zum Erfolg eines Unternehmens am Markt beitragen. Sie sind somit in einer sehr spannenden und einflussreichen Position voller Möglichkeiten.
Aber die Rolle muss sich gegebenenfalls auch mit schwierigen Herausforderungen auseinandersetzen.
Daher sollten Sie, wenn Sie sich in der Rolle des Product Owner befinden oder diese anstreben, auf permanente Fortbildung einstellen: methodisch, toolseitig und besonders auch im zwischenmenschlichen Umgang.
Haben Sie noch Fragen zum Thema Product Owner? Dann freuen wir uns auf Ihre Kontaktaufnahme über das Kontaktformular oder auf anderem Wege. Wir antworten so schnell wie möglich – garantiert.
Unsere Tipps zum Schluss: Abonnieren Sie unseren Projektmanagement Newsletter mit mehr praxisstarken Artikeln, Webinaren, Podcasts, eBooks, Checklisten, Tools etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!
Ist Ihre Neugier geweckt? Dann probieren sie agile Methoden mit Ihren Team und in Ihrem Projekt aus! Und wenn Sie Ihr Wissen ausbauen wollen, dann ziehen Sie doch eine Weiterbildung in Betracht – etwa zum Professional Scrum Master (PSM I) oder zum PMI Agile Certified Practitioner.