Skip to main content

Was sind die größten Fehler, die eine Product Owner:in machen kann? 🇩🇪

February 3, 2022

Diese Frage habe ich neulich in einem meiner 

Professional Scrum Product Owner 

Trainings bekommen.
Wo soll ich anfangen? Man kann vieles falsch machen, und vieles hängt vom Kontext ab! Aber dann dachte ich, es gibt schon einige kapitale Fehler, die ich in verschiedenen Kontexten immer wieder gesehen habe. Also hier kommt meine Top 5 Liste: Empiricism and Self-Managing

  1. Mechanischer Scrum 
    Im Blindflug Scrum mechanisch nutzen unter Verletzung der unterliegenden Prinzipien der Empirie und Selbst-Management des Scrum Teams. Wie man es richtig macht, habe ich in diesem Blog beschrieben. Das ist die „größte Scrum Sünde“, weil man die eigentliche Power von Scrum nicht nutzt und Risiken nicht wirklich managt. Leider ist es sehr leicht in dieses „agile Theater“ zu verfallen ohne es zu merken.


    Crystal ball
  2. Inside-out Glaskugel lesen 
    Die Product Owner:in arbeitet nur auf der taktischen Ebene reaktiv auf Zuruf der lautesten Stakeholder:innen. Dies sehen wir oft, wenn die Product Owner:in selber kaum oder keinen direkten Kundenkontakt oder Nutzerkontakt hat. Kontakt über Sales Kolleg:innen oder Marketing Kolleg:innen reichen nicht aus, weil diese bewusst und zu Recht ganz andere Perspektiven einnehmen. Meistens weiß die Product Owner:in gar nicht im Detail wie und warum potentielle Kund:innen eine Lösung aktuell nutzen, d.h. die Product Owner:in hat weder Kund:innen interviewt noch sie beim Einsatz einer Lösung beobachtet. Die Product Owner:in ist in ihrer Bubble und überlegt sich was ihr selber oder den Stakeholder:innen wohl am besten gefallen würde. Hier werden viele Annahmen getroffen ohne sich dessen bewusst zu sein. Auch das würde ich Blindflug nennen. Hier und da gibt es vielleicht Indikatoren, aber eine Product Owner:in die nicht ständig mit mindestens 15-20 Kund:innen oder Nutzer:innen im Kontakt ist, läuft schnell in diese Falle. 
     
  3. Zu enger Fokus im Product BacklogNarrow Focus
    Der Product Backlog hat nur Einträge um das Produkt zu „bauen”. Es fehlen Product Backlog Items (PBIs) um zeitgleich zum Release potentielle Interessent:innen anzulocken, was man für Customer Relationship Management machen könnte oder über welche ”Channels“ potentielle Kund:innen/Nutzer:innen das Produkt erhalten oder konsumieren möchten. Wir sind im 21. Jahrhundert in dem man über geeignete Partnerschaften schneller gemeinsam zum Ziel kommt, was einen Product Backlog erheblich beeinflussen kann. 

    Overloaded
  4. Produkt wird unnötig aufgebläht 
    Es herrscht immer noch vielerorts der Irrglaube, dass mehr Funktionen gleichbedeutend mit mehr Wertschöpfung ist. Wirklich? Schon seit Jahren liebe ich es auf meinem Smart Phone Termine zu koordinieren, weil es so einfach ist. Auf dem Desktop habe ich viel mehr Funktionen um Termine zu bearbeiten, die ich aber nur selten und gar nicht nutze. Ich behaupte, dass immer noch im Schnitt 50% aller Funktionen bei den meisten Produkten gar nicht benutzt werden. Ja die letzte Studie der Standish Group war 2014, aber ich glaube wir sind nicht viel besser geworden. Und die Kund:innen ärgern sich dann, dass sie für so viele Funktionen bezahlt haben, die sie gar nicht brauchen und die ihr Leben im Zweifelsfall schwerer machen. Und die Product Owner:in muss ein Teil ihres Budgets für die Wartung der nicht genutzten Funktionen aufbringen.

     
  5. Product Backlog wird nicht aufgeräumtClean up
    Dann sehen wir total aufgeblähte Product Backlogs, weil alle PBIs gehütet werden wie der Heilige Gral. Wenn ein PBI über Monate oder sogar Jahre im Product Backlog verstaubt, dann ist das WASTE um in der Lean Sprache zu reden. Das erzeugt Mehraufwand, der unnötig ist. Da braucht es Mut von der Product Owner:in diese Einträge rauszuwerfen. Wenn es wirklich wichtig ist, dann kommt es wieder hoch. 

Wie schon oben gesagt, diese Liste ist nicht erschöpfend. Welche Erfahrungen habt Ihr gemacht? Schreibt es gerne in die Kommentare. 


What did you think about this post?