Der Dreh- und Angelpunkt heutiger agiler Teams ist der Product Owner (PO). Eine Rolle, die fast schon als übermenschlich wahrgenommen wird: Visionär, Kundenversteher, Manager, Teamleader und Technikkenner in Personalunion. Der Product Owner soll alles können und alle Erwartungen erfüllen. Doch wie realistisch ist dieses Idealbild? Wird hier nicht zu oft die „eierlegende Wollmilchsau“ gefordert, die letztlich zu Überforderung und Frustration führt? Zu ineffektiven Prozessen, die die Erfolgschancen eines Projekts massiv beeinträchtigen?
Die Aufgaben eines Product Owners – eine gigantische Liste?
Ein Product Owner trägt die zentrale Verantwortung dafür, dass sich die Investitionen in das Produkt bezahlt machen. Scrum selbst beschreibt die Rolle sehr leichtgewichtig und lässt damit Raum für eine passende Ausgestaltung im jeweiligen Kontext. In der Praxis wird daraus allerdings meist eine lange Liste an Aufgaben, die dem Product Owner zugewiesen werden. Verständlich, dass viele Product Owner bei der Menge an Aufgaben schnell an ihre Grenzen stoßen. Ursache für Überforderung ist aber nicht allein die reine Menge an Aufgaben, sondern die hierfür notwendigen Kompetenzen.
Product Owner müssen also Fähigkeiten vereinen, die normalerweise ein ganzes Expertenteam erfordern würden. Sie müssen Business-Verständnis, Fachkenntnisse, Design-Fähigkeit, technische Grundkenntnisse, Management- und Führungsfähigkeit besitzen. Die hierfür nötigen Kompetenzen in einer Person zu vereinen, ist nahezu unmöglich. Niemand ist alles auf einmal: herausragender Analyst, empathischer Kundenversteher, knallharter Verhandlungsführer und obendrein Experte für Produktmanagement. Die Realität zeigt, dass Product Owner überfordert sind, wenn sie versuchen, diese vielschichtigen Rollen allein zu bewältigen. Die Folgen: Frustration und Burnout.
Zusätzlich erschweren organisatorische Rahmenbedingungen die Rolle. Statt echter Teamarbeit herrscht oft ein nebeneinanderher Arbeiten von Individuen, unterstützt durch möglichst detaillierte Rollenbeschreibungen wie RACI-Matrizen, mit denen festgelegt wird, was jemand gerade nicht tun muss. Die Folge: Alles, was zwischen die Fugen fällt, bleibt beim Product Owner kleben, dem außerdem die Entscheidungsgewalt fehlt, was zu endlosen Abstimmungsrunden führt – besonders in skalierten Umgebungen wie SAFe. Langwierige Entscheidungen, endlose Diskussionsschleifen, teilweise ganz ohne Ergebnis, ständige Rückfragen, Rückdelegation ans Team, ungesteuerte Teams sind die Folge. Schlechte Product Ownership kann schwerwiegende Konsequenzen für das gesamte Unternehmen haben und zu einer Abwärtsspirale führen.
Der Product Owner …
… entwickelt die Vision
… nimmt das Team auf strategischer Ebene mit
… unterstützt das Team bei der taktischen Umsetzung
… gibt dem Team die notwendigen inhaltlichen Informationen
… ist verantwortlich für den wirtschaftlichen Erfolg
… übernimmt das Planning und Refinement
… pflegt das Backlog
… beschreibt die Items in Form von User Stories
… reviewt die Sprintergebnisse
… präsentiert den Fortschritt
… übernimmt das Stakeholder-Management
… macht Terminaussagen gegenüber dem Management
10 Regeln, um Product Owner zu entlasten und Projekte zum Erfolg zu führen
Welche Möglichkeiten gibt es nun Product Owner zu entlasten? In unserer Praxis haben sich die folgenden 10 Regeln bewährt:
1. Erwartungen des Auftraggebers frühzeitig klären: Eine gründliche Auftragsklärung ist der Schlüssel zum Erfolg: Mit dem Auftraggeber oder Vorgesetzten müssen Erwartungen klar definiert werden. Sollten dabei Kompetenzlücken erkennbar werden, müssen diese offen angesprochen werden und klar sein, wie diese abgedeckt werden.
2. Entscheidungsbefugnisse auch leben: Der PO muss über die nötigen Entscheidungsbefugnisse verfügen, um effektiv arbeiten zu können. Eine klar ausgesprochene und vor allem eingehaltene Befugnis verhindert, dass Entscheidungsprozesse zermürben und unnötig lang werden. Der Delegation-Poker aus Management 3.0 kann dabei helfen, diesen Spielraum abzustecken.
3. Effizientes Stakeholder-Management betreiben: Passendes Stakeholder-Management ist stark vom Kontext abhängig und häufig profitieren POs auch von den spontanen und niederschwelligen Abstimmungen mit Stakeholdern. Sind aber viele Stakeholder einzubinden, ist eine strikte Strukturierung der Kommunikation angesagt. Das Sprint-Review sollte der Dreh- und Angelpunkt der Stakeholder-Kommunikation sein und nicht zum Jira-Abhakmeeting degenerieren.
4. Micromanagement vermeiden: Nicht jede Entscheidung muss vom Product Owner selbst getroffen werden. Ein PO sollte auf die Fähigkeiten seines Teams vertrauen und delegieren können. Micromanagement führt nur zu Frustration und ineffizienten Prozessen.
5. Nicht vom Tagesgeschäft auffressen lassen: Auch wenn es manchmal nötig ist, sich mit den kleinen Details des Tagesgeschäfts zu beschäftigen: Strategische Arbeit ist die Pflicht des Product Owners.
6. Den Fokus auf Outcomes statt Outputs legen: Statt nur im Sinne einer „Feature Factory“ auf die Menge der umgesetzten Features zu schauen, sollte sich der Product Owner auf den Mehrwert für den Kunden fokussieren. Das hilft, Prioritäten zu setzen und die Produktvision im Blick zu behalten.
7. Auch mal fünfe gerade sein lassen: Da der Job als Product Owner per se sehr fordernd ist, sollte er sich gut überlegen, in welche Konflikte er wirklich gehen muss und wo es vielleicht auch mal besser ist, einfach fünfe gerade sein zu lassen.
8. Stärken im Team nutzen: Ein starkes, crossfunktional besetztes Team, das alle Kompetenzfelder abdeckt, kann viele Aufgaben gemeinsam bewältigen. Der PO profitiert von einem Team, das eigenverantwortlich arbeitet und Lösungen eigenständig entwickelt.
9. Dem Product Owner eine „Rechte Hand“ zur Seite stellen: Ein von uns häufig beobachtetes hilfreiches Muster ist, dass es im Team mindestens eine Person gibt, die enger als die anderen Teammitglieder mit dem PO zusammenarbeitet. Diese Person nimmt dem Product Owner operative Tätigkeiten ab, wie das Backlog-Refinement oder die Klärung inhaltlicher Detailfragen.
10. Unterstützung des Scrum Masters nutzen: Es ist die klare Verantwortung des Scrum Masters, den PO darin zu befähigen, seine Aufgabe gut erfüllen zu können. Das bedeutet weniger die konkrete operative Mitarbeit, sondern das Coaching des Product Owners, das Bereitstellen von passenden Methoden, Trainings und die Beseitigung von organisatorischen Hindernissen. Der echte Mehrwert eines Scrum Masters kann daran gemessen werden, wie effizient der Product Owner seiner Verantwortung gerecht werden kann.
Ganz wichtig: PO ist nicht gleich PO! Die eine Person mag hervorragend geeignet sein, in einem Start-up ein innovatives neues Produkt zu entwickeln, die andere kann ihre Fähigkeiten bei der Weiterentwicklung eines 20 Jahren alten Systems voll zur Geltung bringen. Am besten achtet man natürlich schon bei der Besetzung auf den passenden Fit und nimmt nicht einfach die nächstbeste Person, die frei ist.
Nicht vergessen: Über diese Punkte immer wieder reflektieren! Dafür bietet sich zum Beispiel die Retrospektive an. Aber natürlich auch die Einzelarbeit zwischen Scrum Master und Product Owner.
Mehr Fokus auf die Menschen, weniger auf die Theorie
Der Product Owner ist zweifellos eine Schlüsselposition in modernen Softwareprojekten. Um erfolgreich zu sein, müssen Unternehmen aufhören, die Position als eierlegende Wollmilchsau zu betrachten. Durch gezielte Entlastung und eine Fokussierung auf die Stärken der Menschen im Team werden Projekte nicht nur effizienter, sondern auch menschlicher.
Über Ute Nause & Jonathan Frankenberger:
Ute Nause, Geschäftsführerin bei BettercallPaul, ist seit 30 Jahren als ITBeraterin und fachliche Chefdesignerin in Großprojekten tätig. Ihre Leidenschaft ist es, mit Strukturierungsfähigkeit und Designkompetenz langfristig tragfähige IT-Landschaften zu gestalten.
Jonathan Frankenberger ist Agile Coach bei BettercallPaul und bringt seit 2016 sein Wissen aus 20 Jahren Projektgeschäft in agile Rollen ein. Sein Fokus liegt auf der Verbesserung von Softwareentwicklung und der Gestaltung moderner Organisationsstrukturen, um optimale Bedingungen für Produktteams zu gewährleisten.
