Die Präsentation eines Fahrplans kann sowohl für Entwickler als auch für Produktmanager eine spannungsgeladene Sache sein. Eine Partei hat hart dafür gearbeitet, um eine Vision zu erschaffen, während die andere Partei darauf wartet, das Unbekannte zu sehen, welches in Zukunft ihre Arbeit beeinflussen wird. Atlassian hat einen Artikel dazu veröffentlicht, was Produktmanager beachten sollten, wenn sie Roadmaps erstellen.

Wer als Entwickler tätig war oder ist kennt die Spannungen, die entstehen können, wenn die Roadmaps des Produktmanagements nicht zur Zufriedenheit aller sind. Die Entscheidungen mögen nicht immer schlüssig sein und Planungsmeetings können entweder in Resignation („Nun, ich finde, das macht keinen Sinn, aber wenn die so denken …“) oder Schadensbegrenzung („Wir müssen die Dinge wohl selbst in die Hand nehmen und es so aussehen lassen, als hätten wir diese Roadmap befolgt.“) münden.

Entwickler haben oft eine sehr starke Meinung über das, was sie für richtig halten. Produktmanager müssen verstehen, was die Ursache für diese Meinungsverschiedenheiten sind und welche allgemeinen Erkenntnisse Produktmanager daraus ziehen können, um bei ihrer nächsten Roadmap-Präsentation einen Sieg einzufahren. Schließlich sollte Ziel sein, dass das technische Team Ihnen als Produktmanager zustimmt und das große Ganze versteht. Somit können Design und die Implementierung von Entscheidungen im richtigen Kontext vorgenommen werden, und Sie können das Produkt so erhalten, wie Sie es sich vorgestellt haben. Also direkt weiter zum ersten Satz von Tipps:

1. Mehr Substanz, weniger Schlagwörter

Während Schlagworte wie „Big Data Analytics“, „Maschinelles Lernen“ oder „Internet der Dinge-Initiative (IoT)“ vielleicht von den Interessenvertretern als High-Level-Ankerpunkte betrachtet werden, sind sie für technische Teams keine hilfreichen und umsetzbaren Dinge. Die Entwickler müssen genau wissen, was sie bauen, in welchem Zusammenhang es mit bestehenden Produkten steht, wie es abgeliefert werden soll, und wer es am Ende für welchen Zweck verwenden wird.

Das Festlegen von High-Level-Themen sind für die Strukturierung der Roadmap und des Kontextes großartig, aber sorgen Sie dafür, dass Sie nicht einfach an diesem Punkt aufhören, sondern stellen Sie sicher, dass Sie gute Antworten darauf haben, was sich hinter jedem dieser High-Level-Themen verbirgt. Wenn Sie beispielsweise ein Thema „intelligente Dienste“ genannt haben, dann unterteilen Sie dieses in Schlüsselinitiativen und Epics, die benötigt werden, um dieses Thema abliefern zu können.

2. Den richtigen Kontext festlegen

Technische Teams benötigen einen Kontext für Dinge, die Sie in Ihre Roadmap einbauen. Kein technisches Team wird Ihnen sagen: „Sagen Sie mir einfach, was Sie möchten, und ich werde es für Sie erledigen.“ Ganz im Gegenteil, Entwickler möchten sogar Beweise dafür, warum Sie Bedarf für ein bestimmtes Feature sehen. Lassen Sie zwar Daten sprechen, aber erzählen Sie auch eine überzeugende Geschichte aus der Sicht Ihrer Nutzer. Verwenden Sie Personas, und sprechen über einige Alternativen, die Sie zuvor ausgeschlossen haben, und warum. Um dafür zu sorgen, dass das ganze Team die Roadmap versteht, ist das „warum“ ebenso wichtig, wie das „was“.

Lassen Sie Daten sprechen, aber erzählen Sie auch eine überzeugende Geschichte aus Sicht Ihrer Nutzer.

3. Verpflichtungen sorgfältig betrachten

Wenn ein Feature nicht gut durchdacht und realistisch erscheint, aber es immer noch auf der Roadmap ist – dann sollte Ihnen das sofort auffallen. Sie wollen nicht, dass das technische Team den Eindruck erhält, sie müssten eine Sache einbauen, nur weil Sie es jemandem versprochen haben. Dies könnte eine Verpflichtung gegenüber einem Kunden sein, oder weil das „Management“ es so will. Seien Sie also weise, was das Eingehen von Verpflichtungen angeht. Selbst wenn Sie dazu gezwungen werden, eine bestimmte Änderung vorzunehmen, müssen Sie trotzdem sicherstellen, dass Sie die Gründe verstehen und an das Team weitergeben und selbst dahinterstehen.

4. Machen Sie realistische Pläne

Eine Vision ist gut, aber es ist noch besser, wenn jeder daran glaubt, dass sie umgesetzt werden kann. Der Plan muss nicht präzise sein, aber wenn das erste, was Ihr Entwicklungsmanager sieht, ein großer Engpass ist – zum Beispiel, wenn die Roadmap den Schwerpunkt auf das Design setzt, aber das Team nur einen Designer hat und in den letzten Monaten mit Frontend-Themen zu kämpfen hatte – dann werden Sie während der gesamten Präsentation mit der Roadmap zu kämpfen haben.

Sorgen Sie dafür, dass Sie im Voraus einen Reality-Check mit dem Team durchführen und Was-wäre-wenn-Szenarien durchspielen. Sie brauchen Antworten, einen klaren Aktionsplan und müssen genauestens betrachten, „wie es erledigt werden kann“, bevor Sie andere darum bitten können, sich für den Plan zu verpflichten.

5. Think big, start small

Sie müssen sich im Klaren darüber sein, wo Produkt und Teamfähigkeit im Moment sind, verglichen damit, wo Sie sie haben möchten. Es ist großartig, in neue Bereiche vorzurücken, die in Ihrem Team neue Fähigkeiten erfordern, oder die sich von bestehenden Technologien entfernen, aber schreiben Sie nicht einfach nur Ihre Wunschvorstellungen darüber auf, wo Sie in einem Jahr sein möchten. Denken Sie stattdessen darüber nach, wie Sie auf realistische Weise dorthin gelangen können. Es erfordert Zeit, neue Talente zu finden, neue Technologien einzuführen, und auch das Aufgeben bestehender Produkte erfordert Verpflichtungen und einen Übergangsplan.

Weitere Fragen?

Dann sind wir als clevere Lösungsfinder für Sie da. Tragen Sie jetzt alle noch offen gebliebenen Fragen und Wünsche zum Thema Roadmaps und Produkt- und Projektplanung an uns heran. Wir freuen uns darauf, gemeinsam mit Ihnen herauszufinden, wie Sie die passenden Werkzeuge und Prozesse finden.

  • Hier finden Sie ausführlichere Informationen zu unseren Atlassian-Leistungen.
  • Sie haben Interesse an einer Demo von Atlassian-Produkten, wollen mehr über das Thema erfahren oder eine individuelle Beratung erhalten? Wenden Sie sich dafür über das Kontaktformular an uns.