Die technische SaaS-Roadmap: 6 Monate Engineering verlässlich planen

Die meisten technischen SaaS-Roadmaps sind ab Monat zwei tot. Der Plan wird im Januar geschrieben, im Februar kommt die Realität, und im März ist das Dokument etwas, wofür sich Leute im Planungsmeeting entschuldigen. Wir sehen das in Kundenprojekten so oft, dass wir es als Standardergebnis betrachten, und es hat eine behebbare Ursache: Die typische Roadmap ist eine Wunschliste mit Terminen, gebaut ohne Kapazitätsmodell und ohne aufgeschriebene Annahmen.

Eine technische SaaS-Roadmap, die sechs Monate lang nützlich bleibt, ist ein anderes Artefakt. Sie startet bei Geschäftsergebnissen statt bei Feature-Wünschen und behandelt Engineering-Kapazität als Budget, das aufgehen muss. Was folgt, ist der Prozess, den wir mit Kunden nutzen, Vorlage inklusive.

Warum der Sechsmonatsplan meist stirbt

Das Fehlermuster ist immer gleich. Jemand sammelt Feature-Wünsche von Sales, Support und den Gründern. Die Liste wird nach Lautstärke sortiert, Termine werden angehängt, und das Ergebnis sieht aus wie ein Plan. Es ist eine Warteschlange. Eine Warteschlange kennt die Kapazität deines Teams nicht, und sie kann den Incident nicht abfedern, der drei Wochen eines Quartals frisst.

Das Dokument scheitert auch sozial. Wenn Engineering in Systemsprache (den Billing-Service migrieren, einen Message Broker einführen) vor Leuten präsentiert, die in Fähigkeiten denken, können Stakeholder nicht über Prioritäten diskutieren. Also diskutieren sie stattdessen über Termine, und in dieser Verhandlung stirbt das Vertrauen.

Eine technische SaaS-Roadmap bei Ergebnissen starten, nicht bei Features

Beginne mit den Unternehmens-OKRs oder dem, was in deiner Organisation als solche durchgeht. Wenn das Ziel für das Halbjahr lautet, den Churn um 20 Prozent zu senken, wird die Roadmap-Frage: Welche Engineering-Initiativen bewegen diese Zahl? Vielleicht Zuverlässigkeitsarbeit an den zwei Features, die deine intensivsten Nutzer täglich anfassen. Vielleicht Onboarding-Instrumentierung, weil gerade niemand sagen kann, wo Trial-Nutzer aufgeben. Diese Initiativen haben eine Daseinsberechtigung, die einer Prüfung standhält.

Wir führen das als Mapping-Übung durch. Jede Initiative zeigt auf ein Geschäftsergebnis, und auf jedes Ergebnis zeigt mindestens eine Initiative. Eine Initiative, die auf nichts zeigt, wird entweder gestrichen oder muss sich als Engineering-Gesundheit rechtfertigen, was eine legitime Kategorie mit eigenem festen Budget ist. Nach unserer Erfahrung streicht das Mapping etwa ein Drittel der ursprünglichen Wunschliste sofort, und genau das ist der Sinn.

Kapazitätsplanung: die Rechnung, die niemand machen will

Sechs Entwickler mal sechs Monate sind nicht 36 Personenmonate Feature-Arbeit. Bevor du dich auf irgendetwas festlegst, zieh ab:

• Incidents, Support-Eskalationen und dringende Kundenwünsche. Nimm den Prozentsatz aus deiner Incident-Historie, nicht aus Optimismus. Bei den meisten SaaS-Teams, die wir sehen, liegt er zwischen 15 und 20 Prozent.
• Ein festes Kontingent für technische Schulden und Wartung, typischerweise 20 Prozent. Lässt du das Kontingent weg, holt sich die Schuld es trotzdem, in Form von Verlangsamung und Feuerlöschen. Eine Codebase Health Scorecard sagt dir, ob 20 Prozent für deine Situation reichen.
• Einarbeitung neuer Mitarbeiter, die erst negativ ist, bevor sie positiv wird. Ein Entwickler, der in Monat zwei anfängt, kostet bis Monat vier Review-Zeit der Seniors und trägt frühestens ab Monat fünf voll bei. Eine Neueinstellung ab Tag eins mit voller Kapazität einzuplanen ist Fiktion.
• Der gewöhnliche Overhead aus Meetings, Reviews, Urlaub und Krankheit. Plane mit 75 Prozent der nominellen Zeit, bevor du irgendeinen der Abzüge oben anwendest.

