Ein Roadmap-Dokument schreiben, das die Kompromisse erklärt
5 Min. Lesezeit
Die meisten Roadmap-Dokumente sind eine Rangliste ohne sichtbare Begründung. Das funktioniert gut, bis ein Stakeholder fragt, warum Feature B über Feature A steht, und die ehrliche Antwort eine Mischung aus Bauchgefühl und wer zuletzt gefragt hat ist, was im Meeting nicht gut ankommt. Ein PM, der einer Runde von Stakeholdern eine sechsteilige Roadmap vorstellt, jeder mit seinem eigenen Lieblingsfeature, kann das ganze Meeting damit verbringen, die Reihenfolge mündlich zu verteidigen, statt auf eine Begründung zu zeigen, die schon auf dem Papier stand.
Achtung
Eine Rangliste ohne Begründung ist keine Entscheidung, sie ist ein Platzhalter für eine. Die erste schwierige Frage im Raum zeigt, ob die Einstufung tatsächlich durchdacht war.
Eine Roadmap, die ihre eigene Reihenfolge nicht erklären kann, ist keine Roadmap. Es ist eine Liste, die darauf wartet, neu diskutiert zu werden.
Warum eine unbegründete Einstufung jedes Mal neu diskutiert wird
Nach Bauchgefühl einzustufen mag richtig sein, aber niemand anderes kann es bewerten, also hat jeder Stakeholder mit anderer Intuition Grund, zurückzudrängen. Ohne sichtbare Begründung passiert dasselbe Kompromissgespräch im nächsten Meeting wieder, und im übernächsten. Eine Roadmap, die als bloße geordnete Liste präsentiert wird, lädt genau zu der Debatte ein, die eine gut begründete verhindert, da ein skeptischer Stakeholder nichts auf dem Papier hat, mit dem er sich auseinandersetzen kann, außer der Erinnerung des PM daran, warum er jede Entscheidung getroffen hat.
Stell dir eine quartalsweise Roadmap-Durchsicht vor, bei der eine technische Leiterin fragt, warum ein Feature mit kleinerer Wirkung über einem mit klar größerer erwarteter Reichweite steht. Lebt die ehrliche Antwort nur im Kopf des PM, „es fühlte sich einfach dringender an“, wird das Meeting zu einer Echtzeit-Verhandlung mit wem auch immer am härtesten drängt. Ist dieselbe Frage schon auf dem Papier beantwortet, „Feature A steht trotz kleinerer Reichweite höher, weil es eine Partnerintegration mit vertraglicher Frist nächsten Monat freischaltet“, verschiebt sich das Gespräch darauf, ob diese Begründung standhält, was ein weit produktiverer Ort dafür ist.
Vorher: Features nach Instinkt einstufen, die Liste präsentieren, das Meeting damit verbringen, die Reihenfolge von Grund auf zu verteidigen.
Nachher: Claude die Kandidaten-Features mit Aufwand und Wirkung geben, eine eingestufte Roadmap mit ausgeschriebener Begründung für jede Position zurückbekommen, und mit den Kompromissen schon auf dem Papier ins Meeting gehen.
Ein Prozess für eine Roadmap mit sichtbarer Begründung
- 1
Kandidaten mit echten Aufwands- und Wirkungsschätzungen auflisten
Gib echte Zahlen, auch grobe, Entwicklungswochen für Aufwand, erwartete betroffene Nutzer für Wirkung, statt vager Labels wie „groß“ oder „klein“. Vage Eingaben erzeugen eine Einstufung ohne solide Grundlage.
- 2
Um eine Einstufung mit begründetem Grund pro Punkt bitten
Fordere zwei Begründungssätze pro Feature an, nicht nur eine eingestufte Liste. Die Begründung ist es, die die Roadmap in einem Raum voller Menschen mit eigenen Meinungen verteidigbar macht.
- 3
Fragen, was die Einstufung ändern würde
Hast du einen ersten Durchgang, frag, welche Features am nächsten daran sind, die Plätze zu tauschen, und was dafür wahr sein müsste. Hier werden die echten Kompromisse sichtbar, nicht nur die finale Reihenfolge.
- 4
Die Begründung gegen das prüfen, was Stakeholdern tatsächlich wichtig ist
Vergleiche die genannte Begründung mit dem, was den Menschen im Raum wichtig ist, Umsatz, Kundenbindung, technische Schulden. Eine Einstufung, die nur Aufwand und Wirkung widerspiegelt, kann das eigentliche Gespräch trotzdem verpassen.
Hier sind 6 Kandidaten-Features mit groben Aufwandsschätzungen und erwarteter Wirkung. Stufe sie in eine Q3-Roadmap ein, und schreibe zwei Sätze, die jede Einstufung begründen.
”Ist bekannt, dass ein bestimmter Stakeholder eine Dimension stärker gewichtet als andere, etwa, die Entwicklungsleitung ist stärker am Abbau technischer Schulden interessiert, als die aktuelle Liste widerspiegelt, lohnt es sich, Claude zu bitten, die Einstufung mit dieser Priorität explizit benannt zu gewichten, statt eine einzige Einstufung zu präsentieren, die implizit annimmt, alle teilten dieselben Prioritäten.
Die Entwicklungsleitung hat technische Schulden als größere Priorität markiert, als diese Einstufung derzeit widerspiegelt. Zeig mir, wie sich die Reihenfolge ändern würde, wenn der Abbau technischer Schulden ebenso stark gewichtet würde wie die Nutzerwirkung, damit ich beide Versionen vor dem Meeting vergleichen kann.
”
In Claude Tutorial
Die Begründung hinter einer Einstufung sichtbar zu machen ist übertragbar.
Eine Bauchgefühl-Entscheidung in eine mit ausgesprochener, prüfbarer Begründung zu verwandeln gilt weit über Roadmaps hinaus. Die App hat eine vollständige Lektion dazu, mit Übungen, die sich auf jede Priorisierungsentscheidung übertragen lassen, die du verteidigen musst.
Wenn zwei Features wirklich knapp beieinanderliegen
Manchmal ist die ehrliche Antwort, dass zwei Features so knapp beieinanderliegen, dass beide Reihenfolgen vertretbar sind. Das lohnt sich, direkt zu sagen, statt bei einer konkreten Rangfolge falsche Sicherheit vorzutäuschen. Eine Roadmap, die jede Einstufung mit identischer Sicherheit präsentiert, lädt einen Stakeholder ein, bei einem knappen Fall so hart zu drängen, als wäre er eine feste Entscheidung, während der ehrlichere und letztlich überzeugendere Schritt ist, ihn von Anfang an als knappen Fall zu benennen.
Tipp
Bitte Claude, zu markieren, welche Einstufungen knapp sind gegenüber eindeutigen. Eine Roadmap, die ehrlich über ihre knappen Fälle ist, wirkt glaubwürdiger als eine, die jede Einstufung mit derselben Sicherheit präsentiert.
Schau dir diese eingestufte Liste von 6 Features an, welche Paare liegen nah genug beieinander, dass die Reihenfolge vernünftigerweise kippen könnte? Sei konkret, was sich dafür ändern müsste.
”Bei einem wirklich knappen Paar lohnt es sich zu fragen, ob es einen praktischen Tiebreaker jenseits von Aufwand und Wirkung gibt, der es sicherer entscheiden würde, eine Abhängigkeit, eine saisonale Frist, eine schon gemachte Zusage an einen Kunden, statt die Roadmap auf einer willkürlichen Münzwurf-Reihenfolge sitzen zu lassen.
Diese zwei Features liegen bei Aufwand und Wirkung praktisch gleich. Gibt es einen praktischen Tiebreaker, eine Abhängigkeit zwischen ihnen, eine externe Frist, irgendetwas jenseits der Zahlen, das eines davon klar zur besseren Wahl machen würde, zuerst zu bauen?
”Weiterlesen
- Support-Tickets in priorisierte Themen verwandeln: wo die Wirkungsschätzungen, auf die sich eine Roadmap-Einstufung stützt, oft herkommen.
- Ein ausgeliefertes Feature in Release Notes und ein Stakeholder-Update verwandeln: was passiert, sobald ein Roadmap-Punkt tatsächlich ausgeliefert ist.
- Ein PRD aus einer Ein-Satz-Feature-Anfrage schreiben: einen Roadmap-Platz in eine Spezifikation verwandeln, sobald er priorisiert ist.