"The Product Owner – Die am meisten missverstandene Rolle"

Dezember 2025 11 Min. Lesezeit Meinung + Erfahrung

Der Product Owner ist die entscheidendste Rolle in Scrum. Und gleichzeitig jene, der am konsequentesten die Entscheidungshoheit entzogen wird, die sie zum Funktionieren braucht. Was nach diesem Entzug übrig bleibt, ist kein Product Owner. Es ist ein Backlog-Verwalter mit beeindruckendem Jobtitel.

---

Der Einstieg: Eine Rolle ohne Macht ist keine Rolle

Fragen Sie zehn Organisationen, was ihr Product Owner macht. Sie bekommen zehn ähnliche Antworten: zuständig für den Backlog, priorisiert Stories, nimmt an Ceremonies teil, kommuniziert mit Stakeholdern. Fragen Sie dieselben zehn Organisationen, ob ihr Product Owner eigenständig eine Sprint-Priorität ändern kann – ohne Management-Freigabe. Ob er einem Senior-Stakeholder eine Feature-Anfrage ablehnen kann. Ob er einen Sprint abbrechen kann, wenn das Sprint Goal hinfällig wird.

Beobachten Sie, wie viele Hände oben bleiben.

Die Product Owner-Rolle, wie sie der Scrum Guide beschreibt, ist eine der anspruchsvollsten in jeder Softwareorganisation. Sie erfordert echte Entscheidungskompetenz, tiefes Produktwissen, kontinuierliche Stakeholder-Einbindung und den politischen Mut, mächtigen Personen regelmäßig Nein zu sagen. Was die meisten Organisationen stattdessen geschaffen haben, ist eine Koordinationsrolle im Product-Owner-Gewand – und dann wundern sie sich, warum ihre Produktentwicklung langsam, fokuslos und losgelöst von dem ist, was Kunden tatsächlich brauchen.

---

Die Realität: Was die meisten Product Owner wirklich sind

In zwanzig Jahren Arbeit in Enterprise-Umgebungen habe ich Product Owner erlebt, die von wirklich außergewöhnlich bis aktiv schädlich reichten. Die Verteilung ist nicht ermutigend. Hier sind die vier häufigsten Product-Owner-Archetypen, denen ich begegnet bin – keiner davon entspricht dem, was der Scrum Guide beschreibt.

Archetyp 1: Der Proxy

Die häufigste Variante. Der eigentliche Entscheider – ein Senior Manager, ein Direktor, ein “Business Owner” – hat keine Zeit, direkt mit dem Team zu arbeiten. Also ernennen sie jemand Rangniedrigeres zum Product Owner. Diese Person nimmt an Ceremonies teil, pflegt den Backlog und schreibt User Stories. Für jede bedeutende Entscheidung – Priorisierungsänderungen, Scope-Trade-offs, strategische Ausrichtung – muss sie zurück zum echten Entscheider und um Genehmigung bitten.

Das Ergebnis ist vorhersehbar. Entscheidungen, die Stunden dauern sollten, dauern Tage. Das Team wartet. Abhängigkeiten häufen sich an. Der Backlog spiegelt wider, was der echte Entscheider zuletzt gesagt hat, dass er will – was möglicherweise nicht dem entspricht, was Kunden tatsächlich brauchen. Der Product Owner sitzt in jedem Meeting, hat aber in keinem davon Entscheidungsgewalt.

Archetyp 2: Der Ausschuss-Sekretär

Schlimmer als der Proxy. Statt eines echten Entscheiders im Hintergrund gibt es ein Komitee. Der Product Owner nimmt an Steering-Group-Meetings teil, hält Entscheidungen fest und übersetzt sie in Backlog-Items. Er ist im Grunde die Schnittstelle zwischen einer Gruppe von Menschen, die sich nicht auf Prioritäten einigen können, und einem Entwicklungsteam, das klare Prioritäten zum Funktionieren benötigt.

Der Product Backlog in diesem Szenario spiegelt politischen Kompromiss statt strategische Klarheit wider. Die Items mit höchster Priorität sind jene, die beim Komitee den geringsten Widerspruch erzeugt haben – nicht jene, die den größten Wert liefern. Das Team baut, worauf sich das Komitee einigen kann. Kunden bekommen, worauf sich das Komitee einigen kann. Niemand ist überrascht, wenn das Ergebnis nicht dem entspricht, was der Markt tatsächlich will.

