Die Aufgaben und Herausforderungen des Product Owners

Für mich haben sich diese drei Grundregeln als Product Owner bewährt:

1. Zerlege den Elefanten.
   Jede Aufgabe, jedes Problem, jede Herausforderung lässt sich in kleinere Teile zerlegen. 

2. Löse eine Herausforderung nach der anderen und nicht alle gleichzeitig.
   Nimm dir eine der identifizierten Herausforderungen, fokussiere dich, löse sie und widme dich dann erst der nächsten.

3. Nimm dich, wann immer möglich, zurück, reflektiere dich und deine Arbeit und erweitere deinen Planungshorizont.
   So verlierst du nicht den Überblick und lernst stetig.

Neben der Beachtung dieser Grundregeln habe ich mir als Product Owner immer die folgenden drei übergeordneten Ziele gesetzt:

1. Habe immer eine klare Vision und vermittle sie jedem.

2. Sei dir bewusst, wie du mit deiner Arbeit zum Unternehmenserfolg beiträgst.

3. Strahle Begeisterung aus für das, was du als Product Owner mit deinem Team entwickelst.

Zu Beginn eines Projektes geht es meistens nur darum, möglichst ohne grössere Probleme und zügig mit der Entwicklung des Minimum Viable Product (MVP)  zu starten. Auf dieses Anliegen sollte sich demnach zunächst die gesamte Arbeit des Product Owners ausrichten. Aus meiner Sicht lassen sich die dafür nötigen Schritte in die persönliche und die projektbezogene Vorbereitung gliedern.

Die persönliche Vorbereitung umfasst vor allem das Beschäftigen mit der eigenen, neuen Rolle als  Product Owner. Dem gegenüber steht die notwendige Vorbereitung des Projektes bzw. Produktes, um in die Entwicklung einsteigen zu können.

Grundregel eins besagt, dass man das grosse Ganze in kleinere Teile zerlegen sollte, um dann Regel zwei anzuwenden und die Herausforderung zu lösen.
Die Suche nach dem ersten Problem gestaltet sich aus meiner Sicht dabei recht einfach. In den häufigsten Fällen ist man selbst das Problem. Ein Sprichwort sagt: „Was man oft macht, das kann man gut.“ Ist man jedoch neu in der Rolle des Product Owners, hat man wahrscheinlich nicht die nötige Erfahrung und Praxis.

Die erste Aufgabe im Rahmen der persönlichen Vorbereitung ist demnach das Auseinandersetzen mit den Aufgaben und Verantwortlichkeiten der Rolle des Product Owners. Unabhängig von der Methode der späteren Implementierung (Scrum, Kanban, XP etc.) ist es wichtig zu verstehen, wie professionelle, agile Produktentwicklung funktioniert.

Beginnen sollte man stets mit den Grundpfeilern: Was sind Agilität und Empirismus? Ausserdem ist ein gutes Verständnis der Lean-Prinzipien und des „Manifests für agile Softwareentwicklung” ein guter Start. Darauf aufbauend, kann ich das Einlesen in Bücher wie „INSPIRED: How to Create Tech Products Customers Love” von Marty Cagan oder „The Lean Startup” von Eric Ries sehr empfehlen. Natürlich ist googlen auch ein absolut passabler Weg, sich langsam voran zu tasten. Wichtig ist, dass man versucht, ein Gefühl dafür zu entwickeln, was das Team später von einem selbst erwartet.

Neben diesem Selbststudium empfehle ich, sich zusätzlich nach professioneller Unterstützung umzusehen. Gerade für das Erlernen erster Methoden für die tägliche Arbeit können zum Beispiel Trainings, Coachings oder Meetups besucht oder bezogen werden. Grosse Unternehmen bieten mittlerweile eine Reihe von internen Formaten an, auf die Projektteams zurückgreifen können. Sollte es diese Möglichkeit nicht geben, empfiehlt es sich erfahrene Dienstleister wie Merkle mit ins Boot zu holen und deren Angebote, z.B. für Schulungen, zu nutzen.

Nachdem man theoretisch verstanden hat, was die Rolle des Product Owners grob an fachlichen Voraussetzungen, Befugnissen und Aufgaben beinhaltet, ist es ratsam einen Vergleich mit der zukünftigen Rolle im Projekt anzustellen. Hier steht die Frage im Mittelpunkt, ob die Rahmenbedingungen eine professionelle Ausübung der Rolle zulassen.

