Der Product Owner im Spannungsfeld seiner Rolle - von der Vision zum ROI!

Scrum als agiles Projektmanagement-Framework basiert auf einem Metarollenkonzept, wobei als Rollen Product Owner, Scrum Master und das Entwicklungsteam zu Grunde liegen. Eine eindeutige Rollenzuordnung und -kommunikation im Projekt oder der Linientätigkeiten (z.B. bei der Produktentwicklung) erfolgt dabei mit dem Ziel, die Komplexität zu reduzieren, die Kommunikation zu vereinfachen und somit ein fokussiertes Arbeiten im Scrum Team sicherzustellen. Der Product Owner ist dabei nicht nur eine Rolle, sondern möglichst auch genau eine Person. Seine Zuständigkeit ist klar geregelt, per Definition ist der Product Owner für das WAS verantwortlich.

Die Aufgaben des Product Owners

Schauen wir uns zunächst das WAS etwas genauer an. Der Product Owner hat eine Vision des Produkts, die er mit allen im Projekt Beteiligten teilt bzw. an das Team kommuniziert. Dabei „brennt“ er als Visionär, Entdecker oder Forscher für sein Produkt und steckt mit seiner Begeisterung alle anderen an, so dass sie sich einbringen und mitdenken.

Zu seinen konkreten Aufgaben und Tätigkeiten gehören dabei:

• Einbindung der Stakeholder
• Aufstellen und Verfolgen der Business-Ziele (inkl. Messung von Erfolg und Nutzen des Produkts)
• Zuständigkeit für das Backlog-Management (Erstellen und Pflegen)
• Zuständigkeit für Items im Backlog und deren Beschreibung sowie die Sortierung/Ordnung
• Übergeordnete Planungen (Iterationen und Releases vorausplanen)
• Planung und aktive Teilnahme an Sprint Reviews

Auf Basis des Product Backlogs erstellt der Product Owner eine Release-Planung, die über die einzelnen Iterationen (Sprints) hinausgeht und vorhersagt, wie sich ein Produkt über einen Zeitraum von mehreren Monaten bis zu einem Jahr (weiter)entwickeln wird.

Das Bestreben des Product Owners besteht grundsätzlich darin, mit jedem Sprint den Geschäftswert des Produkts zu erhöhen, die für Kunden und Anwender wichtigsten Features zuerst zu implementieren und dabei die Kapazitäten des Entwicklungsteam maximal auszuschöpfen. Er hat demnach die Hauptverantwortung für die Ausbalancierung und Priorisierung der Aspekte Inhalt, Kosten und Zeit.

Der Product Owner gibt vor, an welchen Anforderungen und Aufgaben aus dem Product Backlog in dem jeweiligen Sprint gearbeitet wird. Niemand sonst darf dem Entwicklungsteam Arbeitsanweisungen geben.

Von der Vision zum ROI in der Telekommunikation

Im Rahmen der Product Ownership verfügt der Product Owner zwangsläufig über das Vertrauen des Managements sowie die notwendigen Entscheidungsbefugnisse zum Product Backlog, wo die Produktanforderungen sukzessive gesammelt, bewertet und priorisiert dokumentiert sind. Jeder Produktentwicklung liegt dabei ein Prozess zu Grunde, der nach Scrum in die Zuständigkeit des Product Owners fällt und wie nachfolgend dargestellt beschrieben werden kann:

1. Schritt: Identifizierung der Bedürfnisse der Kunden
2. Schritt: Festlegung der Lösungsprioritäten unter Berücksichtigung der Mehrwertmaximierung
3. Schritt: Entwurf von Lösungen und Entscheidung der Lösungsvariante
4. Schritt: Implementierung der Lösung unter Berücksichtigung der Kosten und time-to-market

Bei der Produktentwicklung in der Telekommunikation, kann man die notwendigen Vorgaben und Entscheidungen durch den Product Owner dabei häufig auf ein Standard Product Setup zurückführen, um ein erfolgreiches Produkt zu entwickeln und im Markt einzuführen. Relevant sind dabei dann:

• Preisfindung
• Businessmodell
• Kundenservice
• Produktmarketing
• Vertrieb

Dabei betreut der Product Owner „sein Produkt“ über den gesamten Produktlebenszyklus von der Idee, über die Neuentwicklung/Implementierung und Weiterentwicklung bis zur Produktablösung. Das Sicherstellen von Nutzen durch die entwickelte Lösung („Benefit Engineering“) fällt dabei explizit in seine Zuständigkeit.

Metriken zur Messung von Produktnutzen

Die spannende Fragestellung ist, wie man den Wert des Produkts messen kann. Ausschließlich anhand der Produktivität des Entwicklungsteams sicher nicht, da diese hoch sein kann, aber wenn die Ergebnisse in die falsche Richtung gehen, kein wirklicher Nutzen entsteht. Dazu gibt das „Evidence-based Management“ einige Metriken vor, die in der Telekommunikation häufig genutzt werden. Für Product Owner können sie sehr hilfreich sein, zumal wenn diese über längere Zeit hinweg erfasst werden, um dann Entwicklungen und Trends erkennen zu können.

