10 Wege zum Erfolg bei der Präsentation einer Produkt-Roadmap

Die Präsentation einer Produkt-Roadmap kann für Entwickler und Produktmanager gleichermaßen nervenaufreibend sein: Die eine Partei hat hart an der Entwicklung einer Vision gearbeitet, während die andere Partei noch nicht weiß, was auf sie zukommt und wie es sich auf ihre Arbeit auswirkt.

Diesen Druck habe ich in meiner Zeit als Entwickler selbst oft gespürt und ich war häufig unzufrieden mit den von Produktmanagern erstellten Roadmaps. Ich war nicht vollständig von den getroffenen Entscheidungen überzeugt und dachte nach Ende des Planungsmeetings oft: "Mir erscheint das nicht sinnvoll, aber wenn die PMs so denken …" oder, noch schlimmer: "Wir müssen uns selbst etwas ausdenken und es dann so aussehen lassen, als würden wir uns an diese Roadmap halten".

Man könnte mir nun vorwerfen, ich hätte einfach nur am Not-invented-here-Syndrom (NIH) gelitten und du könntest sogar recht haben. Als Entwickler war ich immer sehr von meiner Meinung überzeugt. Erst jetzt als Produktmanager erkenne ich, worauf diese Spannungen zurückzuführen waren und was Produktmanager mit traditionellem Hintergrund daraus lernen können, um bei einer Roadmap-Präsentation mehr Erfolg zu haben. Es ist schließlich so: Nur wenn das Entwicklungsteam das Konzept versteht und ihm zustimmt, werden die alltäglichen Design- und Implementierungsentscheidungen im richtigen Kontext getroffen – und nur so entsteht tatsächlich das gewünschte Produkt.

Hier sind meine 10 besten Methoden, um Teams mit der Präsentation einer Produkt-Roadmap zu begeistern.

Typische Schlagwörter wie "Big Data-Analysen", "maschinelles Lernen" oder "eine Internet of Things-Initiative" kommen vielleicht in der Business-Abteilung gut an und sorgen für Orientierung. Für die Entwicklungsteams sind sie aber weder hilfreich noch aussagekräftig. Die Entwickler müssen genau wissen, woran sie arbeiten, in welchem Zusammenhang die Lösung zu den aktuellen Produkten steht, wie sie bereitgestellt werden soll und wer sie letztlich für welchen Zweck nutzen wird.

Übergeordnete Themen sind praktisch, um die Roadmap und den Kontext zu strukturieren. Sie sollten aber nicht als selbsterklärend angesehen werden – erläutere immer klar, was hinter einem Thema steht. Wenn du beispielsweise das Thema "intelligente Services" auf die Roadmap setzt, halte auch die wichtigsten Initiativen und Epics fest, die zur Umsetzung des Themas erforderlich sind.

Entwicklungsteams benötigen Kontext zu den Projekten auf einer Roadmap, d. h. Hintergrundinformationen und eine Antwort auf die Frage "warum". Kein Entwicklungsteam wird jemals blind mit der Arbeit loslegen. Im Gegenteil, Entwickler wollen von einem Produktmanager genau wissen, warum ein Feature entwickelt werden sollte und ob Kunden danach fragen. Als Begründung kannst du Daten anführen, aber auch eine überzeugende Schilderung aus der Sicht der Benutzer ist wichtig. Spreche verschiedene Rollen an und erwähne auch Alternativen, die du ausgeschlossen hast (mit Begründung). Das gesamte Team muss das "Warum" hinter der Roadmap genauso gut verstehen wie das "Was".

Wenn ein Feature nicht gut durchdacht oder unrealistisch erscheint und dennoch auf der Roadmap steht, stimmt etwas nicht. Das Entwicklungsteam sollte nicht den Eindruck gewinnen, dass es Features entwickeln muss, nur weil du jemandem diese Features zugesagt hast. Dabei spielt es keine Rolle, ob es sich um eine Zusage gegenüber Kunden oder dem Management handelt. Wäge Zusagen also im Vorfeld sorgfältig ab. Selbst wenn dich jemand unter Druck setzt, eine bestimmte Änderung durchzuführen, solltest du die Begründung nachvollziehen können und sie an das Team weitergeben, um deinen Standpunkt sicher vertreten zu können.

Eine Vision ist gut – noch besser ist es, wenn alle Beteiligten von ihrer Umsetzbarkeit überzeugt sind. Auch wenn der Plan nicht ins Detail geht, erkennen Entwicklungsmanager größere Engpässe schon beim ersten Blick auf die Roadmap. Dies kann beispielsweise der Fall sein, wenn die Roadmap viel Gewicht auf das Design und das Front-end legt, zum Entwicklungsteam jedoch nur ein einziger Designspezialist gehört und das Team in den letzten Monaten immer wieder Probleme mit Front-end-Themen hatte. In einem solchen Fall wird es dir nicht gelingen, das Team von der Roadmap zu überzeugen.

Prüfe daher vorher in Absprache mit dem Entwicklerteam die Umsetzbarkeit, und spiele mit möglichen Szenarios. Du benötigst klare Antworten, einen eindeutigen Handlungsplan und exakte Vorstellungen von der Umsetzung, bevor du die anderen Beteiligten ins Boot holst.