Nachfolgend habe ich eine kleine Liste erster Fragen zusammengestellt, um die Rolle des Product Owners im Projekt zu überprüfen:

• Habe ich die Befugnis, allein operative und taktische Entscheidungen im Rahmen der Entwicklung zu treffen?

• Habe ich das Budget, um mein Vorhaben zu realisieren und kann ich eigenverantwortlich darüber entscheiden?

• Habe ich die notwendige Rückendeckung von Management-Positionen?

• Steht mir ausreichend Zeit für meine Rolle als Product Owner  zur Verfügung?

• Kann ich ohne Hürden andere Abteilungen bzw. Stakeholder kontaktieren?

• Bin ich in der Lage, täglich mit dem Entwicklungsteam zusammen zu arbeiten?

• Kann ich in der Domäne des zukünftigen Produkts fachlich sicher argumentieren?

• Verstehe ich grob die technischen Rahmenbedingungen?

• Ist eine persönliche, örtliche Zusammenarbeit mit dem Umsetzungsteam möglich?

Diese Fragen müssen nicht zwangsläufig alle mit einem klaren „Ja” beantwortet werden, um einen guten Job als Product Owner zu machen. Doch gerade bei einer positiven Beantwortung der ersten Punkte in der Liste steigen die Erfolgschancen des Vorhabens erheblich.

Neben diesen nach aussen gerichteten Fragen, sollte sich ein angehender Product Owner  auch die Frage stellen, wie er sich und sein Team für die anstehenden Herausforderungen begeistern kann. Ein guter Product Owner lässt sein Feuer auf das Team überspringen und bietet das „Warum”, um das sich das Team formieren kann. Nur wenn der Product Owner  selbst eine klare Vision hat und den unternehmerischen Mehrwert vertritt, wird seine Begeisterung auch andere anstecken.

Ein guter Start für die Entwicklung einer Idee ist zum Beispiel ein ausgefülltes Business Model Canvas. Besonders die Value Proposition sollte klar aufzeigen, für welche Zielgruppe, man wie und auf Basis welcher konkreten Pains und Gains man sein Produkt inhaltlich ausprägen möchte. Die restlichen Felder dienen vor allem dem Bewusstwerden des wirtschaftlichen Kontextes, in dem man sich während und nach der Entwicklung bewegt. Natürlich unterstützt ein gutes Business Model auch bei der internen Argumentation oder Rechtfertigung für Investitionsentscheidungen und kann für Produktmarketingzwecke herangezogen werden.

Im Anschluss empfiehlt es sich die Value Proposition in eine Vision zu überführen. Hierbei können Vorlagen, wie Roman Pichlers „Product Vision Board” oder einfache Methoden wie das Elevator Pitch Template und die Vision Box genutzt werden.

Die Vision dient vor allem als Leitbild für die Produktentwicklung. Im Verlauf der Entwicklung ist es die Aufgabe des Product Owners  zu entscheiden, in welcher Tiefe und Breite er sein Produkt ausprägen möchte und in welche Bereiche Geld investiert werden soll. Um bei dieser Aufgabe nicht den Überblick zu verlieren, kann ich als Product Owner meine Entscheidungen anhand der Vision auf ihren Business Value hin überprüfen und ausrichten.

Zusammenfassend ist die persönliche Vorbereitung vor allem dazu gedacht, sattelfest in der fachlichen Domäne, Produkt-Vision und der eigenen Rolle zu werden.

Als Ergänzung zur persönlichen Vorbereitung muss für einen langfristigen Erfolg auch die Entwicklung auf eine solide Basis gestellt werden. Hierbei würde ich diesen Bereich in drei Handlungsfelder gliedern:

1. Zusammenstellung eines Teams

2. Hypothesen und Anforderungen

3. Steuermechanismen und Prozesse

Betrachten wir zunächst das Handlungsfeld „Team”. Hierbei sollte der Product Owner, je nach Framework, den Schulterschluss mit anderen Rollen suchen. In Scrum z. B. sollte der Scrum Master eng eingebunden werden, um gemeinsam das Entwicklungsteam zu befähigen ihr Bestmögliches zu leisten.

