Startseite » Product Owner

Product Owner

Voraussichtliche Lesedauer: 11 Minuten

Der Begriff Product Owner beschreibt seine Aufgabe schon sehr schön: ihm „gehört“ das Produkt. Das bedeutet natürlich nicht vollkommende Selbstverwirklichung mit unbegrenztem Budget, sondern verantwortungsvoller Umgang mit den Ressourcen, um den maximalen Wert zu schaffen.

Kernfrage: Was ist das Produkt? Das einmal für alle intern Beteiligten zu klären ist eine hilfreiche Abgrenzung, denn der Product Owner hat erstmal viel auf dem Zettel.

Damit ist der Product Owner weit mehr als der Administrator von Wünschen, die einfach nur zu Umsetzung eingetaktet werden müssen. Er ist das Bindeglied zwischen Stakeholdern und dem umsetzenden Team. Je nach Reife der Organisation sind die Stakeholder mehr oder weniger weit entfernt vom Verständnis, wie Dinge umgesetzt werden. Dadurch variiert auch die Rolle des Product Owners je nach Umfeld.

Das primäre Ziel des Product Owner ist es den maximalen Geschäftswert für ein Budget zu erzeugen. Damit verantwortet er den Outcome für das Budget und hat eine der entscheidenden Rollen in der Produktentwicklung. Er muss also ganz klar mit dem Management an einem Tisch sitzen – im Zweifel entscheidet er über Millionen. Das ist keine Rolle für einen Administrator.

Vision als Aufgabe des Product Owner

In der agilen Welt haben wir keinen Plan von A-Z, weil wir flexibel auf Veränderungen reagieren wollen. Komplexität bestimmt unser Handeln. „Veränderungen“ im komplexen Umfeld sind bereits neue Erkenntnisse über Produkteigenschaften, wenn man die erste Version in der Hand hält. Wir testen jede Iteration und lernen beim Entwickeln.

Bei einer vergleichsweise kleinteiligen Vorgehensweise darf das große Ganze nicht verloren gehen. Genau das sind ja häufig Vorurteile gegenüber agilem Arbeiten. Nebst dem, dass klassische Projekte häufig ihre Ziele verfehlen, dient dazu in der agilen Welt die Vision.

Die Vision ist erstmal ein attraktives Zielbild, ein Leuchtturm im agilen Meer. Er dient bei jedem Schritt der Produktentwicklung der Verortung des neu Geschaffenen. Wie sehr hat es uns der Vision nähergebracht? Wie wollen wir im nächsten Schritt nachsteuern? Der Product Owner ist dabei der Kapitän.

Die Vision wird idealerweise mit vielen betroffenen Parteien entwickelt. Unterschiedliche Sichtweisen reichern den Prozess oft hilfreich an. Bis am Ende ein klares, attraktives Bild entsteht. Ich persönlich, und da scheiden sich die Geister, bevorzuge eine Erweiterung der Vision durch Benennen der Kennzahlen, die die Vision untermauern. Zum Beispiel Zeitersparnis, Umsatzsteigerung, Kundenzufriedenheit, Mitarbeiterwachstum …

Product Owner Pin
Product Owner in alle Richtungen „Eigentümer“

Stakeholder Management

Der Product Owner ist die Anlaufstelle für die Wünsche der Stakeholder. Das sind typischerweise diverse Gruppen – interne, wie externe. Verschiedene Abteilungen, Kunden, Geschäftspartner etc. Manche Gruppen, wie zum Beispiel Kunden kommen nicht von selbst auf den PO zu, sondern müssen proaktiv angesprochen werden. Dennoch sollte alles beim Product Owner zusammenlaufen.

In Zusammenarbeit mit den Stakeholdern gilt es zunächst aus Wünschen die echten Bedürfnisse herauszuarbeiten. Oft kommen schon Lösungsvorschläge. Aber was steckt dahinter? Was wollen wir erreichen? Und schlussendlich, welchen Geschäftswert (Business Value) können wir damit erzielen.

Es liegt auf der Hand, dass Kunden oder Fachabteilungen häufig nicht gewohnt sind in „Erreichen“ zu denken. Dabei ist es hilfreich, wenn der Product Owner methodisch in der Lage ist das gemeinsam auszuarbeiten. Dazu gehört die Abläufe und Prozesse zu verstehen, das was mit dem Produkt am Ende erzeugt werden soll tief zu durchdringen.

Bei Weiterentwicklungen von Produkten ist die Kenntnis des bisherigen die Grundlage, um das Neue damit zu verheiraten. Dem Product Owner gehört eben das Produkt und damit kennt er es auch in- und auswendig. Bestenfalls gibt es auch Analysen, welche Produkteigenschaften die eigentliche Wirkung ausmachen. Ein Beispiel aus der Software-Industrie: als Product Owner sollte ich wissen, welche Features verwendet und welche nicht verwendet werden. Aufräumen, vereinfachen ist auch ein Teil des Jobs. Denn ein zielgerichtetes Produkt hat keinen Schnick Schnack ohne Wert. Es ist simpel und strebt nach Fokus.

