Wenn dein Team dir als Product Owner nicht folgt

Tim & Oliver im Gespräch Worum es geht Backlog priorisiert, im Refinement erklärt, warum was wichtig ist – und trotzdem diskutiert das Team jede Entscheidung, oder einzelne Teammitglieder machen am Ende etwas ganz anderes als vereinbart. Egal ob mit Scrum, Kanban oder einer anderen Arbeitsweise: Dieses Gefühl kennen viele Product Owner. Tim und Oliver gehen der Frage nach, was in solchen Situationen wirklich passiert. Was "Folgen" als Product Owner eigentlich bedeutet Bevor es um Ursachen und Lösungen geht, steht eine grundsätzlichere Frage im Raum: Müssen Teammitglieder einem Product Owner überhaupt "folgen" – und was heißt das eigentlich? Ansagen machen, echte Zustimmung bekommen oder Entscheidungen verstehen und mittragen, auch ohne ihnen zuzustimmen, sind drei völlig unterschiedliche Dinge. Product Owner sind Führungskräfte, aber keine Vorgesetzten. Wer vorher Team- oder Projektleiter war und in die Product-Owner-Rolle gewechselt ist, fällt leicht in ein klassisches Ansage-Verständnis von Führung zurück. Echte Zustimmung und Mittragen lassen sich damit aber nicht erzeugen – die müssen sich Product Owner durch Vertrauen, Kompetenz und Empathie erst verdienen. Mögliche Ursachen, wenn das Team nicht folgt Tim und Oliver sammeln mehrere Gründe, warum ein Team einem Product Owner inhaltlich nicht folgt: Fehlendes Vertrauen auf der Beziehungsebene zwischen Product Owner und Team. Fehlendes Verständnis: Das Warum hinter einer Entscheidung wurde nicht ausreichend vermittelt – fehlende "Problemempathie" für das Nutzerproblem, das gelöst werden soll. Scheinbeteiligung: Feedback wird zwar eingeholt, hat aber erkennbar keinen Einfluss auf die Entscheidung, weil der Product Owner ohnehin allein entscheidet. Geschwindigkeits-Mismatch: Der Product Owner ist im eigenen Denken und in der Transformation schon weiter als das Team und überfordert es dadurch. Fehlendes gemeinsames Ziel: Ohne eine nachvollziehbare Kette von Vision über Strategie und Roadmap bis zum Sprint Goal (Decision Stack) wirkt die Priorisierung willkürlich. Zwischenmenschliche oder politische Konflikte: Manchmal steckt hinter dem Nicht-Folgen auch offene Verweigerung – etwa, wenn jemand die eigene frühere Entscheidungsmacht verloren hat oder agile Arbeitsweisen grundsätzlich ablehnt. Wichtig ist dabei die Unterscheidung: Folgt das gesamte Team nicht, liegt die Ursache eher beim Product Owner selbst. Verweigern sich einzelne Personen, kann das auch an ihnen liegen. Typische, aber wenig hilfreiche Reflexe Als Reaktion beobachten Tim und Oliver häufig: mehr Kontrolle, ein Rückfall in Command-and-Control-Muster, Resignation, das Abschieben von Verantwortung an andere, immer detailliertere Tickets oder zusätzliche Meetings. Ohne die eigentliche Ursache zu klären, ändern diese Reflexe am Grundproblem meist nichts. Was stattdessen hilft Stattdessen empfehlen Tim und Oliver: Gemeinsame Klarheit über das Warum herstellen – wer ist die Zielgruppe, welches Problem wird gelöst, woran erkennt man Erfolg. Mehr visualisieren statt nur Tickets schreiben – mit dem Stift denken macht Missverständnisse sichtbarer. Situativ führen und Entscheidungsstile bewusst an die jeweilige Situation anpassen, statt immer gleich zu entscheiden oder zu delegieren. Bei sich selbst anfangen: die eigene Kommunikation und ihre Wirkung reflektieren, statt Feedback vorschnell als persönlichen Angriff oder reines Teamversagen abzutun. Sich Hilfe holen – durch einen Scrum Master oder Agile Coach, einen Sparringspartner im Team oder einen anderen Product Owner. Aus Sicht von Tim und Oliver in Organisationen werden Entwickler:innen viel zu selten in agilen Arbeitsweisen und modernem Produktmanagement geschult, dabei trägt im Idealfall das ganze Team Produktverantwortung. Fazit Wenn ein Team dem Product Owner nicht folgt, lohnt sich zuerst der Blick auf die eigene Kommunikation und das gemeinsame Zielverständnis, bevor mit mehr Kontrolle reagiert wird. Bei einzelnen, dauerhaft verweigernden Teammitgliedern kann aber auch das offen angesprochen werden – bis hin zu klaren Konsequenzen. Folgende Episoden könnten dich auch interessieren [Folge mit Arne Kittler zu Klarheit und Rollenklarheit]](https://produktwerker.de/klarheit-fuer-produktmenschen/)) [Folge mit Bernd Joussen zu Konflikten zwischen Product Ownern und Developern]](https://produktwerker.de/welchen-einfluss-auf-die-retrospektive-hat-ein-product-owner/)) [Folge mit Sohrab Salimi: "Product Owner als Agile Leader"]](https://produktwerker.de/product-owner-als-agile-leader/)) [Folge "Product Owner ohne Scrum Master"]](https://produktwerker.de/product-owner-ohne-scrum-master/)) [Folge mit Frank Wolfes zu Decision Poker]](https://produktwerker.de/entscheidungen-treffen-decision-poker/))