Archetyp 3: Der Feature-Sammler

Dieser Product Owner hat echten Zugang zu Stakeholdern und echtes Interesse daran, ihre Bedürfnisse zu verstehen. Das Problem: Er behandelt jede Stakeholder-Anfrage als gleich valide und gleich dringend. Der Backlog wächst kontinuierlich. Prioritäten verschieben sich mit jedem Stakeholder-Gespräch. Das Team schließt nichts ab, weil die Definition von “am wichtigsten” schneller wechselt, als das Team liefern kann.

Der Feature-Sammler ist oft beliebt und gutmeinend. Er reagiert auf Stakeholder, hat Beziehungen quer durch die Organisation und arbeitet extrem hart. Er verhindert aber auch systematisch, dass sein Team Wert liefert – weil er die schwierigen Priorisierungsentscheidungen nicht trifft, die den Kern der Product-Owner-Rolle ausmachen.

Archetyp 4: Der technische Backlog-Manager

Häufig in technologiegetriebenen Organisationen. Dieser Product Owner ist oft ein ehemaliger Entwickler oder Technical Lead, der in die Rolle befördert wurde. Er versteht die technische Arbeit tiefgehend und schreibt ausgezeichnete User Stories. Was ihm fehlt, ist die Business- und Kundenperspektive, die die Priorisierung antreiben sollte. Der Backlog ist technisch kohärent und strategisch orientierungslos. Das Team baut Dinge, die wunderschön funktionieren und die niemand bestellt hat.

Der gemeinsame Nenner: Alle vier Archetypen teilen eine Eigenschaft – sie füllen eine Product-Owner-förmige Lücke, ohne die Entscheidungshoheit, das Mandat oder die Kundennähe zu besitzen, die die Rolle tatsächlich erfordert. Die Organisation hat den Titel. Die Rolle hat sie nicht.

---

Der Checksum: Was der Scrum Guide tatsächlich fordert

Der Scrum Guide 2020 ist eindeutig in Bezug auf die Verantwortlichkeiten des Product Owners. Drei Punkte stechen als in der Praxis konsequent verletzt hervor.

Eine Person, kein Komitee

Der Scrum Guide stellt explizit fest: “Der Product Owner ist eine Person, kein Komitee.” Er geht weiter: “Wer den Product Backlog ändern möchte, kann dies tun, indem er versucht, den Product Owner zu überzeugen.” Nicht durch E-Mails an die Steering Group. Nicht durch Eskalation zum Vorgesetzten des Product Owners. Durch Überzeugen des Product Owners.

Das erfordert, dass der Product Owner echte Entscheidungshoheit hat – und echte organisatorische Rückendeckung für diese Hoheit. In den meisten Organisationen existiert diese Rückendeckung nicht. Senior-Stakeholder, die ihre Features nicht priorisiert bekommen, gehen am Product Owner vorbei zu ihren eigenen Senior-Kontakten. Die Entscheidungen des Product Owners werden überstimmt. Die Rolle wird bedeutungslos.

Den Backlog ordnen, nicht nur pflegen

Der Scrum Guide sagt, der Product Owner ist verantwortlich für das “Ordnen” des Product Backlogs – nicht nur für dessen Pflege oder Refinement. Ordnen impliziert aktive, kontinuierliche Priorisierung auf Basis von Wert. Es impliziert, Dinge abzulehnen, die es nicht in die engere Auswahl schaffen. Es erfordert den Mut, einen Backlog zu führen, in dem Item 47 wahrscheinlich nie gebaut wird – und dazu ehrlich zu sein.

Die meisten Product Backlogs sind nicht geordnet. Sie sind angesammelt. Items werden oben hinzugefügt, wenn Stakeholder dringend sind, unten hinzugefügt, wenn Stakeholder höflich sind, und in der Mitte umgeschichtet, wenn niemand hinschaut. Der Product Owner verwaltet die Zugänge. Er trifft nicht die harten Entscheidungen darüber, was nie erledigt werden wird.

Verantwortlich für Produktwert

Der Scrum Guide macht den Product Owner verantwortlich für die “Maximierung des Werts des Produkts, der aus der Arbeit des Scrum Teams resultiert.” Das ist eine Ergebnis-Verantwortlichkeit, keine Aktivitäts-Verantwortlichkeit. Der Product Owner ist nicht verantwortlich dafür, einen gesunden Backlog zu pflegen, an Sprint Reviews teilzunehmen oder gut strukturierte User Stories zu schreiben. Er ist verantwortlich dafür, ob das Produkt Wert liefert.