Du solltest wissen, wie es derzeit um das Produkt und die Teamfähigkeiten bestellt ist und was du für die Zukunft erwartest. Es kann wunderbar sein, in neue Fachgebiete vorzudringen, die möglicherweise neue Kenntnisse im Team oder eine Abkehr von den bisherigen Technologien erfordern. Schreibe aber nicht einfach auf, was du in einem Jahr gerne erreicht haben möchtest. Überlege dir, ob und wie der Weg dorthin zu bestreiten ist. Es braucht Zeit, neue Kenntnisse zu erwerben und neue Technologien einzuführen. Der Verzicht auf bisherige Produkte erfordert klare Zielsetzungen und einen Plan für die Übergangszeit.

Ein Business Case? Ja, bitte. Entwicklungsteams sind Business Cases durchaus wichtig. Sie haben dort vielleicht nicht dieselbe Bedeutung wie in der Führungsetage, aber das ganze Entwicklerteam möchte wissen, warum ein Feature für das Unternehmen wichtig ist, ob es sich in der Praxis bewährt und wie dies gemessen wird. Nutze die Geschäftstüchtigkeit deines Entwicklungsteams. Jeder Mitarbeiter hat ein konkretes Interesse am Erfolg des Unternehmens und kann möglicherweise wertvolles Feedback oder weiterführende Ideen liefern.

Wenn das Entwicklungsteam weiß, welche Vorteile für das Geschäft zu erwarten sind, und den Weg dorthin nachvollziehen kann, ist dies ein großer Motivationsfaktor. Positive Ergebnisse erzielt zu haben sorgt für deutlich mehr Zufriedenheit als "nur" ein Feature entwickelt und zur Marktreife gebracht zu haben.

Entwickler möchten einzigartige, innovative Produkte erstellen, auf die sie stolz sein können. Wenn es nur um ein Standardprodukt geht, das in ähnlicher Form auch bei Mitbewerbern zu finden ist, leidet die Motivation. Recherchiere gründlich, um sicherzugehen, dass deine Idee so innovativ ist, wie du denkst. Abgesehen von den demotivierten Entwicklern hat mangelnde Innovation auch verheerende Folgen für das Geschäft.

Trotz allem gibt es technisch nicht allzu interessante Must-haves, die einfach abgehakt werden müssen – so gilt es in Roadmaps immer die richtige Balance zwischen spannenden neuen Features und dem simplen Alltagsgeschäft zu finden. Versuche, auch triviale Punkte in der Roadmap motivierend zu formulieren.

Die Entwicklung eines MVP (Minimum Viable Product) und einer Version 1 ist wichtig, aber die Geschichte endet nicht damit. Nach der Markteinführung folgen Betrieb, Wartung, Featureanfragen von Benutzern, fortlaufende Verbesserungen und neue Versionen anderer Produkte und/oder Plattformen, die in die Lösung integriert sind. Die Entwickler werden es dir danken, wenn du kurz über die möglichen Herausforderungen und Schwierigkeiten nach der Markteinführung nachdenkst und auch diese Aspekte ihrer Arbeit berücksichtigst. Groben Schätzungen zufolge macht der anfängliche Aufwand der Entwicklung eines neuen Features oft nur ein Drittel bis die Hälfte des Gesamtaufwands im ganzen Lebenszyklus dieses Features aus. Anders gesagt: Die Folgekosten sind höher als die Entwicklungskosten und manche "schnellen kleinen Aufgaben" werden auf Dauer sehr teuer.

Schätzungen sind wichtig. Sie bieten Orientierungspunkte und werden vom Produktmanager immer nach bestem Wissen und Gewissen erstellt. Viele für Schätzungen getroffene Annahmen erweisen sich jedoch bei der Implementierung oder näheren Ausarbeitung eines Entwurfs als völlig falsch. Lass daher bei der Vorbereitung und Präsentation der Roadmap Raum für flexible Anpassungen.

Eine Roadmap soll Anhaltspunkte für das Vorgehen liefern. Sie ist kein detaillierter Plan zur Ausführung – das weiß jeder im Softwareteam. Spare dir die Mühe, die Roadmap als etwas anderes zu verkaufen. Wenn du zu einem Thema noch nicht alle Details kennst, dann stehe dazu. Teile den anderen Beteiligten mit, was du weißt, welche Absicht dahintersteht, welche Fragen noch offen sind und welche entscheidenden Risiken noch geklärt werden müssen. Weise auf Bereiche hin, in denen zur Klärung weiter experimentiert und recherchiert werden muss. Den Zeitaufwand dafür musst du natürlich bei der Planung berücksichtigen.

Dein Team verdient eine Roadmap, die klar eine Richtung vorgibt, dabei jedoch die Realität nicht außer Acht lässt. Diese Roadmap sollte motivierend und anregend sein und genügend Details enthalten, damit das ganze Softwareteam weiß, welche Aufgaben in den nächsten ein oder zwei Sprints anstehen. Nach der Präsentation sollten alle überzeugt sein, dass sie gute Ergebnisse für das Team und das ganze Unternehmen erzielen werden.

Brauchst du noch mehr Unterstützung? Schau dir die Roadmap-Funktionen in Jira Software und eine Vorlage für eine Produkt-Roadmap in Jira an. Oder teste kostenlos das speziell für Produktmanager entwickelte Jira Product Discovery.