Erfahrungsgemäß kann es bei den Aufgaben und Verantwortlichkeiten eines Product Owners im Scrum Kontext zu Dysfunktionen kommen, die die Arbeit eines Teams negativ und sogar kontraproduktiv beeinflussen können.

Die 4 gängigsten Konflikte als Product Owner sind:

1. Der Product Owner hat keinerlei Autorität und ist quasi nur Bote für die Entscheidungen der Geschäftsführung oder anderer HIPPOs. Diese Dysfunktion tritt vor allem zu Beginn einer Transition von einem klassischen Wasserfallmodell hin zu einem agilen Framework auf und steht in krassem Konflikt zu der Definition der Aufgaben und Autorität des Product Owners im Scrum Guide: “For the Product Owner to succeed, the entire organization must respect his or her decisions“. Für ein vitales und erfolgreiches Scrum Framework muss die alleinige Entscheidungshoheit über das „Was getan wird“ bei dem Product Owner als Experte liegen.
2. Der Product Owner versteht sich als Chef des Entwickler-Teams und mischt sich ungefragt in technische Lösungsdiskussionen ein. Der Product Owner ist als Experte zwar durch die Priorisierung der Backlog Items für das „Was getan wird“ verantwortlich, gleichzeitig entscheidet aber vorrangig das Entwickler-Team wie groß der Leistungsumfang eines Sprints ist. Anstatt sich also einen Namen als Hobby-Diktator machen zu wollen, sollte sich ein guter Product Owner auf seine Rolle als fachlicher Vertreter der Stakeholder Interessen besinnen und das Entwickler-Team durch klar formulierte User Storys und ein priorisiertes Backlog unterstützen.
3. Der Product Owner reißt das Daily Scrum Meeting an sich oder nutzt es als Plattform für seine Interessen. Der offizielle Scrum Guide bezeichnet das Daily unzweifelhaft als internes Meeting von dem und für das Entwicklungs-Team. Gäste, und damit auch der Product Owner, können die Gelegenheit nutzen, um sich passiv über die täglichen Entwicklungen zu informieren. Einfluss auf die konkrete Arbeit des Entwickler-Teams nimmt der Product Owner aber durch die Erstellung relevanter Arbeitsaufgaben in Form der Backlog Items und deren Priorisierung.
4. Der Product Owner ist gleichzeitig Mitglied des Entwickler-Teams und wurde, oftmals aus Mangel an Budget und/oder Alternativen, zum Product Owner befördert. Indem eine Person als Product Owner sowohl über das „Was“, als Mitglied des Teams aber auch über das „Wie“ entscheidet, ist ein Interessenskonflikt quasi vorprogrammiert. Der Product Owner ist zwar Experte für sein Produkt, gleichzeitig sollten aber nicht nur die technischen Aspekte, sondern vielmehr der Kundennutzen und -mehrwert im Vordergrund seiner Überlegungen stehen.
   Außerdem wird einem Halbtags-Product Owner die notwendige Zeit fehlen, um seinen beiden Tätigkeiten gewissenhaft nachgehen zu können.

Um möglichen Dysfunktionen schnell entgegenzutreten, ist nicht nur die tägliche Kommunikation mit dem Team enorm wichtig. Es sollten auch regelmäßige Retrospektiven genutzt werden, um auftretende Konflikte gemeinsam mit dem Scrum Master in der Rolle Mediators zu thematisieren und aufzulösen.