Standard-Retrospektiven wurden nicht für Produkte entwickelt, bei denen das Kernverhalten nicht deterministisch ist, die Kosten mit der Nutzung auf unvorhersehbare Weise skalieren und die sorgfältig abgestimmten Prompts des letzten Monats möglicherweise schlechter werden, weil der Modellanbieter ein Update bereitgestellt hat.
Wenn Sie mit LLMs bauen, benötigen Sie Retrospektiven, die den spezifischen Erfolg und Misserfolg von KI-Produkten berücksichtigen. Hier erfahren Sie, wie Sie dies tun können, ohne jede Retro-Retro in eine dreistündige Metriküberprüfung zu verwandeln.
Warum Ihr normales Retro-Format zu kurz kommt
Traditionelle Retrospektiven basieren auf einem vorhersehbaren Modell: Sie schreiben Code, Sie versenden ihn, er macht das, was Sie geschrieben haben. Bei den interessanten Problemen geht es um Prozesse, Kommunikation und Prioritäten.
KI-Produkte durchbrechen dieses Modell auf verschiedene Weise:
Die Ausgaben variieren zwischen identischen Eingaben. Dieselbe Prompt mit derselben Benutzernachricht kann bei verschiedenen Anrufen zu unterschiedlichen Qualitätsergebnissen führen. Das bedeutet, dass „es funktioniert auf meinem Computer“ zu „es hat funktioniert, als ich es vor fünf Minuten getestet habe“ erweitert wird.
Fehlermodi sind neu. Halluzinationen, prompte Injektion, Bias-Verstärkung und Kontextfensterüberlauf lassen sich nicht auf herkömmliche Fehlerkategorien übertragen. Ihr Team benötigt spezifisches Vokabular und Rahmenwerke, um diese zu besprechen.
Die Kosten sind nutzungsproportional und schwer vorherzusagen. Eine herkömmliche Funktion kostet genauso viel wie ihre Erstellung und läuft dann auf Ihrer vorhandenen Infrastruktur. Die Kosten einer LLM-Funktion steigen mit jeder Benutzerinteraktion, und ein viraler Moment kann Ihr Budget über Nacht sprengen.
Die Qualität nimmt unsichtbar ab. Eine Modellaktualisierung Ihres Anbieters kann die Ausgabequalität ohne Benachrichtigung geringfügig ändern. Ihre Prompts wurden für eine bestimmte Modellversion optimiert – diese Optimierung wird möglicherweise nicht übertragen.
Nichts davon bedeutet, dass Retrospektiven weniger wichtig sind. Das bedeutet, dass sie verschiedene Dinge betrachten müssen.
Die vier Linsen für KI-Produkt-Retros
Anstelle der klassischen Struktur „Was lief gut/was nicht/Maßnahmen“-Struktur, organisieren Sie Ihre KI-Produktrückblick nach vier unterschiedlichen Gesichtspunkten. Jedes Problem bringt eine andere Problemkategorie zum Vorschein.
Objektiv 1: Modellleistung
Hier geht es darum, ob die KI auf technischer Ebene ihren Job macht.
Fragen zur Diskussion:
- Wie entwickeln sich unsere Bewertungsergebnisse? Messen wir die richtigen Dinge?
- Sind uns Qualitätsverschiebungen aufgefallen, die mit Modellaktualisierungen oder zeitnahen Änderungen einhergehen?
- Was sind unsere schlimmsten Fehlerfälle aus dieser Zeit? Was haben sie gemeinsam?
- Gibt es Anwendungsfälle, bei denen das Modell ständig Schwierigkeiten hat und die wir anders angehen sollten?
Was Sie im Raum benötigen: Bewertungsergebnisse, Fehlerprotokolle, Beispiele für fehlerhafte Ausgaben, die Benutzer gemeldet oder von der Qualitätssicherung gemeldet wurden.
Linse 2: Schnelle technische Wirksamkeit
Prompts sind die Bedienoberfläche Ihres Produkts. Sie verdienen besondere Aufmerksamkeit.
Fragen zur Diskussion:
- Welche sofortigen Veränderungen führten tatsächlich zu besseren Ergebnissen, und welche waren Seitwärtsbewegungen?
- Verfolgen wir prompte Versionen systematisch oder geschieht dies ad hoc?
- Gibt es Prompts, die brüchig sind – sie funktionieren, brechen aber bei geringfügigen Eingabeschwankungen?
- Wie viel Zeit verbringen wir mit der schnellen Iteration im Vergleich zu anderen technischen Arbeiten? Stimmt dieses Verhältnis?
Was Sie im Raum benötigen: ein Protokoll zeitnaher Änderungen und deren gemessene Auswirkungen. Wenn Sie nicht über diese Möglichkeit verfügen, ist die Einrichtung dieses Tracking-Systems Ihr erster Schritt.
Linse 3: Benutzererfahrung
Das Modell funktioniert technisch möglicherweise gut, während die Benutzer immer noch frustriert sind.
Fragen zur Diskussion:
- Wie reagieren Benutzer auf KI-generierte Ausgaben? Was sagt das Feedback?
- Wo überschreiben, bearbeiten oder ignorieren Benutzer KI-Vorschläge? Das sind signalreiche Momente.
- Bietet die KI einen Mehrwert für Power-User, verwirrt aber neue Benutzer oder umgekehrt?
- Gibt es Vertrauensprobleme? Überprüfen Benutzer alles, was die KI produziert, oder vertrauen sie ihr zu sehr?
Was Sie im Raum benötigen: Benutzerfeedback, Nutzungsanalysen (insbesondere Drop-Off- und Bearbeitungsraten) und Support-Tickets im Zusammenhang mit KI-Funktionen.
Linse 4: Kosten und Nachhaltigkeit
Wenn Ihre KI-Funktionen wirtschaftlich nicht nachhaltig sind, spielen Qualität und UX keine Rolle.
Fragen zur Diskussion:
- Wie hoch sind unsere tatsächlichen Kosten pro Benutzerinteraktion für jede KI-Funktion?
- Wie skalieren die Kosten mit unseren Wachstumsprognosen? Ist es linear oder haben wir Kostenverstärker?
- Gibt es Möglichkeiten zur Kostensenkung ohne nennenswerte Auswirkungen auf die Qualität? (Caching, kürzere Prompts, kleinere Modelle für einfachere Aufgaben.)
- Erhalten wir einen Wert aus den Token, die wir ausgeben, oder senden wir aufgeblähte Prompts und Verarbeitungsausgaben, die wir nicht verwenden?
Was Sie im Raum brauchen: Abrechnungsdaten aufgeschlüsselt nach Funktion, Kosten-pro-Interaktionsberechnungen und Nutzungswachstumstrends.
Leitung des Meetings
Dauer: 60 Minuten. Sie können es mit 45 schaffen, wenn Ihr Team diszipliniert ist, aber versuchen Sie nicht, es auf 30 zu drängen.
Häufigkeit: Alle zwei Wochen, wenn Sie aktiv an KI-Funktionen iterieren. Monatlich, sobald sich die Lage stabilisiert. Führen Sie keinen Termin aus, nur weil er im Kalender steht, wenn sich nichts Wesentliches geändert hat.
Wer sollte dabei sein: Der Produktmanager, Ingenieure, die an KI-Funktionen arbeiten, und alle, die Modellausgaben oder Benutzerfeedback überprüfen. Sie brauchen nicht das ganze Unternehmen.
Format, das funktioniert:
Daten-Komplettlösung (10 Min.): Jemand stellt die wichtigsten Kennzahlen seit der letzten Retro vor. Noch keine Meinungen – nur die Zahlen. Dies verhindert, dass die lauteste Person im Raum das Gespräch auf ihre Anekdote konzentriert.
Diskussion über vier Linsen (35 Min.): Gehen Sie jede Linse durch. Sie müssen nicht für jeden die gleiche Zeit aufwenden – in manchen Zeiträumen sind die Kosten das große Thema; In anderen Fällen dominiert eine Qualitätsregression. Lassen Sie sich von den Daten leiten, wo Sie sich konzentrieren.
Maßnahmen (15 Min.): Seien Sie konkret. „Promptqualität verbessern“ ist kein Maßnahme. „Führen Sie den A/B-Test durch, indem Sie die aktuelle Zusammenfassungsaufforderung mit dem v7-Kandidaten vergleichen, ROUGE-Scores und Benutzerbearbeitungsraten messen und bei der nächsten Retro-Reportage Bericht erstatten“ ist ein Maßnahme.
Kennzahlen, die es wert sind, verfolgt zu werden (und einige, die es nicht sind)
Es besteht die Versuchung, ein ausgeklügeltes Dashboard zu erstellen, das Dutzende von KI-Metriken verfolgt. Widerstehen Sie ihm. Beginnen Sie mit einem kleinen Satz wirklich informativer Kennzahlen und fügen Sie nur dann weitere hinzu, wenn Sie eine bestimmte Frage beantworten müssen.
Hochwertige Metriken:
- Aufgabenerfolgsquote – Hat die KI erreicht, was der Benutzer verlangt hat? Dies ist die wichtigste Kennzahl und oft auch am schwierigsten zu messen. Sogar ein grober Proxy (wie „Benutzer hat die Ausgabe ohne Bearbeitung akzeptiert“) ist besser als nichts.
- Kosten pro erfolgreicher Interaktion – Nicht nur Kosten pro Anruf, sondern Kosten pro Ergebnis, das dem Benutzer tatsächlich geholfen hat. So können Sie sich auf den Wert und nicht nur auf das Volumen konzentrieren.
- Benutzerbearbeitungsrate – Wie oft ändern Benutzer KI-generierte Inhalte? Eine hohe Bearbeitungsrate ist nicht unbedingt schlecht (es könnte bedeuten, dass Benutzer sich aktiv engagieren), aber eine steigende Bearbeitungsrate deutet darauf hin, dass die Qualität nachlässt.
- Latenz bei p95 – Keine durchschnittliche Latenz, die die miserablen Erfahrungen verbirgt. Das 95. Perzentil sagt Ihnen, womit Ihre unglücklichsten, aber nicht extremsten Benutzer zu kämpfen haben.
Metriken, die nützlich erscheinen, es aber oft nicht sind:
- Roh-Token-Anzahl – Zeigt das Volumen an, nicht den Wert. Für die Abrechnung interessant, aber nicht für Produktentscheidungen.
- Eingabeaufforderungslänge – Länger ist nicht automatisch schlechter und kürzer ist nicht automatisch besser. Beurteilen Sie Prompts nach der Ausgabequalität und nicht nach der Länge.
- Modellversionsvergleiche im Alleingang – Der Vergleich von GPT-4o mit Claude 3.5 in abstrakten Benchmarks sagt Ihnen sehr wenig über Ihren spezifischen Anwendungsfall. Vergleichen Sie Ihre tatsächlichen Aufgaben ausschließlich mit Ihren tatsächlichen Bewertungskriterien.
Umgang mit schwierigen Gesprächen
Retros zu KI-Produkten bringen unangenehme Themen ans Licht, die Teams oft meiden:
„Wir wissen eigentlich nicht, ob die KI gut ist.“ Wenn Ihr Team nicht über eine systematische Methode zur Bewertung der Ausgabequalität verfügt, geben Sie es zu. Der Maßnahme besteht darin, auch nur ein minimales Bewertungsgerüst zu erstellen – eine Reihe von Testfällen mit erwarteten Ausgaben, die Sie nach jeder Änderung ausführen.
„Wir geben viel aus und sind uns nicht sicher, ob es sich lohnt.“ Dies ist eine Produktfrage, keine technische. Fördert die KI-Funktion die Kundenbindung, die Konvertierung oder ein anderes Geschäftsergebnis? Wenn Sie diese Grenze nicht ziehen können, entwickeln Sie möglicherweise KI-Funktionen, weil sie beeindruckend sind, und nicht, weil sie wertvoll sind.
„Das Modell macht manchmal etwas Problematisches und wir sind nicht sicher, wie wir es verhindern können.“ Machen Sie sich keine Gedanken über Sicherheitsprobleme. Wenn das Modell gelegentlich voreingenommene, schädliche oder irreführende Inhalte produziert, handelt es sich hierbei um eine Maßnahme mit höchster Priorität und nicht um ein „bekanntes Problem“, das Sie ablegen.
„Unsere schnelle Entwicklung fühlt sich wie eine Vermutung an.“ Das ist oft der Fall, besonders in der Anfangszeit. Die Retro ist ein guter Ort, um mehr Strenge einzuführen: Versionskontrolle für Prompts, A/B-Testprotokolle und explizite Bewertungskriterien.
Retro-Einblicke mit Produktentscheidungen verbinden
Der Zweck dieser Retrospektiven besteht nicht darin, eine Liste von Optimierungen zu erstellen. Es dient dazu, größere Produktentscheidungen zu treffen:
- Sollten wir mehr in diese KI-Funktion investieren oder ist das eine Sackgasse?
- Verwenden wir für diesen Anwendungsfall das richtige Modell oder sollten wir mit Alternativen experimentieren?
- Ist unser aktueller Ansatz skalierbar oder werden die Kosten unsere Margen bei 10x Nutzern verschlingen?
- Gibt es KI-Funktionen, die wir hinzufügen sollten, oder sollten wir uns intensiver darum bemühen, die vorhandenen Funktionen zuverlässig zu machen?
Wenn Ihre Retrospektive solche Entscheidungen nicht beeinflusst, handelt es sich lediglich um ein Statusmeeting im Retrospektiv-Klamottenstil.
Probieren Sie NextRetro kostenlos aus – Verwenden Sie das Vier-Linsen-Format mit speziellen Spalten für Modell, Prompts, UX und Kosten in Ihrer nächsten KI-Produkt-Retrospektive.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
