Habe gerade eine spannende Idee in unserer Organisation gepflanzt. Während eines Workshops zum Aufstellen der Roadmap unserer weiteren Produktentwicklung sind wir in unser herkömmlichen Art vorgegangen: In der Gruppe gab es viele gute Produktideen und Wünsche. Daneben handfeste Features aber auch zahlreiche Einzelprobleme mit teils noch unklarer Lösung. Als Zwischenstand ergab dies eine Liste aus Produktfeatures in stark unterschiedlicher Reife und Granuläritat. In der Methode zeigte sich ein bekanntes Muster, das durchbrochen werden musste. Priorisiert wurde diese Liste durch die sehr guten Erfahrungen eines jeden Produktvertreters. Allerdings folgte diese Priorisierung noch keiner gemeinschaftlich wahrgenommenen Wichtigkeit. Vielmehr waren individuelle Erfahrungen aus dem operativen Geschäft die Grundlage für die Einschätzung. Die Benefits hinter jeder Meldung waren nicht vorher transparent, sondern wurden stets auf Nachfragen begründet. Interessante Beobachtung: Je bewegter die Diskussion wurde, desto mehr glich die Begründung einer Rechtfertigung für den jeweils genannten Punkt – das “Feilschen” setzte ein!
Bekannte Risiken
Mit dem Zwischenergebnis war ich trotz – oder gerade wegen – der gesunden Diskussion schon ganz zufrieden: In der Gruppe herrschte breiter Konsens. Wir hatten gemeinsam die Themen inhaltlich verstanden. Wir waren uns klar darüber, wie wichtig jedes Produktfeature im Vergleich zum anderen sei und damit einig, mit welcher Priorität sie zu einander standen.
Mir fehlte an diesem Tag allerdings noch einer der wichtigsten Aspekte: Wie bringen wir nun die Mannschaft dazu, motiviert beim Umsetzen der sehr umfangreichen und ambitionierten Liste mit zu ziehen? Erfahrungsgemäß zeigen sich mit einem solchen Ansatz folgende Probleme:
- Unklares Verständnis: Die Menschen in der Organisation interpretieren Features jeweils anders. Wegen der nur knappen Benennung in einer Liste gibt es inhaltliche Missverständnisse
- Subjektive Priorität: Wie wichtig ein Feature ist, betrachtet jeder Mitarbeiter aus seiner eigenen Erfahrung ganz subjektiv. Das wird sich gerade in gestressten Projektphasen darin äußern, dass einige Menschen die eigenen Probleme als wichtiger erachten und dann ausscheren. Zu verdenken ist es in dem Moment nicht.
- Mangelnder Raum für Kreativität: Eine fertige Liste legt die Inhalte auf längere Zeit fest. Dabei bleibt für die Mannschaft kaum Platz, eigene Ideen zu generieren oder Lösungen für Probleme zu finden. Oft schlummern dort aber die besten Ideen. Sie bleiben dann weitestgehend ungenutzt.
- Fehlende Flexibilität: Nach wenigen Wochen entstehen neue Wünsche, neue operative Erkenntnisse wollen angegangen werden, neue Produktideen wollen erprobt werden. Mit einer längerfristig festgelegten Liste führt das zu Unzufriedenheit. Es ist ja kein Patz mehr.
Das sollte uns nicht passieren! Mir fiel nach dem ersten Workshoptag wieder ein, was ich in meiner Elternzeit gefunden hatte: die Goal Oriented Product Roadmap von Roman Pichler.
Kernfragen der GO Product Roadmap
Mit der GO Product Roadmap arbeiten, heißt, sich vor allem folgende Fragen zu stellen:
- Welches Ziel (Goal) verfolge ich mit meinem nächsten Produktrelease? Welches Ziel ist es mir wert, um die komplette Mannschaft darauf zu fokussieren?
- Welche Kennzahlen (KPIs) möchte ich mit diesem Release wie stark verbessern?
- Welche Funktionen (Features) sind am besten geeignet, das Ziel und die gesetzten Kennzahlen zu erreichen?
Selbstverständlich ist ein absehbarer Zielhorizont von 6-8 Wochen unverzichtbar, um den Einsatz zu konzentriert und möglichst schnell Erfolge messbar zu machen.
Ich sah die Zeit reif genug und den Moment perfekt an und stellte am Tag 2 des Workshops die Idee der GO Product Roadmap spontan vor.
Erste Erfahrungen
Die erste Herausforderung war es, von dem eingeschlagenen Weg (priorisierte Featureliste) eine Brücke zu schlagen hin zu einer neuartigen Roadmap. Vor allem war für einige Beteiligte folgendes schwierig: Sie hatten ja eine klare Vorstellung ihrer “Lieblingsthemen”, bereits eine Reihenfolge verteidigt und somit ein grobes Gefühl dafür, wann sie es grob umgesetzt bekämen – das trügerische Gefühl eines belastbaren Plans. Jetzt aber mussten sie mindestens einen Abstraktionslevel höher ansetzen. Sie mussten ihre Features beiseite legen und sich auf die eigentlichen Ziele verständigen. Das heißt Loslassen der fertig definierten Lösungen und zuerst die eher strategische, visionäre Produktausrichtung definieren. Spannender Prozess für alle Gehirne.
Auch ein anderer zeitlicher Horizont war nun gefragt: statt des Versuchs einer langen (Halb)Jahresplanung ging es darum, sich auf das kommende Quartal zu fokussieren. Das lenkt ab von eher großkalibrigen Problemdiskussionen und bringt hin zu “Wie können wir die wichtigsten Themen jetzt konkret angehen?” So einfach das klingt, ist es doch eine radikal andere Herangehensweise. Sie bringt jeden raus aus der Komfortzone des üblichen Handelns.
Ich freue mich auf das weitere Arbeiten mit der Goal Oriented Product Roadmap und werde hier weiter berichten.
Habt Ihr bereits Erfahrungen mit der GO Product Roadmap gemacht? Oder alternative Wege genommen? Freue mich auf Berichte!
Mehr Details und weitere Aspekte, wie das Vision Board und den Product Canvas findet Ihr bei Roman Pichler.
photo credit: <a href=”https://www.flickr.com/photos/geomangio/2575358644/”>Geomangio</a> via <a href=”https://photopin.com”>photopin</a> <a href=”https://creativecommons.org/licenses/by-nc-sa/2.0/”>cc</a>