Zunächst ist es wichtig zu verstehen, dass sich die Produktentwicklung im Bereich der Wissensarbeit bewegt. Folgt man dem Systemtheoretiker Helmut Willke (Organisierte Wissensarbeit, 1998, S. 161), geht damit die Herausforderung einher, dass Wissen veralten kann und stetig erneuert werden muss. Ausserdem hält er fest, dass man schlicht nicht alles wissen kann.
Diese Rahmenbedingungen zeigen bereits, dass es ein Team braucht, das auf der einen Seite gewillt ist, fortlaufend an sich zu arbeiten und auf der anderen Seite ganz bewusst diverse Kompetenzen sowie Wissen zusammenbringt. Das Team als Ganzes ist für diese Art von Arbeit der entscheidende Faktor.

Ich schliesse mich in diesem Kontext dem bekannten Produkt-Manager Marty Cagan (INSPIRED, 2018, S. 33) an und empfehle jedem angehenden Product Owner darauf zu achten, dass er möglichst die besten Leute als Wissensträger in seinem Team versammelt, die er finden kann. Nur ein crossfunktionales Team aus fähigen Menschen wird am Ende auch das bestmögliche Produkt bauen.

Hat der Product Owner sein Team aus fachlicher Sicht zusammen, muss überprüft werden, inwieweit die Kolleg/innen bereits mit dem agilen Arbeiten vertraut sind. Es kann sich durchaus der Fall ergeben, dass ein/e Kolleg/in aus fachlicher Sicht absolut geeignet ist, doch seine/ihre Arbeitsweise oder persönlichen Prinzipien nicht mit den Grundsätzen der Agilität (siehe Manifest für agile Softwareentwicklung) vereinbar sind. Wahrscheinlich sollte der Product Owner dann auf diese/n Kolleg/in im Team verzichten.

Die Berücksichtigung der Erfahrungen mit dem Framework sollte bei der Teamzusammenstellung ebenfalls nicht unterschätzt werden. Je nachdem wie hoch der Reifegrad des Teams ist, liegt es im Interesse des Product Owners, seine Kolleg/innen aus- und weiterzubilden. Nur auf diese Weise kann sichergestellt werden, dass er auch weiterhin das beste Team für den Job hinter sich weiß. Wie bereits zuvor angesprochen, stellen Schulungen einen guten ersten Schritt hierbei dar.

Eine weitere entscheidende Facette funktionierender Teams ist aus meiner Sicht ein klares Verständnis der Team-Rollen. Es sollte jedem bewusst sein, wer der Product Owner ist und warum er diese Stelle innehat. In Abhängigkeit des Frameworks sollten auch die anderen Rollen spezifiziert und erläutert werden. Eine klare Definition  der Rollen hilft Überschneidungen in Kompetenzen und Aufgaben zu vermeiden und fest zu halten, was von wem erwartet werden kann.

Explizit nicht gemeint sind an dieser Stelle Rollen wie „Tester” oder „Delivery Manager”, da diese aus meiner Erfahrung vor allem dazu dienen unliebsame Aufgaben weg zu delegieren. Die Teammitglieder müssen sich im Klaren darüber sein, dass sich im Verlauf der Produktentwicklung die Konstellationen verändern und an neue Situationen anpassen werden müssen. Auch hier gilt der agile Grundsatz „Inspect and Adapt”.

Neben klaren Rollen und einem gut ausgebildeten sowie diversen Team, braucht es vor allem eine gemeinsame Stossrichtung – also eine gemeinsame Vision. Umso besser der Product Owner diese im Rahmen der persönlichen Vorbereitung ausgearbeitet und ggf. validiert hat, desto leichter wird es ihm fallen auch sein Team davon zu überzeugen. Wie bereits zuvor angesprochen, ist es aus meiner Sicht eine der zentralen Aufgaben des Product Owners  sein Team hinter der Vision zu versammeln und das „Warum” klar für jeden zu beantworten. Das Wissen über Wert und Sinn der eigenen Arbeit im Rahmen eines grösseren Kontextes ist ein wesentlicher Treiber der Motivation eines jeden Teams. Letztlich sollte jeder im Team folgende Fragen beantworten können: 

1. Wer ist unsere Zielgruppe?

2. Welches Bedürfnis unserer Zielgruppe adressieren wir?

3. Wie tragen wir damit zum Unternehmenserfolg bei?

