Produkt-Roadmap für KI-Funktionen: Planen unter Modellunsicherheit

Eine Produkt-Roadmap lebt von Zusagen: Im dritten Quartal kommt Funktion X. Bei KI-Funktionen wackelt diese Logik, denn eine Zusage über zwölf Monate setzt voraus, dass sich die Grundlagen in dieser Zeit nicht wesentlich verschieben. Genau das ist bei Sprachmodellen nicht gegeben. Fähigkeiten, Preise und Grenzen der Modelle ändern sich in Abständen von Monaten, und zwar von außen, ohne eigenes Zutun und ohne Rücksicht auf den eigenen Planungszyklus.

Daraus folgt nicht, dass Planung sinnlos wäre. Es folgt, dass eine KI-Roadmap anders gebaut werden muss als eine klassische: um Nutzerprobleme herum statt um Technologien, mit sortierten Abhängigkeiten vom Modellfortschritt und mit fest eingeplanten Momenten des Umplanens. Wer diese drei Prinzipien beachtet, kann auch unter Modellunsicherheit verbindlich wirken, ohne Zusagen zu machen, die in sechs Monaten niemand mehr halten kann.

Nutzerprobleme statt Technologieversprechen

Ein Roadmap-Eintrag wie Assistent mit Gedächtnis ist ein Technologieversprechen. Er legt fest, wie etwas gebaut wird, bevor klar ist, ob dieser Weg in einem Jahr noch der richtige ist. Besser ist die Formulierung als Nutzerproblem: Bestandskunden müssen ihre Vorgeschichte nicht bei jedem Kontakt wiederholen. Das Problem bleibt stabil, auch wenn sich der Lösungsweg dreimal ändert, und es lässt sich am Ende prüfen, ob es gelöst wurde.

Technologieversprechen veralten dagegen mit der Technologie. Was heute ambitioniert klingt, ist in einem Jahr trivial oder überholt, und die Roadmap hat sich öffentlich an ein Mittel gebunden statt an einen Zweck. Der Umbau ist meist reine Formulierungsarbeit: Jeder bestehende Eintrag wird gefragt, welches Nutzerproblem er eigentlich löst. Einträge, die darauf keine Antwort haben, verdienen ohnehin einen zweiten Blick, mit oder ohne KI.

Funktionen nach Modellabhängigkeit sortieren

Nicht jede KI-Funktion hängt gleich stark am Fortschritt der Modelle. Für die Planung hat sich eine Sortierung in drei Klassen bewährt:

• Heute machbar: Die Funktion lässt sich mit aktuellen Modellen zuverlässig umsetzen. Solche Einträge verhalten sich wie klassische Features und vertragen Termine.
• Am Rand des Machbaren: Die Funktion geht heute, aber nur mit Aufwand, Sonderbehandlung und Kompromissen. Jede neue Modellgeneration kann diesen Aufwand drastisch senken. Solche Einträge eignen sich für schmale Pilotversionen, nicht für den Vollausbau.
• Auf Fortschritt angewiesen: Die Funktion braucht Fähigkeiten, die aktuelle Modelle nicht verlässlich liefern. Solche Einträge gehören auf die Roadmap als beobachtete Wette mit klarem Auslöser, nicht als Termin.

Der Fehler liegt nicht darin, Einträge der dritten Klasse zu führen. Ambitionierte Wetten gehören zu einer ehrlichen Produktstrategie. Der Fehler liegt darin, sie mit Terminen aus der ersten Klasse zu versehen. Die Sortierung zwingt außerdem zu einer gesunden Frage bei jedem Eintrag der zweiten Klasse: Lohnt es sich, den heutigen Aufwand zu investieren, oder ist Warten die günstigere Entscheidung.

Neubewertungspunkte bewusst einplanen

Eine Roadmap unter Modellunsicherheit braucht feste Punkte, an denen sie gegen die veränderte Lage geprüft wird, etwa einmal pro Quartal. Drei Fragen genügen: Hat sich die Modelllandschaft für unser Produkt relevant verändert. Ist ein Eintrag vom Rand des Machbaren in das heute Machbare gerutscht. Und ist eine laufende Eigenentwicklung durch Modellfortschritt überflüssig geworden.

Die dritte Frage ist die unangenehmste und die wichtigste. Teams neigen dazu, ein halbfertiges Feature fertigzubauen, weil schon Arbeit darin steckt, auch wenn eine neue Modellfähigkeit denselben Zweck einfacher erfüllt. Ein fester Neubewertungspunkt macht den Abbruch zu einer normalen, vorgesehenen Entscheidung statt zu einem Gesichtsverlust. Ohne solche Punkte findet die Neubewertung trotzdem statt, nur ungeplant: ausgelöst durch eine Modellankündigung, mitten im Quartal, unter Druck.

Zeithorizonte kommunizieren ohne Detailzusagen

Stakeholder brauchen Verlässlichkeit, aber Verlässlichkeit heißt nicht Detailtiefe auf zwölf Monate. Bewährt hat sich eine Staffelung der Aussagen nach Horizont. Für die nächsten drei Monate: konkrete Funktionen mit Terminen, denn hier ist die Modelllage praktisch stabil. Für den Rest des Jahres: Problemfelder in einer Reihenfolge, ohne Termin je Funktion. Darüber hinaus: Richtungsaussagen, welche Probleme das Produkt langfristig lösen soll.

Diese Staffelung wirkt auf den ersten Blick wie ein Rückzug, ist aber das Gegenteil. Sie hält die Zusagen dort präzise, wo sie sich halten lassen, und ehrlich dort, wo niemand sie halten könnte. Eine einzige gebrochene Detailzusage kostet mehr Vertrauen als ein von Anfang an offen kommunizierter Korridor. Hilfreich ist, die Logik einmal explizit zu erklären: Wir planen in dieser Form, weil sich die Modellgrundlagen mehrmals im Jahr ändern, und wir versprechen lieber weniger und halten es.

Fazit

Eine Produkt-Roadmap für KI-Funktionen scheitert nicht an der Unsicherheit selbst, sondern an dem Versuch, sie mit klassischer Planungslogik zu überdecken. Tragfähig wird sie durch vier Verschiebungen: Einträge als Nutzerprobleme statt als Technologieversprechen, eine ehrliche Sortierung nach Abhängigkeit vom Modellfortschritt, fest eingeplante Neubewertungspunkte mit dem Mut zum Abbruch überholter Vorhaben und gestaffelte Zusagen, die mit dem Zeithorizont bewusst unschärfer werden. So bleibt die Roadmap ein Führungsinstrument statt einer Sammlung von Versprechen, an die sich in einem Jahr niemand mehr gebunden fühlen kann.