Sind die Bedürfnisse der Stakeholder erfasst, können Produktideen entwickelt werden. Der Stakeholder ist aber weiter im Loop. So häufig es geht sollte er mit einbezogen werden. Alles was testbar ist, sollte getestet werden. Dazu helfen MVPs (Minimal Viable Products), Prototypen oder auch direkt Design Thinking Workshops. Frühzeitig zu erkennen, welches der Kern ist, um die Bedürfnisse zu erreichen hilft schlanke, kostengünstige Produkte zu entwickeln. Es geht darum den maximalen Geschäftswert aus dem Budget zu holen.

Der Stakeholder liefert seine Bedürfnisse. Der Product Owner sorgt für eine Befriedigung im Produkt.

Stakeholder sind typischerweise keine Produktdesigner. Natürlich haben wir alle eine subjektive Meinung und wissen wir unsere aktuellen Abläufe sind. Dennoch ist es etwas anderes, ein gutes Produkt zu entwickeln, als einfach „eine neue Spalte“ in eine Tabelle hinzuzufügen.

Wenn uns Steve Jobs 2008 gefragt hätte: „Wollt ihr ein Handy ohne Tasten?“, hätten wir alle „Nein“ geantwortet. Was er gemacht hat ist zu beobachten, wie sich die Nutzung des Handys tatsächlich entwickelt und einige Trends zu antizipieren. Im Folgenden hat er getestet, was das Zeug hält.

Das unterscheidet die Umsetzung von dem, was uns Stakeholder sagen von einem gut entwickelten Produkt.

Umsetzungsplanung und Priorisierung

Mit den entwickelten Produktideen und dem dazugehörigen Business Value kann schon eine gewisse Reihenfolge für die Umsetzung aufgestellt werden. Dabei hilft insbesondere die Produkt Vision, an der gemessen werden kann welche der Produktideen uns dieser wirklich näherbringen. Es kann zum Beispiel sein, dass wir von Kunden einen tollen Wunsch erfahren, ihn auch über Bedürfnisse zu einer genialen Produktidee entwickeln können, das aber gar nicht in die Richtung unserer Vision geht – andere Zielgruppe, gerade nicht Fokus etc.

Bevor aber wirklich klar ist, welche Umsetzungsreihenfolge angestrebt wird, braucht es eine erste Einschätzung des Aufwandes, der Kosten. Hierzu involviert der Product Owner die umsetzenden Kollegen oder Firmen. Es geht nicht um eine detaillierte Planung, sondern um eine grobe Einschätzung. Wir erinnern uns: das endgültige Produkt entsteht durch viele Feedback-Schleifen und entwickelt sich iterativ. Es kann also nicht mit einem exakten Preisschild versehen werden, sondern nur mit einem ungefähren Budget.

Das machen die verschiedenen Methoden unterschiedlich. Manche gehen auf grobe Aufwände. Das hat den Vorteil, dass man sich Tage oder Wochen an Arbeit leichter vorstellen kann und hat den Nachteil, dass dann implizit ein Zeitpunkt der Lieferung im Raum steht. Manche gehen auf T-Shirt Größen (S, M, L, XL), manche auf Storypoints mit Referenzerfahrungen aus der Vergangenheit. Zwei Aspekte dabei finde ich wichtig:

  1. Die verschiedenen Produktideen sollten in Relation zueinander für alle Beteiligten bezogen auf den Aufwand stimmig sein.
  2. Die in der Vergangenheit umgesetzten Produkte helfen als Referenzpunkte für die Einschätzung. Daraus entwickelt sich auch eine immer treffender werdende Schätzung.

Nun hat der Product Owner einen Business Value und einen Aufwand. Und es ist überraschend, wie gut die Schwarmintelligenz bei der Einschätzung hilft.

Der Quotient aus Business Value und Aufwand, gespiegelt an der Vision ergibt dann die Priorisierung quasi automatisch. Natürlich wird noch mit Augenmaß geprüft, ob diese „Roadmap“ sinnvoll erscheint, in die generelle Ressourcen Planung passt oder andere Argumente für eine angepasste Sortierung sprechen.

Die Priorisierung ist damit keine exakte Wissenschaft. Trotzdem kommt man so schneller und effizienter zu einem Ergebnis, um loszulegen. Der Vergleich aus der klassischen Welt wäre ja ein wochenlang erarbeitetes Detailkonzept und eine Aufwandsschätzung – ebenfalls Kosten, die gleich in ein Produkt hätten fließen können. (Nebst dem, dass häufig auch der Business Value eine große Unschärfe hat.)

Product Owner in der Umsetzung

Bei der Umsetzung des Produktes ist der Product Owner Ansprechpartner für umsetzende Teams. Das heisst eine seiner Aufgaben ist es auch das Team mitzunehmen und zu vermitteln, was mit den einzelnen Stories erreicht werden soll. Wir wollen jedes Team-Mitglied in die Lage versetzen in Richtung unseres Outcome mitzudenken und hilfreiche Vorschläge zu machen sowie Entscheidungen zu fällen.