• Current Value
  Er misst, wie das Produkt am Markt angenommen und genutzt wird. Beispielmetriken für diese Kategorie: Kundenzufriedenheitsindizes (bspw. aus Produktfeedback generiert), Messungen der Nutzung einzelner Funktionen im Vergleich zur Kundenzufriedenheit mit diesen.
• Time-to-Market
  Er misst, wie lange es dauert vom Zeitpunkt, wenn eine neue Anforderung zum ersten Mal formuliert wird, bis sie vermarktungsreif verfügbar ist. Beispielmetriken für diese Kategorie: Release-Häufigkeit, Integrationshäufigkeit, Durchlaufzeit von Backlog-Einträgen, Vorlaufzeit.
• Ability to Innovate
  Dies ermittelt, wie innovativ (neuartig) die Lösungsfindung ist. Beispielmetriken für diese Kategorie: Nutzung einzelner Funktionen im Vergleich zu anderen, Aufwand oder Kosten für Neuentwicklung (in Prozent) gegenüber reaktiven Tätigkeiten wie Wartung, Messung der Zeit, die das Team tatsächlich am Produkt beschäftigt ist (im Vergleich zu anderen Aufgaben).
• Unrealized Value
  Hier geht es darum, welches Potential momentan noch nicht ausgeschöpft ist. Beispielmetriken für diese Kategorie: Marktanteil, Erwartungen der Anwender im Vergleich zu dem, was sie bekommen.

Erfolgsfaktoren für den Product Owner

Ein guter Product Owner soll die Stakeholder und das Team mit seiner Produktvision vereinen und inspirieren. Er ist dabei für das Team und den Kunden der einzige und zentrale Ansprechpartner, wenn es um fachliche Entscheidungen zum Produkt oder zum Product Backlog geht. Dabei sind jedoch zwei unterschiedliche Aspekte zu unterscheiden:

1. Organisationsorientiert: Kunden- und Stakeholder-Orientierung, z.B. zur Anforderungsaufnahme und -bewertung anhand der Produktvision.
2. Teamorientiert: Diskussion und Bewertung der Anforderungen mit den technischen Experten aus dem Entwicklungsteam bezüglich der Umsetzbarkeit sowie fachliche Entscheidungen in der Umsetzungsphase.

Dabei darf keiner der beiden Aspekte vernachlässigt werden, d.h. eine Fokussierung auf einen Aspekt und weniger Aufmerksamkeit auf den anderen ist nicht zielführend oder zulässig. Soweit der Anspruch, aber wie kann er das in der Praxis erreichen?

Erfolgreiche Product Owner berichten dabei über ihr persönliches Erfolgsrezept:

• Antrieb und Begeisterung für das Produkt „vorleben“
• Immer neugierig bleiben
• Mutig und voller Vertrauen fachliche Entscheidungen treffen („Es gibt keine richtigen oder falsche Entscheidungen“)
• Fragen zum Produkt jederzeit beantworten (man muss aber nicht alles wissen)
• Das Team als gleichwertigen Partner begreifen, d.h. Product Owner und Entwicklungsteam arbeiten auf Augenhöhe eng zusammen
• Permanente Kommunikation mit allen Stakeholdern (Team und Kunden)

Fazit:

Der Product Owner hat als Person Kenntnisse und Fähigkeiten erlangt, die ihn besonders für diese Rolle befähigen. Sie ähneln stark denen, die auch für Projektmanager wichtig sind. Er muss ein Teamplayer innerhalb des Scrum Teams sein. Wenn er nur seine Ideen durchsetzen möchte, das Entwicklungsteam diese aber ablehnt, können keine brauchbaren Ergebnisse in den Sprints erzielt werden. Er muss sich auf die Wünsche, Arbeitsweise und Fähigkeiten des Entwicklungsteams einstellen, denn ohne das Team wird er nicht das bekommen, was „sein“ Produkt braucht, um am Markt erfolgreich zu sein. Das gilt in ähnlicher Form auch für die Zusammenarbeit mit den Stakeholdern. Es liegt dabei in seiner Verantwortung, verschiedene Aspekte permanent gegeneinander abzuwägen und auszubalancieren:

• Kosten, Profitabilität und Rentabilität der Produktentwicklung (ROI) gegen Kundenzufriedenheit und Marktfähigkeit
• Erwartungen und Anforderungen der Stakeholder gegen die Kapazität (und Fähigkeiten) des Entwicklerteam
• Produktivität des Teams (Output) gegen Ergebnisqualität und Nutzen/Wert (Outcome)
• Proaktive Maßnahmen (Risikoerforschung, Entwicklung neuer Funktionen) gegen reaktive Maßnahmen (Tests, Fehlerbehebung, Qualitätssicherung, Wartung)

Idealerweise können die Product Owner diese oftmals konträren Aspekte gut handeln, was keine leichte Aufgabe ist, aber zum Spannungsfeld der Rolle gehört. Product Owner müssen also in der Praxis deutlich mehr können, als der Scrum Guide zu ihrer Rolle ausführt.