Fast keine Organisation hält ihren Product Owner für Produktwert verantwortlich. Er wird verantwortlich gemacht für Backlog-Hygiene, Story-Qualität, Stakeholder-Zufriedenheit. Wert, der an Kunden geliefert wird, wird – wenn überhaupt – auf einer Ebene weit oberhalb der Entlohnungsstufe des Product Owners gemessen.

“Ein Product Owner ohne Entscheidungshoheit über seinen Backlog ist wie ein Koch ohne Zugang zur Küche. Der Titel stimmt. Die Stellenbeschreibung nicht.” Markus – agile-checksum.com

---

Praxisbeispiele: Die Lücke in der Realität

Die überstimmte Priorität

Eine Product Ownerin bei einem großen Logistikunternehmen hatte ihren Backlog sorgfältig geordnet – auf Basis von Kundenforschung, Umsatzwirkungsanalyse und technischem Dependency-Mapping. Das Item mit höchster Priorität war ein kundenseitiges Tracking-Feature, das laut Forschung das Support-Anrufvolumen um geschätzte 30 % reduziert hätte.

Zwei Wochen vor dem Sprint, in dem dieses Feature starten sollte, bat ein Senior Sales Director darum, ein anderes Feature – ein internes Reporting-Dashboard, das er für eine Kundenpräsentation benötigte – an die Spitze des Backlogs zu setzen. Die Product Ownerin erklärte die Priorisierungslogik. Der Sales Director eskalierte zu ihrem Vorgesetzten. Der Vorgesetzte forderte sie auf, der Anfrage nachzugeben. Das Tracking-Feature wurde um zwei Sprints verzögert. Das Reporting-Dashboard wurde gebaut und einmal genutzt.

Die Product Ownerin hatte alles richtig gemacht. Die Organisation hatte unmissverständlich gezeigt, dass ihre Entscheidungshoheit genau so weit reichte, wie Senior Management bereit war, sie zu stützen – was nicht sehr weit war.

Der Backlog mit 600 Items

Eine Product Ownerin, die ich coachte, übernahm einen Backlog mit 623 Items. Die ältesten Items waren vier Jahre alt. Niemand hatte sie seit Jahren angeschaut. Die Product Ownerin verbrachte jeden Sprint erhebliche Zeit in Backlog-Refinement-Sessions damit, Items zu schätzen und zu besprechen, die realistisch keine Chance hatten, je gebaut zu werden.

Als ich vorschlug, alles zu löschen, was älter als achtzehn Monate war und im letzten Quartal nicht besprochen worden war, war die Reaktion Entsetzen. “Wir können die nicht löschen – Stakeholder haben sie angefragt.” Als ich fragte, ob diese Stakeholder noch im Unternehmen arbeiteten, ob sie noch dieselben Prioritäten hatten oder sich überhaupt noch an die Anfragen erinnern würden, war die Antwort ungewiss. Der Backlog war zu einem Museum vergangener Gespräche geworden, gepflegt aus politischer Angst statt strategischer Absicht.

Wir löschten 340 Items. Kein einziger Stakeholder bemerkte es. Keine einzige Beschwerde wurde erhoben. Die Planungssessions des Teams wurden 40 % kürzer. Die Product Ownerin nutzte die gewonnene Zeit, um mit Kunden zu sprechen. Die Lieferung des nächsten Quartals war die fokussierteste und wertvollste in der Geschichte des Produkts.

Der Product Owner, der niemals falsch lag

Ein Product Owner bei einem Fintech-Startup hatte starke Meinungen und eine überzeugende Persönlichkeit. Er war effektiv darin, seine Prioritäten in den Sprint zu bekommen. Weniger effektiv war er darin, zu validieren, ob diese Prioritäten richtig waren. Kundenfeedback aus Sprint Reviews wurde durch seine bestehenden Überzeugungen gefiltert. Daten, die seiner Produktintuition widersprachen, wurden wegerklärt. Das Team baute, was er wollte – konsequent und effizient.

