Startseite » Product Owner

Product Owner

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 OwnerPin
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


Schreibe einen Kommentar

Neues per E-Mail?