Roadmap ohne Ballast: wie du entscheidest, was als Nächstes kommt

Was eine Roadmap wirklich ist

Viele Teams behandeln ihre Roadmap wie einen Lieferplan: eine Liste von Features mit Datum daneben, abgehakt von oben nach unten. Das fühlt sich ordentlich an und geht trotzdem fast immer schief. Eine Roadmap, die Termine verspricht, wird zur Schuldenliste, sobald sich die Welt verändert, und sie verändert sich immer.

Nützlicher ist ein anderes Bild. Eine Roadmap gibt Richtung, kein Versprechen. Sie sagt, welche Probleme du in den nächsten Monaten lösen willst und in welcher Reihenfolge, ohne dich auf den exakten Tag und den exakten Funktionsumfang festzunageln. Damit bleibt sie ein Werkzeug zum Entscheiden statt eine Bühne, auf der du dich später rechtfertigen musst. Der Rest dieses Artikels handelt davon, wie du diese Reihenfolge findest, ohne dich auf das Bauchgefühl zu verlassen.

Wert gegen Aufwand: die Achse, die fast alles erklärt

Die schlichteste Frage, die überraschend weit trägt, lautet: Was bringt das, und was kostet es. Wert auf die eine Achse, Aufwand auf die andere, und schon sortiert sich vieles von allein.

Wert heisst dabei nicht nur Umsatz. Eine Funktion kann wertvoll sein, weil sie Nutzer hält, die sonst kündigen würden. Weil sie den Support entlastet, der jede Woche dieselbe Frage beantwortet. Weil sie eine ganze Zielgruppe erst zugänglich macht. Aufwand wiederum ist mehr als Entwicklungszeit. Eine Zahlungsintegration kostet dich nicht nur die Implementierung, sondern auch Compliance, Fehlerbehandlung und Betrieb auf Jahre. Wer nur die Tage bis zum ersten Release zählt, unterschätzt fast jede Funktion, die nach dem Launch noch lebt. Wir haben darüber an anderer Stelle geschrieben, warum Software nach dem Launch oft teurer wird als gedacht.

Vier Felder ergeben sich daraus. Hoher Wert bei niedrigem Aufwand: sofort machen. Hoher Wert bei hohem Aufwand: die grossen Wetten, gut überlegen, vielleicht in Etappen schneiden. Niedriger Wert bei niedrigem Aufwand: nebenbei, wenn Zeit ist. Niedriger Wert bei hohem Aufwand: streichen, ohne schlechtes Gewissen. Das letzte Feld ist das wichtigste, weil dort der meiste Ballast liegt, getarnt als gute Idee.

Die Achse ist kein Taschenrechner. Du wirst Wert und Aufwand selten exakt kennen, und das ist in Ordnung. Es geht nicht um die dritte Nachkommastelle, sondern darum, ein Gespräch zu strukturieren. Wenn zwei Leute eine Funktion völlig verschieden einordnen, hast du etwas Wichtiges gelernt, noch bevor eine Zeile Code geschrieben ist.

Das Problem vor die Lösung setzen

Die meisten Roadmap-Einträge sind in Wahrheit schon Lösungen. Wir brauchen ein Dashboard, Lass uns eine App bauen, Da fehlt ein Export. Das Problem dahinter bleibt ungesagt, und genau dort beginnt der Ärger.

Frag bei jedem Eintrag zurück: Welches Problem löst das, und für wen. Wenn die Antwort lautet die Geschäftsführung will es so sehen, ist das ein anderes Problem als drei Kunden haben letzte Woche danach gefragt. Oft stellst du fest, dass dieselbe Lösung mehrere Probleme adressieren soll, schlecht. Oder dass das echte Problem mit einem Drittel des Aufwands lösbar wäre, wenn man es nur benennen würde. Ein Kunde, der nach einem Export fragt, will vielleicht bloss eine Zahl wöchentlich in sein eigenes Reporting bekommen. Ein kleiner automatischer Versand löst das besser als ein grosses Export-Modul, das niemand bedient.

Wir bauen mit Wortfreunde und Reazon eigene Produkte und betreiben sie selbst. Das verändert, wie wir auf solche Einträge schauen. Wer eine Funktion nicht nur baut, sondern jahrelang wartet, überlegt zweimal, ob die teure Lösung wirklich das Problem trifft oder nur ein Symptom. Diese Betreiber-Perspektive ist der Grund, warum wir lieber lange über das Problem reden, bevor wir über die Umsetzung sprechen. Welche Funktion überhaupt den Kern eines Produkts bildet, ist eine eigene Frage, die wir in erste Funktion und Produktkern finden ausführlicher behandeln.

Wenige Wetten statt langer Wunschliste

Eine Roadmap mit dreissig Einträgen ist keine Roadmap, sondern ein Ablagefach. Sie beruhigt, weil nichts vergessen wird, und sie lähmt, weil alles gleich dringend aussieht.

Besser ist eine kurze Liste echter Wetten. Eine Wette ist eine Entscheidung unter Unsicherheit: Du glaubst, dass ein bestimmtes Problem gelöst gehört, und du setzt Zeit und Geld darauf, ohne den Ausgang zu kennen. Drei bis fünf solcher Wetten pro Quartal sind für die meisten Teams genug. Wer alles gleichzeitig will, baut von allem die halbe Hälfte und liefert nichts fertig aus.