Die Vision stellt neben den teambezogenen Aspekten die Grundlage der Entwicklung und somit der fachlichen Anforderungen dar.
An dieser Stelle greift Grundsatz Nummer 1: Zerlege den Elefanten. Die Aufgabe des gesamten Entwicklungsteams, inklusive des Product Owners, ist es nun die Vision in kleinere Pakete zu zerlegen und erste Hypothesen zu formulieren.

Letztlich kommt es auf die gesteckte Aufgabe an, auf welcher Flughöhe die Hypothesen sich befinden und ob man komplett auf der grünen Wiese beginnt.
Je geringer die Erfahrungswerte in einem Bereich sind, desto wahrscheinlicher ist es, dass zum Beispiel ein Design Sprint notwendig ist, um die grösste Herausforderung im Rahmen der Vision zu identifizieren. Für diese wird eine Lösungshypothese erarbeitet, welche am Ende des Design Sprints grob getestet wird. Das Ergebnis kann genutzt werden, um später in die detaillierte Umsetzung einzusteigen. Während der Lösungsfindung werden sich neue Anforderungen und Hypothesen ergeben, wodurch man sich Stück für Stück der Vision nähert.

Bewegt man sich jedoch in einem Bereich, in dem bereits zahlreiche Erfahrungswerte vorliegen, kann man zu konkreten Methoden greifen. Möchte man zum Beispiel einen Online Shop entwickeln, ist die zugrunde liegende Customer Journey wahrscheinlich relativ klar und auch die ersten Aufgaben liegen meist auf der Hand. Um hier die ersten Arbeitshypothesen zu erhalten, könnte der Product Owner  einen Story Mapping Workshop ansetzen. Für die Bedienung der einzelnen Customer-Journey-Schritte werden hierbei Hypothesen, zum Beispiel als User Stories, formuliert.

Das Business Model des Product Owners stellt in jedem Fall auf dem Weg der Hypothesenerarbeitung den Startpunkt dar. Später dient es als Leitbild, um sich im Dschungel der Ideen nicht zu verlaufen.

Das letzte, aber nicht minder wichtige Handlungsfeld im Rahmen der entwicklungsbezogenen Vorbereitung umfasst die Erarbeitung von Arbeitsprozessen und Steuerungsmetriken.

Der Product Owner ist neben seiner Rolle als Visionär zugleich auch „Wertmaximierer“. Es gehört auch zu den Aufgaben des Product Owners sicherzustellen, dass sich die Investitionen lohnen und er dies belegen kann.

Ein erster Schritt, um den erbrachten Mehrwert der Entwicklung zu zeigen, ist die Hypothesen mit einem erwarteten Business Value zu versehen. Natürlich ist auch dieser Wert eine Annahme und beinhaltet verschiedene Dimensionen:

1. Wirtschaftlicher Wert – alles, was direkt auf den Profit einzahlt

2. Marktwert – eingeschätzter Unternehmenswert

3. Effizienzwert – Steigerung der Effizienz und Reduzierung der Betriebskosten

4. Kundenwert – Wert eines Kunden für das Unternehmen

5. Kosten durch Verzögerung – Opportunitätskosten und Risiko

Der Product Owner  muss von Fall zu Fall entscheiden, ob die Lösung einer Hypothese in ausreichendem Masse auf die Dimensionen einzahlen wird. Demnach ist der Business Value neben Aufwand, Risiko und Abhängigkeiten eine der zentralen Priorisierungsmetriken.

Hinter jeder der einzelnen Dimensionen stehen zudem messbare KPIs, anhand derer nach einem Release geprüft wird, ob die Hypothese zugetroffen hat. Beispielsweise könnte man durch Befragungen herausgefunden haben, dass die Kund/innen des eigenen B2B-Online-Shops zwar ihre Produkte auswendig kennen, aber Probleme haben sie im Shop zu finden. Durch den Fokus auf die Produktsuche erhofft man sich, die Umsätze um 5 % und die Kundenzufriedenheit um 7 % zu steigern sowie die Absprungraten um 2 % zu reduzieren.

Nun sollte man diese Lösung stets prototypisch testen, um in gewissem Masse einzuschätzen, ob sie funktionieren wird. Letztlich bleibt der Wert jedoch solange eine Annahme, bis er vom Markt belegt wird. Dies bedeutet, dass erst das Release zum Kunden und die Messung der KPIs Klarheit schaffen kann. Diese Messgrössen sollten auf der strategischen, taktischen und operativen Ebene Einzug in die Arbeit des Product Owners halten und konsequent auch vom Management eingefordert werden. In diesem Zusammenhang offenbart sich eine weitere Aufgabe des Product Owners: das Management von Stakeholdern.