Nach achtzehn Monaten brachte ein Wettbewerber ein Produkt auf den Markt, das mehrere Kundenbedürfnisse adressierte, die das Team konsequent deprioritisiert hatte. Die Marktreaktion war erheblich. Als ich hinzugezogen wurde, um die Situation zu beurteilen, fand ich ein Produkt, das technisch hervorragend, effizient geliefert und zunehmend unausgerichtet mit dem war, was Kunden tatsächlich brauchten. Der Product Owner hatte seine eigene Produktvision maximiert. Er hatte nicht Wert maximiert.

---

Wie ein echter Product Owner aussieht

Echter Product Owner	Häufiger Ersatz
Kann einem Senior-Stakeholder Nein sagen, ohne zu eskalieren	Braucht Management-Freigabe für jede Prioritätsänderung
Trifft Priorisierungsentscheidungen auf Basis von Wertnachweisen	Priorisiert nach Lautstärke und Seniorität der Stakeholder
Löscht aktiv Backlog-Items, die nie gebaut werden	Pflegt jedes angeforderte Item auf unbestimmte Zeit
Nimmt an Sprint Reviews teil, um Feedback zu bekommen, nicht um zu präsentieren	Nutzt Sprint Reviews, um Fortschritt dem Management zu demonstrieren
Misst Erfolg am Wert, der Kunden geliefert wird	Misst Erfolg an Backlog-Gesundheit und Story-Abschluss
Verbringt mehr Zeit mit Kunden als in Refinement-Meetings	Verbringt die meiste Zeit mit der Verwaltung von Stakeholder-Anfragen und Backlog-Items

---

Das Fazit: Zuerst das Autoritätsproblem lösen

Die meisten Product-Owner-Probleme sind keine Product-Owner-Probleme. Es sind organisatorische Autoritätsprobleme, die sich in der Product-Owner-Rolle manifestieren. Die Person in der Rolle gibt häufig ihr Bestes unter Einschränkungen, die die korrekte Ausübung der Rolle unmöglich machen.

Wer einen funktionierenden Product Owner will, muss organisatorische Fragen stellen, keine individuellen. Fragen danach, ob die Organisation bereit ist, einer Person echte Entscheidungshoheit über die Ausrichtung eines Produkts zu geben. Ob Senior-Stakeholder bereit sind, ihren Fall dem Product Owner zu machen statt an ihm vorbei. Ob das Management bereit ist, die Entscheidungen des Product Owners zu stützen, auch wenn diese Entscheidungen unbequem sind.

Das sind keine einfachen Fragen. Sie erfordern organisatorischen Wandel, keine Trainingsprogramme. Ein Product-Owner-Zertifizierungskurs gibt niemandem Entscheidungshoheit. Das kann nur die Organisation tun.

Führen Sie den Checksum für Ihren Product Owner durch:

1. Nennen Sie das letzte Mal, als Ihr Product Owner einem Senior-Stakeholder Nein sagte und die Entscheidung ohne Eskalation Bestand hatte.
2. Wie viele Items in Ihrem aktuellen Product Backlog wurden in den letzten drei Monaten nicht besprochen? Was ist der Plan dafür?
3. Welche Metrik nutzt Ihr Product Owner, um zu messen, ob der letzte Sprint Wert geliefert hat? Ist es eine Business-Outcome-Metrik oder eine Aktivitätsmetrik?

Die Antworten zeigen Ihnen, ob Sie einen Product Owner oder einen Backlog-Verwalter haben. Beides kann nützlich sein. Aber nur eines davon entspricht dem, was der Scrum Guide beschreibt.

“Die Product-Owner-Rolle ist keine Koordinationsrolle. Sie ist eine Führungsrolle. Behandeln Sie sie als solche – oder wundern Sie sich nicht, wenn Ihr Produkt sehr effizient nirgendwohin gelangt.” Markus – agile-checksum.com

---

Im Artikel verwendete Glossarbegriffe

• Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts und die Verwaltung des Product Backlogs.
• Backlog – Eine geordnete Liste von Arbeitsitems, die alles repräsentiert, woran ein Team arbeiten könnte.
• Scrum – Ein leichtgewichtiges Framework zur Entwicklung und Lieferung komplexer Produkte.
• Sprint Review – Ein Scrum-Event, bei dem das Team und Stakeholder das Increment inspizieren und den Product Backlog anpassen.
• Definition of Done – Die gemeinsame Vereinbarung, was “fertig” für ein Produktinkrement bedeutet.