Der Vorteil weniger Wetten ist nicht nur Fokus. Eine kurze Liste zwingt zur Entscheidung. Sobald nur fünf Plätze frei sind, musst du begründen, warum dieser eine Eintrag einen davon bekommt und ein anderer nicht. Diese Begründung ist das eigentliche Produkt der Priorisierung, viel mehr als die sortierte Liste selbst. Alles, was es nicht auf die Liste schafft, landet nicht im Mülleimer, sondern in einem Backlog, das du beim nächsten Mal wieder durchgehst. Manches wird dann plötzlich wichtig, weil sich die Lage geändert hat. Vieles stirbt still, weil es nie wirklich gebraucht wurde.

Wetten haben noch eine angenehme Eigenschaft: Sie dürfen verlieren. Wenn du etwas baust und es funktioniert nicht wie gedacht, war es kein Versagen, sondern ein Ergebnis. Eine Lieferliste kennt nur erledigt oder offen. Eine Wettenliste kennt auch ausprobiert, hat nicht getragen, weiter. Das ist eine gesündere Art, mit einem Produkt umzugehen, das noch wächst.

Wenn Priorisierung der falsche Hebel ist

Nicht jedes Problem löst sich durch besseres Sortieren. Manchmal ist die Roadmap nicht zu lang, sondern das Team zu klein für jede sinnvolle Reihenfolge. Dann hilft kein Framework, sondern eine Entscheidung über Ressourcen oder über den Zuschnitt des Produkts.

Es gibt auch eine Phase, in der eine Roadmap schlicht verfrüht ist. Wenn du noch gar nicht weisst, ob jemand dein Produkt überhaupt will, brauchst du keine priorisierte Liste von Features, sondern ein kleines, lauffähiges Etwas, an dem du das herausfindest. In dieser frühen Lage ist die wichtigste Entscheidung nicht was kommt als Nächstes, sondern was ist das Kleinste, das die Annahme prüft. Wer hier schon quartalsweise plant, plant ins Blaue. Was so ein erstes lauffähiges Produkt kostet und wovon das abhängt, haben wir in was ein MVP kostet aufgeschlüsselt.

Und manchmal ist das Problem politisch, nicht technisch. Wenn drei Abteilungen je ihre Lieblingsfunktion oben sehen wollen, löst keine Wert-Aufwand-Matrix den Konflikt. Sie macht ihn nur sichtbar. Das ist schon viel wert, ersetzt aber nicht das Gespräch darüber, welches Ziel das Produkt insgesamt verfolgt. Eine Roadmap kann diese Diskussion strukturieren. Führen musst du sie selbst.

Der häufigste Einwand: aber unsere Kunden fordern doch alles

Der Satz fällt fast immer: Wir können nicht priorisieren, der Kunde will alles, und zwar sofort. Das stimmt selten so absolut, wie es klingt. Was Kunden fordern, ist eine Quelle, kein Befehl. Zehn Anfragen nach demselben Problem sind ein starkes Signal. Eine laute Einzelstimme ist es nicht, auch wenn sie der grösste Account ist.

Der Trick liegt darin, Forderungen auf Probleme zurückzuübersetzen und dann zu zählen, wer dasselbe Problem hat. Plötzlich schrumpft die Liste, weil fünf verschiedene Feature-Wünsche dasselbe wunde Thema umkreisen. Eine gut gewählte Wette bedient dann mehrere Kunden auf einmal, statt jedem einzeln hinterherzubauen. Das ist kein Trick gegen Kunden, sondern für sie. Ein Produkt, das jeder Stimme folgt, wird beliebig und am Ende für niemanden mehr richtig gut.

So bleibt die Liste lebendig

Priorisierung ist keine Sitzung, die du einmal abhältst, sondern eine Gewohnheit. Die Lage ändert sich, neue Probleme tauchen auf, alte Wetten gehen auf oder eben nicht. Eine Roadmap, die ein halbes Jahr unverändert bleibt, ist entweder ein Wunder oder, viel wahrscheinlicher, niemand schaut mehr drauf.

Praktisch heisst das: ein fester Rhythmus, in dem du die kurze Liste neu sortierst. Jeden Eintrag noch einmal gegen Wert und Aufwand halten, das echte Problem dahinter prüfen, und konsequent abräumen, was sich überlebt hat. Dabei hilft, die Begründungen festzuhalten, nicht nur die Entscheidungen. Wenn du in drei Monaten nicht mehr weisst, warum eine Wette oben stand, kannst du auch nicht beurteilen, ob sie sich gelohnt hat.

Wenn ihr an dem Punkt seid, an dem die Roadmap steht und es ums Bauen und Betreiben geht, lohnt sich ein Blick auf unsere SaaS-Produktentwicklung. Wir bringen die Betreiber-Sicht von Anfang an mit, weil wir unsere eigenen Produkte über Jahre selbst am Laufen halten. Eine Roadmap ohne Ballast entsteht nicht durch ein cleveres Werkzeug, sondern durch die Bereitschaft, wenige Dinge bewusst zu wählen und vieles bewusst liegen zu lassen. Wert gegen Aufwand, Problem vor Lösung, wenige Wetten statt langer Wunschliste. Mehr braucht es nicht, und weniger genügt nicht.