Ein bewährtes Mittel sind Roadmaps. Sie dienen als Diskussions- sowie Planungsgrundlage und damit letztlich der Transparenz. Das Problem mit Roadmaps ist jedoch, dass sie oft als dogmatische und detaillierte Pläne betrachtet werden, die es einzuhalten gilt. Die Alternative dazu sind problem- und hypothesengetriebene Planungen (Marty Cagan, The Alternative to Roadmaps, 2015).

Um die notwendige Planungstransparenz nach innen und aussen zu schaffen, sollte der Product Owner  demnach eine Roadmap erstellen, die folgende Punkte aufzeigt:

1. Wann grob welche Hypothese angegangen werden soll 

2. Welche technischen Abhängigkeiten bestehen

3. Welche fachlichen Abhängigkeiten vorliegen

4. Welche Abhängigkeiten zum Management und Business (Steering Committees, Messen, etc.) es gibt

5. Wie die Planung von Finanzierungen (z.B. finanzielle Deadline) ist

Wichtig beim Einsatz von Roadmaps ist, diese in regelmäßigen Intervallen zu überprüfen und zu aktualisieren. Erfolgt dies nicht, verlieren sie ihren Nutzen und schaden mehr als sie helfen.

Nachdem ich als Product Owner nun eine Vision formuliert, mein Team zusammengestellt, erste Hypothesen formuliert, deren Metriken definiert und mir einen groben Plan gemacht habe, kommt die Frage, wie man das alles in einen operativen Modus überführt.

Ein typischer Entwicklungsprozess erstreckt sich von der Ideengenerierung, über die Schärfung erster Umsetzungsansätze und mündet schließlich in die konkrete Implementierung und Optimierung. Die Aufgabe des Product Owners ist es sicherzustellen, dass auch das geliefert wird, was er sich vorgestellt hat. Nur so kann er sich der Vision annähern.

Solange ich als Product Owner nicht ausreichend Erfahrungen gesammelt habe, um selbst einen Prozess aufzusetzen, ohne die Grundsätze der Agilität zu verletzen, sollte ich auf bewährte Frameworks wie Scrum oder Kanban zurückgreifen. Diese können als „Stützräder” dienen und mit ihren Regeln, Metriken und der zahlreichen Literatur den Einstieg in die Umsetzung erheblich erleichtern. Umso erfahrener das gesamte Team und der Product Owner  werden, desto sinnvoller und leichter wird es den Prozess an die eigenen Bedürfnisse anzupassen.

Ich würde an dieser Stelle jedem Product Owner empfehlen sich beraten bzw. unterstützen zu lassen und den Schulterschluss zu Agile Coach, Scrum Master etc. zu suchen. Arbeitet man in seinem Setup mit Dienstleistern wie Merkle zusammen, kann auch auf deren Beratungskompetenz, z.B. durch Product Owner Consultants, zurückgegriffen werden.

Eine gute persönliche und entwicklungsbezogene Vorbereitung und die Auseinandersetzung mit der Domäne sind die Grundlagen für erfolgreiche Produktentwicklungen, zufriedene Teams und letztlich zufriedene Kunden.

Die Aufgaben, vor denen man als Product Owner steht, scheinen zunächst überwältigend. Folgt man jedoch den genannten Schritten, kann der Einstieg leichter fallen. Zunächst überprüft man die eigenen Fähigkeiten und die eigene Position. Dann entwickelt man eine Vision, stellt das beste Team der Welt zusammen und reisst die Kolleg/innen für die Idee mit. Ist dies gelungen, werden die ersten Anforderungen in Form von Hypothesen erhoben, parallel Metriken für die Erfolgsmessung erarbeitet und eine grobe Planung erstellt. Den Abschluss bildet die Definition eines Umsetzungsprozesses unter Einbeziehung des Teams.

Was nun folgt, ist der erste Schritt auf einer womöglich nicht immer leichten, aber in jedem Fall spannenden, lehrreichen und prägenden Reise: Die Bearbeitung der ersten Scheibe des Elefanten.