Der Product Owner und sein erstes Projekt.

Nicht selten habe ich in den vergangenen Jahren Product Owner (PO) erlebt, die in diese Rolle mehr oder weniger unfreiwillig hineingerutscht sind. Dies klingt zunächst negativer als es ist. Einer der wesentlichen Unterschiede zu jemandem, der sich aktiv in diese Rolle entwickeln möchte, besteht darin, dass diese “unfreiwilligen” Product Owner meist sehr wenig Zeit haben, sich mit ihrer Rolle auseinander zu setzen.

Aus eigener Erfahrung kann ich sagen, dass man gerade bei großen IT-Projekten mit mehreren Streams im ersten Moment komplett überfordert ist. Wo fängt man an, auf was muss man achten? Wer kann mir helfen und wie strukturiere ich mich selbst?

Product Owner - Erstes Projekt

Für mich haben sich drei Grundregeln 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.
    Man nimmt sich eine der identifizierten Herausforderungen, fokussiert sich, löst sie und widmet sich 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 mit deinem Team entwickelst.

Zu Beginn eines Projektes geht es meistens nur darum, möglichst ohne größere Probleme und zügig mit der Entwicklung des MVP zu starten. Auf dieses Anliegen sollte sich demnach zunächst die gesamte Arbeit des POs 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 des Product Owners. Dem gegenüber steht die notwendige Vorbereitung des Projektes bzw. Produktes, um in die Entwicklung einsteigen zu können.

Persönliche Vorbereitung oder “Was mache ich hier eigentlich?”

Grundregel eins besagt, dass man das große 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 nämlich 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? Außerdem 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. Große 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 Namics 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:

  • 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 eigenverantwortlich darüber entscheiden?
  • Habe ich die notwendige Rückendeckung von Management-Positionen?
  • Steht mir ausreichend Zeit für meine Rolle als PO 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 zu machen. Doch gerade bei einer positiven Beantwortung der ersten Punkte in der Liste steigen die Erfolgschancen des Vorhabens erheblich.

Neben diesen nach außen gerichteten Fragen, sollte sich ein angehender PO 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 er 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 Kontexts, 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 PO 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.

Entwicklungsbezogene Vorbereitung oder “Wie bekomme ich das Ding aus den Startlöchern?”

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 PO, 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.

Zusammenstellung eines Teams

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. Außerdem 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 diverseste Kompetenzen sowie Wissen zusammenbringt. Das Team als Ganzes ist für diese Art von Arbeit der absolut entscheidende Faktor.

Ich schließe 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 den fähigsten Menschen wird am Ende auch das bestmögliche Produkt bauen.

Hat man sein Team aus fachlicher Sicht zusammen, muss überprüft werden, inwieweit die Kollegen bereits mit agilem Arbeiten vertraut sind. Es kann sich durchaus der Fall ergeben, dass ein Kollege aus fachlicher Sicht absolut geeignet ist, doch seine Arbeitsweise oder persönlichen Prinzipien nicht mit den Grundsätzen der Agilität (siehe Manifest für agile Softwareentwicklung) vereinbar sind. Wahrscheinlich sollte ich als Product Owner dann auf diesen Kollegen 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 PO, seine Kollegen 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 zum Beispiel 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 gute Klärung 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 auch 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”.

Hypothesen und Anforderungen

Neben klaren Rollen und einem gut ausgebildeten sowie diversen Team, braucht es vor allem eine gemeinsame Stoßrichtung – 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 PO 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ößeren Kontextes ist meiner Erfahrung nach 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 PO, 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ößte 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 konkreteren 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 PO 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 Owner 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.

Steuermechanismen und Prozesse

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“. Demnach ist es auch seine Aufgabe 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 PO muss von Fall zu Fall entscheiden, ob die Lösung einer Hypothese in ausreichendem Maße 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 Kunden 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 Maße 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ößen sollten auf der strategischen, taktischen und operativen Ebene Einzug in die Arbeit des PO halten und konsequent auch vom Management eingefordert werden. In diesem Zusammenhang offenbart sich eine weitere Aufgabe des Product Owners: das Management von Stakeholdern.

Ein durchaus bewährtes Mittel sind Roadmaps. Sie dienen als Diskussions- sowie Planungsgrundlage und damit letztlich der Transparenz. Das Problem mit Roadmaps ist jedoch, dass sie oftmals 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 außen zu schaffen, sollte der PO demnach eine Roadmap erstellen, die folgende Punkte aufzeigt:

  1. Wann man grob welche Hypothese angehen möchte
  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 PO 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 ich selbst als PO werde, 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 Namics zusammen, kann auch auf deren Beratungskompetenz, z.B. durch Product Owner Consultants, zurückgegriffen werden.

Product Owner wird man nicht über Nacht

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 reißt die Kollegen 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.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>