Product Owner Tools – Teil 1

von Gregor Meyenberg

Der Gedanke, dass ich als Produkt Owner meine eigenen Produktideen verwirklichen kann war für mich stets verlockend. Nach einigen Jahren weiß ich aber, dass die Realität der Arbeitswelt meist anders aussieht. In sehr vielen Fällen muss ich die Idee eines anderen übernehmen, mich selbst dafür begeistern, um dann wiederum andere von der Idee begeistern zu können und schließlich das Produkt effizient in die Umsetzung bringen.

Damit das gelingt, ist es wichtig die Intention des geplanten Produktes im Detail zu durchdringen. Wir stellen hier ein paar Tools vor, die sich für Product Owner bei Goodgame Studios (GGS) im Alltag bewährt haben.

Rahmenbedingungen

Bei GGS gibt es verschiedene zentrale Abteilungen, die für die Game-Studios und andere zentrale Bereiche Produkte liefert (Shop, Landing Pages etc.). Sich veränderndende Produktwünsche und -prioritäten sind eine ständige Herausforderung. Anstatt für jedes Produkt ein neues Team aufzusetzen geben wir neue Produkte an bestehende Teams. So verhindern wir einen ständigen Neustart des Tuckman Cycle (Forming – Storming – Norming – Performing).

Der Auftrag

Eine Fachabteilung tritt mit einer neuen Produktidee in der Regel an den Product Owner heran, den sie bereits kennt. Um ein Gefühl für die Priorität zu bekommen, versuchen wir initial den erwarteten Business Value abzuschätzen (Revenue Uplift, Steigerung der Registrierungen, Erhöhung der Retention etc.).

Geht es um ein größere Produktidee entscheiden die Product Owner des Bereichs gemeinsam, welche Teams für die Entwicklung in Frage kommen. Die Entscheidung basiert immer auf dem Wert des neuen Produktes in Relation zu dem Wert der Lieferung, die ein Product Owner bereits in seiner Roadmap geplant hat.

Jeder Product Owner in dessen Team eine Umsetzung  des neuen Produktes Sinn ergibt, liefert drei mögliche Umsetzungsoptionen, legt die jeweiligen Auswirkungen anhand seiner Roadmap dar und listet Vor- und Nachteile für das Unternehmen in einer knappen Zusammenfassung.

Die Gruppe der Product Owner aggregiert die besten Optionen und stimmt sie (bei besonders großem Impact) mit dem Management ab. Dazu betrachten wir insbesondere den “Cost of Delay”. Nach der Entscheidung für eine Option geht der Arbeitsauftrag ins Backlog des gewählten Teams.

Story Mapping

Damit Entwickler, Product Owner und Stakeholder ein gemeinsames Verständnis der Produktidee entwickeln, hilft es gemeinsam die “Geschichte” zum Produkt zu erarbeiten. Gerade zu Beginn eines Projektes führen wir dazu gerne Story Mapping Workshops durch.

Das Big Picture und die Projektziele sollten für alle Beteiligten gut sichtbar gemacht werden, z.B. mit einer Product Wall.

Der “User” sollte immer im Vordergrund stehen. Letztendlich ergibt sich die Daseinsberechtigung der Software daraus, dass sie für jemanden von Nutzen ist.

Insofern kann man sich als Product Owner die zentrale Frage stellen, wessen Leben man zum Positiven verändern will und warum?

Daraus ergibt sich dann der Business Case.

Produktvision

Die Produkt-Vision ist ein Steuerungs-Werkzeug für die Produktentwicklung. Sie ermöglicht es allen Projektbeteiligten immer wieder zu validieren, ob die geplante Arbeit auf die Vision einzahlt.

Produkt-Vision neben dem Team-Taskboard

Eine gute Vision wird oft in intensiven Gesprächen mit den Stakeholdern erarbeitet, z.B. im Zusammenhang mit oben genanntem Story Mapping Workshop. In seinem Management3.0-Buch listet Jurgen Appelo hilfreiche Qualitätskriterien für eine Vision auf:

Zudem orientieren wir uns an den zahlreichen Templates für Product Visionen, wie dem Business Model Canvas oder Roman Pichlers Product Vision Board.

Am Ende sollten sich alle Beteiligten auf die Vision committen, von der Geschäftsleitung bis zum Entwicklungsteam.

Fortsetzung HIER.

Gregor Meyenberg ist Product Owner bei Goodgame Studios