Rechne das durch, und ein Sechspersonenteam hat ungefähr die Hälfte dieser 36 Personenmonate für geplante Initiativen verfügbar. Schreib diese Zahl oben auf die Roadmap. Jede Priorisierungsdiskussion wird kürzer, sobald sie sichtbar ist.

Wenn der Anteil für technische Schulden umstritten ist, und das ist er meistens, klärt ein externes Technical Debt Assessment die Zahl schneller als eine weitere Runde interner Debatte.

Initiativen sizen: S, M, L, XL

Wir sizen Roadmap-Einträge bewusst in T-Shirt-Größen. Story Points auf Roadmap-Ebene suggerieren eine Präzision, die es noch nicht gibt.

Größe	Kalenderrealität	Was es bedeutet
S	Tage bis 2 Wochen	Bekannte Arbeit in bekanntem Code, ein Entwickler
M	2 bis 6 Wochen	Einige Unbekannte, bis zu zwei Entwickler, keine Überraschungen im Datenmodell erwartet
L	6 bis 12 Wochen	Echte Unbekannte, teamübergreifende Berührungspunkte oder eine Live-Datenmigration
XL	Ein Quartal oder mehr	Zu groß zum Planen. Aufteilen, bevor es in die Roadmap kommt

Die Diskussion, ob etwas M oder L ist, ist der Ort, an dem der Planungswert steckt, also erzwingen wir sie mit einem festen Fragenkatalog. Berührt die Initiative Authentifizierung, Billing oder das zentrale Datenmodell? Dann ist sie mindestens M. Migriert sie Live-Daten? Mindestens L. Hängt sie davon ab, dass ein Drittanbieter zuerst etwas liefert? Eine Größe drauflegen und einen Eintrag im Risikoregister schreiben. Können zwei Personen die Akzeptanzkriterien nennen und dasselbe meinen? Wenn nicht, lässt sich die Initiative nicht sizen und geht zurück in die Definition.

Ein XL kommt nie am Stück in die Roadmap. Teile es in ein L, das etwas Beobachtbares liefert, und einen Folgeschritt, der gesized wird, sobald das L gelandet ist und dir etwas beigebracht hat.

Reihenfolge: weniger Abhängigkeiten schlagen frühere Starts

Vier Prinzipien, in der Reihenfolge, in der wir sie anwenden.

Plane die Initiativen mit echten Unbekannten früh im Halbjahr. Wer in Monat fünf entdeckt, dass ein L eigentlich ein XL war, hat keinen Raum mehr zu reagieren.

Ein Team, eine Initiative zur Zeit. Zwei halbfertige Initiativen sind weniger wert als eine ausgelieferte, und der Kontextwechsel belastet beide.

Halte zwei Initiativen, die dasselbe Subsystem berühren, aus demselben Zeitfenster heraus, auch über Teams hinweg. Merge-Konflikte sind der billige Teil dieser Kollision; die umstrittenen Designentscheidungen sind der teure Teil.

Lass Abhängigkeiten nach hinten zeigen. Wenn Initiative B die API aus Initiative A braucht, dann ist A fertig, bevor B startet, mit Puffer dazwischen, und die Zeile von B in der Roadmap benennt diese Abhängigkeit.

Wenn die Sequenzierung immer wieder Deadlocks produziert, egal wie du umsortierst, sagt dir die Architektur etwas über Kopplung. Dieses Gespräch führen wir in Tech-Stack-Strategie-Reviews, und dort ist es deutlich günstiger als in der Produktion.

Das Risikoregister: was diesen Plan ungültig machen könnte

Jede Roadmap steht auf Annahmen, also schreib sie daneben auf. Ein typisches Register aus unseren Projekten: Der Backend-Neuzugang fängt spätestens im März an, der Zahlungsanbieter liefert seine angekündigte API in Q2, das Zeitfenster für das SOC-2-Audit verschiebt sich nicht, niemand aus dem vierköpfigen Kernteam geht in längere Abwesenheit. Notiere für jeden Eintrag, wie wahrscheinlich er bricht und welche Initiativen mit ihm fallen.

Dann preise das Risiko als Puffer ein. Wir halten 20 Prozent jedes Quartals unverplant. Wenn eine Annahme bricht, hat die Auswirkung einen Platz. Wenn nichts bricht, nimmt der Puffer die nächste Initiative vorzeitig auf, was zur Abwechslung ein angenehmes Review-Meeting ergibt. Der Puffer ist der Reaktionsplan für das Risikoregister, vereinbart, bevor irgendjemand unter Stress steht.

Fähigkeiten präsentieren, nicht Systeme