Er kann immer gerne auf die Stakeholder zurückgreifen, für Fragen, Feedback oder Anpassungsvorschläge. Für das Team ist er der Entscheider, weil er selbst entscheiden kann. Er kennt das was wir erreichen wollen, kennt das bisherige Produkt und kann somit (meist sofort) Detailfragen in der Umsetzung klären. Er sieht die Ergebnisse während der Umsetzung mitwachsen und kann sofort Missverständnisse aufklären, es geht ja genau darum keine Papierberge mit Anforderungen zu definieren. Sondern wir wollen das ganze Team auf der Reise mitnehmen, jeder soll verstehen, was wir erreichen wollen und mitdenken können. Dabei wird die Masse an kreativer Lösungskompetenz integriert. Es können alternative Umsetzungswege – besser oder günstiger – aufgezeigt werden. Es geht um den effizientesten Weg zum besten Produkt und nur durch die Zielorientierung des „Erreichens“ von allen ist das möglich.

Product Owner zwischen den Welten

Der Product Ower ist der Oktopus der Produktwelt. Er hat seine Tentakel in alle Richtungen ausgestreckt. Dabei ist es wichtig eine demütige Einstellung bezüglich eigener Ideen zu haben.

Tolle Ideen entwickeln: Ja.

Die eigenen Ideen für die besten zu halten: Nein.

Es geht stets um Aufmerksamkeit, was Stakeholder und Team explizit oder implizit als Input liefern. Das auszubalancieren. Zu Messen. Feedback einzusammeln. Und damit der Kenner beider Seiten zu werden. Wie genau dieser Job als intelligentes Bindeglied aussieht, ist sehr abhängig von der Organisation und dem Produkt. Manchmal ist die Kluft zwischen Fachabteilungen und der Produktentwicklung sehr groß, manchmal ist schon ein tiefes gegenseitiges Verständnis sowie ganzheitliches Denken vorhanden.

Wann duldet eine Organisation einen PO?

Ein Product Owner kann im Sinne des Produkteigentums nur funktionieren, wenn ihm auch die Verantwortung gegeben wird.

Er wird zum zahnlosen Tiger, wenn:

  • Priorisierungen vom Management vorgegeben werden
  • das Produkt schon von der Fachabteilung definiert wird
  • er keine Ressourcen bekommt
  • das umsetzende Team ihm nicht die Möglichkeit gibt an Verschlankungen und Verbesserungen mitzuwirken

Dann wird er zum Administrator und die Entscheidungen rund um das Produkt werden an den schlechtesten Stellen getroffen. Menschen, die keine Produktentwickler sind, entwickeln dann Produkte.

Wie weit kann Product Ownership gedacht werden?

Oft wird ein Product Owner gedanklich in IT Projekte verortet. Das ist verständlich, weil viele Bestrebungen agilen Arbeitens durch die IT initiiert werden. Und es ist auch logisch, weil Softwareprojekte häufig und immer häufiger komplex sind und agile Methoden erfordern.

Es wird dabei der Ursprung viele agiler Methoden in der japanischen Autoindustrie vergessen. Kraftvolle Methoden, wie z.B. Kanban, haben ihre Wurzeln in der Produktion und zielen auch auf die Reduktion von Verschwendung und eine kontinuierlichen Verbesserungsprozess ab. Keine Softwareprojekte.

Mit dieser „Erinnerung“ auf ein Unternehmen geschaut, kann „Produkt“ und „Product Ownership“ und damit agile Fortentwicklung ganzheitlich betrachtet werden:

Was kommt bei Kunden an?

Damit sind Service Prozesse, Vertrieb, Marketing aber auch jegliche Art von internen Abläufen schnell Potenzial für einen Product Owner.

Jedes Team produziert Ergebnisse, weshalb sollen diese Teams nicht von erfolgreichen Methoden und Rollenkonzepten profitieren? Bei der Betrachtung der Einheit „Team“ kann dieser Impuls noch fortgeführt werden. Was und vor allem wie (stetig verbessert) produzieren:

  • Finanzabteilung
  • Geschäftsführung
  • HR
  • ….

Wenn ich das mit Kunden oder in Workshops bespreche, stoße ich oft auf irgendetwas auf dem Spektrum zwischen direkter Neugier bis hin zur Denkblockade. Gleichzeitig gibt es sowohl angewandt Methoden für jeden Bereich – Beyond Budgeting für Finanzen, OKR für Management, agile HR für … na … genau die Personalabteilung.

Nicht in allen Methoden heißt der Mensch, dem „das Produkt“ gehört dann auch noch Product Owner. Das ist auch sekundär. Die oben ausführlich beschriebene Rolle ist vergleichbar bis hin zu identisch.

In diesem Sinne meine Einladung: einfach mal schauen, was in funktionierenden agilen Bereichen attraktiv erscheint und ausprobieren, wie sich das übertragen lässt.

Weiterführende Artikel


Wie hilfreich war dieser Beitrag?

Klicke auf die Sterne um zu bewerten!

Durchschnittliche Bewertung 4.9 / 5. Anzahl Bewertungen: 17

Bisher keine Bewertungen! Sei der Erste, der diesen Beitrag bewertet.

Neues per E-Mail?