Wenn dein Team dir als Product Owner nicht folgt

Tim und Oliver sprechen in dieser Folge über ein von vielen Product Owner kommuniziertes Gefühl: Das Product Backlog ist priorisiert, im letzten Refinement wurde vermeintlich alles geklärt. Trotzdem diskutiert das Team jede Entscheidung neu oder macht am Ende etwas komplett anderes als vereinbart. In einer solchen Situation kommt häufig die Frage auf, warum dir dein Team als Product Owner nicht folgt.

Tim und Oliver beiden stellen dieser Frage einen anderen Gedanken entgegen: Muss ein Team einem Product Owner überhaupt folgen? Und was bedeutet „Folgen“ in diesem Kontext wirklich?

Oliver unterscheidet drei Ebenen von Folgen. Die erste sind klare Ansagen, denen ein Team einfach gehorcht. Die zweite ist echte Zustimmung, die sich ein Product Owner erst erarbeiten muss. Die dritte ist ein geteiltes Verständnis, das Menschen mittragen lässt, selbst wenn sie anderer Meinung sind. Viele Product Owner waren früher in der Teamleitung oder Projektleitung und aus dieser Zeit erwarten sie oft automatisch, dass Ansagen befolgt werden. Genau dieses Selbstverständnis hält Tim für einen Denkfehler. Product Owner führen zwar, sind aber keine disziplinarischen Vorgesetzten. Wer trotzdem so auftritt, verwechselt seine Rollenbezeichnung mit Vertrauen. Denn Vertrauen muss sich ein Product Owner erst verdienen, durch Kompetenz, Empathie und Verlässlichkeit.

Ein zweiter Grund für fehlendes Folgen kann in der eigenen Kommunikation liegen. Versteht ein Team nicht, welches Problem gelöst werden soll, bleibt jede Priorisierung angreifbar. Außerdem bitten manche Product Owner zwar um Meinungen und Feedback, entscheiden am Ende aber ohnehin allein. Dadurch wirkt die Beteiligung im Team nur wie ein Ritual. Andere Product Owner überfordern ihr Team mit Tempo. Sie selbst stecken schon tief in agilen Arbeitsweisen, während einzelne Teammitglieder diese Geschwindigkeit noch nicht mitgehen können.

Typische Reflexe tauchen auf, wenn ein Product Owner sich nicht gehört fühlt. Dazu zählen mehr Kontrolle, detailliertere Tickets und zusätzliche Meetings. Tim beschreibt das als Rückfall in ein klassisches Auftraggeber und Auftragnehmer Muster. Am Ende wird wieder alles bis ins Detail vorgegeben. Aber ein solches Vorgehen hilft selten. Das eigentliche Symptom bleibt bestehen und die Distanz zwischen Product Owner und Team wächst wieder. Oliver und Tim empfehlen stattdessen, gemeinsam an Ziel und Kundennutzen zu arbeiten. Diese Orientierung hilft mehr, als einzelne Tickets immer wieder neu zu erklären.

Werkzeuge wie der Decision Stack oder Impact Mapping können dabei unterstützen. Sie machen eine nachvollziehbare Linie von der Produktvision bis zum Sprintziel sichtbar. So versteht ein Team die Zusammenhängen und wofür es arbeitet. Product Owner sollten zuerst bei sich selbst ansetzen. Sie sollten die eigene Kommunikation hinterfragen, bevor sie das Verhalten des Teams zum Problem erklären. Oliver nennt das eine Form von Selbstreflexion. Das bedeutet nicht, sich automatisch die Schuld zu geben. Es bedeutet, ehrlich zu prüfen, welchen Anteil die eigene Kommunikation an der Situation hat.

Solltest du dich in einer vergleichbaren Situation befinden, kann es eine gute Idee sein, sich Hilfe zu holen. Ein Scrum Master, ein Teamcoach oder eine kollegiale Fallberatung mit anderen Product Ownern kann unterstützen. Denn Selbstreflexion mit sich alleine fällt oft schwer. Wichtig ist eine Unterscheidung: Folgt das ganze Team nicht, liegt die Ursache häufiger beim Product Owner selbst. Folgen nur einzelne Personen nicht, kann das viele verschiedene Gründe haben.

Folgen hat im Produktkontext wenig mit Hierarchie zu tun und viel mit einem gemeinsamen Ziel. Ein Team folgt eher der Idee, ein Problem für Kundinnen und Kunden zu lösen. Es folgt seltener der Person, die zufällig den Titel Product Owner trägt. Wer dieses Ziel greifbar macht, Verantwortung im ganzen Team verankert und offen mit Rückmeldungen umgeht, muss sich um das Thema Folgen deutlich weniger Sorgen machen.