Die Version der Roadmap, die im Leadership-Meeting ankommt, enthält keine Subsystemnamen. Übersetze jede Zeile.

Systemsprache	Fähigkeitssprache
Billing auf die neue Provider-Abstraktion migrieren	Kunden können per Rechnung und Lastschrift zahlen, nicht nur per Karte
Read Replicas und Query Caching einführen	Dashboards bleiben beim Zehnfachen des heutigen Datenvolumens schnell
Das Berechtigungsmodul refactoren	Enterprise-Admins können eigene Rollen selbst definieren

Diese Übersetzung leistet echte Arbeit. Sie erlaubt nicht-technischen Stakeholdern, über Priorität zu diskutieren, was ihr Job ist, ohne über Implementierung zu diskutieren, was es nicht ist. Und wenn jemand mitten im Zyklus eine neue Fähigkeit anfragt, kannst du in derselben Sprache zeigen, was sie verdrängen würde.

Das monatliche Review, das die Roadmap aktuell hält

Ein Meeting, 45 Minuten, einmal im Monat, gleiche Agenda. Vergleiche Ausgeliefertes mit Geplantem. Geh das Risikoregister durch und markiere jede Annahme als gehalten oder gebrochen. Size den Rest neu, wenn sich die Realität bewegt hat. Halte fest, welcher Scope von außerhalb der Roadmap hereingekommen ist, denn irgendetwas kommt immer. Das Ergebnis ist ein kurzer Diff gegenüber dem Vormonat, kein neues Dokument.

Versioniere die Roadmap wie Code. Der Januarplan sollte unter den Märzrevisionen lesbar bleiben, denn die Diff-Historie ist die ehrliche Aufzeichnung, wie das Halbjahr gelaufen ist, und sie ist der beste Input, den du für die Planung des nächsten haben wirst.

Zwei Fehlermodi sind es wert, benannt zu werden. Wenn das Review zum Statusmeeting wird, verlege Statusupdates in Schriftform und behalte das Meeting für Entscheidungen. Wenn das Review nie etwas ändert, wird die Roadmap zwischen den Meetings nicht benutzt; ein Plan, der vier Monate ohne eine einzige Revision übersteht, war zu vage geschrieben, um falsch zu sein.

Die einseitige Vorlage, die wir mit Kunden nutzen

Eine Tabelle, eine Zeile pro Initiative.

Spalte	Was hineingehört
Initiative	Name, formuliert in Fähigkeitssprache
Ergebnis	Das Geschäftsziel oder OKR, das sie bewegt
Größe	S, M oder L. XL heißt: erst aufteilen
Zeitfenster	Ein Zielmonatsbereich, nie ein Datum
Owner	Ein Name, kein Teamname
Hängt ab von	Einträge im Risikoregister und andere Initiativen
Status	Geplant, aktiv, ausgeliefert oder verworfen

Unter der Tabelle stehen die Kapazitätszahl, der Puffer und das Risikoregister. Alles passt auf eine Seite. Eine Roadmap, die ein Foliendeck braucht, wird nicht monatlich aktualisiert, und eine Roadmap, die nicht aktualisiert wird, ist ein historisches Dokument.

FAQ

Wie weit voraus sollte eine technische SaaS-Roadmap reichen?

Sechs Monate auf Initiativenebene, zwölf Monate in Themen. Alles darüber hinaus ist eine Richtung, und so zu tun, als wäre es mehr, kostet Glaubwürdigkeit. Das monatliche Review schärft das ferne Ende, je näher es rückt.

Wie viel Puffer braucht der Plan?

Unser Standard sind 20 Prozent pro Quartal, nach oben angepasst für Teams mit hoher Incident-Last oder einem Audit im Kalender. Teams, die regelmäßig mit ungenutztem Puffer abschließen, können ihn kürzen, wobei solche Teams nach unserer Erfahrung selten sind.

Was ist der Unterschied zwischen Roadmap und Backlog?

Das Backlog ist alles, was du tun könntest. Die Roadmap ist die Teilmenge, für die das Team in diesem Halbjahr Kapazität hat, an Ergebnisse gebunden, gesized und in Reihenfolge gebracht. Wenn die beiden Dokumente ähnlich aussehen, hat der Roadmap-Schritt nicht wirklich stattgefunden.

Wenn du ein zweites Paar Augen für deinen nächsten Planungszyklus willst, von der Kapazitätsrechnung bis zur Zahl für technische Schulden, von der sie abhängt, schreib an hello@wolf-tech.io mit einer kurzen Notiz, wo die Planung wehtut. Mehr darüber, wie wir arbeiten, findest du auf wolf-tech.io.