Was muss ein Product Owner können?

Ein neuer Product Owner wird gesucht. Wie sieht die Stellenausschreibung aus? Beim Lesen von Artikeln über modernes Produktmanagement merken wir, dass unser Produktmanagement hoffnungslos veraltet ist. Wir praktizieren kein Design Thinking, betreiben keine Innovation und der MVP ist schon wieder tot bevor wir ihn verstanden haben. Eigentlich dürfte es uns gar nicht mehr geben, so altbacken sind wir.” Kommt das irgendwie bekannt vor?

Product Owner = Superman?

Das Lesen von Artikeln auf medium und die Teilnahme an Konferenzen wie MTP formen das Bild des Product Owners des allwissenden Supermans. Er muss einen riesigen Wissensschatz mitbringen, um das Wunderwerk zu vollbringen:

  • Stories schreiben
  • Backlog priorisieren
  • Visionen erschaffen
  • Roadmaps bauen
  • Marktforschung betreiben
  • Stakeholder verstehen und organisieren
  • Kreativ-Workshops durchführen
  • Innovation vorantreiben
  • Produkte vertreiben
  • User Experience ermöglichen
  • Business Modelle ausdenken
  • Finanzvorhersagen treffen

Dass dies relevante Aufgaben eines POs sind, ist richtig. Dass ein PO sich aber perfekt (inkl. vieler Methoden und Tools) und aus dem Stand mit allem auskennen muss, nicht. Ich will mich nun einmal auf die Kernfähigkeiten eines POs zurückbesinnen.

Was sind die Kernfähigkeiten des Product Owners?

Trennen wir uns mal von jeglicher Methodik, Vorgehensweise und von Tools. Was bleibt dann eigentlich noch übrig, mit dem sich ein PO richtig gut auskennen muss?

  • Das Wichtige vom Unwichtigen unterscheiden
  • Die wirklichen Probleme und Bedürfnisse von Kunden erkennen und adressieren
  • Komplexitäten durchdringen
  • Empathisch gegenüber Team und Stakeholdern agieren
  • Von einer klaren Linie überzeugt sein, Nein sagen können

Diese Fähigkeiten (die erlernbar sind) sind das Fundament eines jeden Product Owners. Er läuft sonst Gefahr, sich immer mehr und mehr zu verlaufen, bevor sein Fundament steht. Überspitzt dargestellt: Design-Thinking, MVP, OKR und Lean Startup helfen auf der einen Seite nicht, wenn sich der PO mit unwichtigen Features beschäftigt, am Kunden vorbei plant, das Produkt nicht versteht, sich von Team bzw. Stakeholdern gelöst hat und nur situativ reagiert. Die genannten Methoden erfordern aus meiner Sicht erst das genannte Fundament. Hier ist der PO kein besserer PO, wenn er besonders viel davon kennt, sondern wenn er verstanden hat, wofür er sie einsetzt, und wie sie ihn schneller und besser machen.

Muss ein Product Owner technische Kenntnisse haben?

Nein, aber sie helfen eigentlich immer! Treffen sich Team und PO auf der Architektur-Ebene, finden beide Seiten einen einfacheren Zugang zueinander. War der PO früher selber Entwickler, versteht er es, dass die Lösung zunächst einfacher Probleme mehrere Tage dauern können. Es fällt beiden Seiten leichter, über technische Schuld, Refactoring und Tech-Stories zu sprechen.

Kennt oder beschäftigt sich der PO nur mit der fachlichen Seite, sehe ich ein Risiko: Die Isolation vom Team / der Elfenbeinturm (ein übliches PO-Antipattern). Das muss nicht passieren, wenn beide Seiten über Empathie verfügen und die jeweils andere Seite respektieren. Doch ein isolierter PO kann in Discoveries, unzähligen Canvasses usw. abdriften. Er verliert dann immer die Bindung ans Team, weil ihn kaum noch jemand versteht. Einen schönen Artikel dazu gibt es hier.

Wieder auf den Boden der Tatsachen zurückfinden

Die Suche nach dem PO-Superman ist nicht sinnvoll. Man wird ihn nur schwer finden. Diese Notwendigkeit ist stark aus dem Rockstar-Image des Product Owners geboren. Methoden und Werkzeuge sind nur Mittel zum Zweck. Sie einzusetzen, um gefühlt dran zu bleiben, hilft nicht. Wenn man aber das konkrete Problem/die Komplexität verstanden hat und sie versucht zu durchdringen, ist es richtig, die passende Methode zur Lösung zu suchen.

Dann teilen wir die Rolle einfach?

Aber ich möchte wieder zur langen Liste von Aufgaben zurückkehren. Das breite Spektrum lässt sich mit den genannten Kernfähigkeiten inhaltlich gut adressieren, es bleibt aber viel Arbeit. Ist das Produktteam groß, die Stakeholder-Landschaft komplex oder die Anzahl der Produkte groß, so muss sich der PO mit der Skalierung seiner eigenen Rolle beschäftigen. Dazu hat Roman Pichler drei sinnvolle Optionen beschrieben. Kurz gesagt managed der PO ein PO-Team (z.B. mit einem Business Analysten und einem UX-Experten) oder das Produkt wird zerteilt. Meiner Meinung nach sind das die richtigen Optionen. Beim PO-Team ist liegt die Verantwortung immer noch beim PO und nicht verteilt. Die Zerteilung von Produkten ist nicht einfach, schafft aber auch klare Strukturen. Ein sehr ungünstiges Modell ist die Zerteilung der PO-Rolle in ein Zwei- (“PO-Technisch” und “PO-Fachlich”), Drei- (“PO-Technisch”, “PO-Fachlich”, “PO-Management”) oder gar Viergestirn (“PO-Technisch”, “PO-Fachlich”, “PO-Organisatorisch”, “PO-Feelgood-Management”). Zum Einen entsteht diese Zerteilung meist am Reißbrett und hat ihren Ursprung in alten Abteilungsstrukturen (Produktmanagement, Software-Development, Projektleitung). Zum Anderen fördert eine solche Konstellation komplexe und unklare Wege in Kommunikation, Entscheidung und Verantwortung.

Teile deine Gedanken