Machen es Unternehmen den Product-Ownern absichtlich schwer?
Manchmal kommt es mir so vor. Wahrscheinlich, weil viele Führungskräfte selbst nicht verstehen, was es heißt, ein Produkt zu verantworten.
Und SAFe, der Saboteur agiler Softwareentwicklung, flüstert ihnen gefährliches Halbwissen ins Ohr.
In diesem Artikel möchte ich einmal die 5 Fallstricke vorstellen, die mir in über 10 Jahren im Produktmanagement mit Scrum begegnet sind. Und eines vorweg: Nicht jeder Fallstrick wird Product-Ownern von Unternehmensseite vor die Füße gelegt.
Los geht’s ...
Fallstrick #1: Das Unternehmen degradiert Product-Owner zu „Backlog-Schreibern“
Es ist kein Geheimnis. Viele Product-Owner sind überlastet.
Die Hälfte der Zeit verbringen sie in Abstimmungsmeetings. Die andere Hälfte damit, Tickets in Jira zu formulieren. Damit werden Product-Owner ungewollt zum administrativen Flaschenhals der Entwicklung.
Und jetzt kommt das Absurde:
Der Scrum Guide beschreibt die Rolle eines Product-Owners keineswegs so. Der Product-Owner ist für effektives Product-Backlog-Management verantwortlich. Das umfasst – ich zitiere –:
„Product-Backlog-Einträge zu erstellen und klar zu kommunizieren“.
Und jetzt kommt die Stelle, die fast jeder überliest:
„Der Product-Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren.“
Das ist der Unterschied zwischen Verantwortung und Zuständigkeit.
Product-Owner übernehmen die Verantwortung dafür, dass die Einträge erstellt sind. Aber sie sind nicht dafür zuständig, sie auch selbst zu erstellen. Wenn Unternehmen Product-Owner trotzdem in diese Rolle pressen, passiert etwas sehr Vorhersehbares:
Product-Owner verstricken sich in operativer Kleinarbeit.
Wie soll da noch Zeit für die Messung von Wert, die Entdeckung neuen Werts, Marktanalysen, Stakeholder-Management und das Schärfen der Produktvision bleiben?
All die Dinge, die nötig sind, um Entscheidungen über die Richtung des Produkts zu treffen. Und Verantwortung für die Ergebnisse zu übernehmen.
Und jetzt die unangenehme Wahrheit:
Wer sich als Product-Owner auf das Schreiben von Tickets reduzieren lässt, wird auch so wahrgenommen.
Nicht als Produktverantwortlicher.
Sondern als Backlog-Schreiber.
Fallstrick #2: Das Unternehmen degradiert Product-Owner zu Projektleitern – nur mit neuem Titel
Was ist der Unterschied zwischen einem Projektleiter und einem Product-Owner?
- Ein Projektleiter plant Aufgaben, verteilt Arbeit, kontrolliert den Fortschritt und steuert die Ausführung.
- Ein Product-Owner ergründet Bedarfe, priorisiert Outcomes und trifft Entscheidungen über die Richtung des Produkts.
Kurz gesagt:
- Projektleiter steuern Menschen und Arbeit.
- Product-Owner steuern Wert und Produktentscheidungen.
Beides kann Unternehmen erfolgreich machen.
Aber Scrum wurde nicht erfunden, weil Pläne so gut funktionieren. Scrum wurde erfunden, weil Softwareentwicklung unter Unsicherheit stattfindet.
- Wie gut kennen wir die Probleme, Schmerzen und Frustration unserer Kunden?
- Wie sicher sind wir, dass Kunden dafür bezahlen?
- Wie zuversichtlich sind wir, dass wir das überhaupt liefern können?
Lautet die Antwort auf diese Fragen „na ja ...“?
Dann ist Scrum das bessere Vorgehen. Scrum verschiebt Entscheidungen dorthin, wo die Informationen sind: zum Scrum Team. Und deshalb setzen Scrum Teams auf Selbstmanagement. Nicht auf den einen Experten als Projektleiter. Wenn Unternehmen trotzdem ihren Product-Owner als Projektleiter einsetzen, passiert etwas sehr Vorhersehbares:
Der Product-Owner beginnt Arbeitsschritte zu kontrollieren, Einzelaufgaben zu überwachen und das Team zu steuern.
Das Problem:
Product-Owner verlieren das Vertrauen ihres Teams. Und ohne Vertrauen endet jede Form von Führung. Besonders informelle.
Und das schadet jeder Karriere.
Fallstrick #3: Product-Owner verlieren sich in technischen Details zum „Wie“
Viele Product-Owner besitzen technisches Wissen.
Besonders dann, wenn sie vorher als Entwickler gearbeitet haben oder aus der Entwicklung kommen. Versteh mich jetzt nicht falsch: Technisches Verständnis hilft, die Tragweite von Entscheidungen zu begreifen. Aber technisches Detailwissen ist nicht deine Hauptaufgabe.
Und jetzt kommt der Punkt, an dem sich Product-Owner selbst sabotieren:
Wenn du dich als Product-Owner in Lösungswege verbeißt oder diese sogar vorgibst, degradierst du Entwickler zu reinen Code-Monkeys. Ein Product-Owner sollte sich in die Probleme der Kunden verlieben.
Nicht in die Lösung.
In die Lösung dürfen (und sollen) sich die Entwickler verlieben. Der Scrum Guide beschreibt deren Aufgabe etwas formeller als ich:
„Developer sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Inkrements zu schaffen.“
Die Developer sind Experten für das technische „Wie“. Deine eigentliche Expertise als Product-Owner ist eine andere:
Du bist da, um zu verstehen, was den Kunden den höchstmöglichen Wert bietet.
- Das ist Discovery.
- Das ist Strategie.
- Das ist Priorisierung.
- Das ist Storytelling.
- Das ist Stakeholder-Management.
- Das ist ökonomisches Denken.
Wenn du stattdessen das „Wie“ optimierst, vernachlässigst du zwangsläufig das „Warum“.
Und jetzt die unangenehme Wahrheit:
Du wirst im Unternehmen nicht für die beste Architektur befördert.
Sondern für gute Entscheidungen.
Fallstrick #4: Das Unternehmen macht Product-Owner zu Vermittlern
Was macht einen guten Kellner im Restaurant aus?
- Er nimmt Bestellungen auf.
- Er bringt Getränke und Essen zum Tisch.
- Und er fragt, ob es noch ein Dessert sein darf.
Der Kellner „vermittelt“ zwischen Küche und Gästen.
Und genau so wird Product-Ownership in vielen Unternehmen angewandt:
Product-Owner sammeln Anforderungen ein, schreiben sie um, reichen sie weiter, beantworten Rückfragen, schirmen das Team ab und spielen Übersetzer zwischen Stakeholdern und Entwicklern.
Das klingt nach „wichtiger“ Arbeit.
Ist aber eine Falle.
Denn ein Product-Owner ist nicht die Post zwischen Team und Stakeholdern. Ein Product-Owner bindet Stakeholder ein, um auf Basis ihres Feedbacks Entscheidungen zu treffen. Und jetzt kommt das, was dann immer passiert:
Wenn zu viele Bestellungen eingehen, entsteht ein Engpass.
In der Softwareentwicklung wirst du damit zum Flaschenhals. Und du bekommst die Schuld für Verzögerungen zugewiesen. Dann stellt das Unternehmen weitere „Product-Owner“ ein.
Das klingt erstmal nach Aufstieg.
Ist es aber häufig nicht.
Denn das Unternehmen baut damit nicht Product-Leadership aus. Sondern eine Bestellannahme-Kette:
- Junior-Product-Owner sammeln Anforderungen.
- Senior-Product-Owner koordinieren.
- Und der Abteilungsleiter entscheidet.
Kellner werden daran gemessen, wie schnell sie arbeiten und wie freundlich sie sind.
Product-Owner sollten daran gemessen werden, ob sie Entscheidungen treffen, Prioritäten setzen und Wert maximieren, und nicht daran, wie gut sie Anforderungen einsammeln oder koordinieren können.
Und jetzt die unangenehme Wahrheit:
Wenn du nicht frühzeitig lernst zu delegieren, wirst du nur als Kellner wahrgenommen. Und nicht als das, was du eigentlich sein solltest: jemand, der Entscheidungen trifft, also der Besitzer des Restaurants.
Fallstrick #5: Product-Owner hängen ihre Karriere an Titeln auf, statt an Mandaten
Beim Thema Skalierung werden häufig Teams und Produkte miteinander verwechselt.
Der Scrum Guide schreibt:
„Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie sich Produktziel, Product-Backlog und Product-Owner teilen.“
Also: Mehrere Teams können durchaus an einem Produkt arbeiten.
Was nicht skalieren darf, ist das Entscheidungsmandat. Sonst verwässert die Verantwortung. Und jetzt kommt der Teil, den viele Product-Owner nicht hören wollen:
- Du kannst das im Alltag noch so gut argumentieren.
- Du kannst noch so viele Bücher gelesen haben.
- Du kannst dich noch so sehr auf den Scrum Guide berufen.
Am Ende entscheidet das Organigramm.
Viele Product-Owner machen den Fehler, ihre Karriere an der Frage aufzuhängen, ob sie Product-Owner oder Product-Manager heißen sollten.
Das ist verständlich, aber nicht hilfreich.
- Wenn im Organigramm Product-Manager über dir sind, dann willst du diesen Titel erreichen.
- Wenn es Product-Owner sind, dann willst du das werden.
- Wenn dir das nicht passt, bleibt am Ende nur der Wechsel des Unternehmens.
Bonus-Fallstrick: Das Unternehmen trennt Product-Owner und Product-Manager und schafft ein Verantwortungsvakuum
Auf dem Organigramm sieht es sauber aus:
- Der Product-Manager macht Vision und Roadmap.
- Der Product-Owner kümmert sich um die Umsetzung.
Aber damit wird Product-Ownership zur Verwaltungsrolle degradiert.
Was verwirrt.
Denk an ein Geschäft. Dort gibt es den Besitzer und den Manager. Der Manager verwaltet das Geschäft jeden Tag von 9:00 Uhr bis 18:00 Uhr. Wenn das Geschäft abbrennt: Wer hat den finanziellen Schaden? Der Besitzer. Egal, ob er an diesem Tag anwesend war oder nicht.
Das bedeutet Ownership.
Und die Aufspaltung von Product-Owner und Product-Manager erzeugt ein Verantwortungsvakuum: Viele reden mit.
Aber wer ist wofür verantwortlich?
Dieses Vakuum muss dann mit Abstimmungsmeetings, Rollenbeschreibungen und unterschiedlichen Backlogs gefüllt werden. Das macht es für Stakeholder nicht leichter, zu verstehen, an wen sie sich wenden sollen.
Und die Ironie:
Das wollte Ken Schwaber eigentlich mit der Schaffung der Rolle des Product-Owners in Scrum verhindern.
„Ursprünglich dachte ich, dass die Produktmanager und andere Geschäftskunden, die diese Rolle einnehmen, Scrum lieben würden.“
Product-Ownership ist von Ende zu Ende gedacht.
Von Marktforschung über Strategie und Prioritäten bis zum Release. Und nicht: Roadmap oben und Backlog unten.
Aber jetzt kommt die bittere Wahrheit:
Du machst Karriere durch mehr Mandat, mehr Verantwortung und größeren Entscheidungsspielraum.
Unabhängig vom Titel.
P.S. Suchst du nach Wegen, dich als Product Owner weiterzuentwickeln? Willst du ein Product-Leader werden, der Verantwortung für den unternehmerischen Erfolg des Produkts übernimmt?
Dann wirf einen Blick auf mein „Professional Scrum Product Owner – Advanced“-Training. Dieses Jahr auch online.