AI Product Lifecycle
Context
Abschnitt betitelt „Context“Dein AI-Feature ist live. Die Zusammenfassungs-Funktion funktioniert, die Metriken sehen gut aus, das Team feiert den Launch. Drei Monate später: Die Qualität sinkt. Nutzer beschweren sich über schlechte Zusammenfassungen. Was ist passiert?
Niemand hat etwas geaendert — und genau das ist das Problem. Der Model Provider hat ein Update ausgerollt. Die Kundenanfragen haben sich verändert (neues Produktrelease). Die Wissensdatenbank ist veraltet. In der traditionellen Softwareentwicklung heisst “nichts ändern” Stabilitaet. Bei AI-Produkten heisst “nichts ändern” Qualitaetsverlust.
Concept
Abschnitt betitelt „Concept“Der AI Product Lifecycle ist nicht linear
Abschnitt betitelt „Der AI Product Lifecycle ist nicht linear“
Traditionell: Discovery, Design, Build, Launch, Maintain AI: Discovery, Prototype, Evaluate, Build, Launch, Monitor, Re-evaluate, Improve, (Repeat)
Der entscheidende Unterschied: AI-Produkte erreichen nie eine stabile Maintenance-Phase. Modelle driften, Nutzerverhalten ändert sich, die Welt ändert sich, Wettbewerber verbessern sich. Ein AI-Produkt, das nicht aktiv verbessert wird, degradiert aktiv.
Die vier Phasen
Abschnitt betitelt „Die vier Phasen“Phase 1: Exploration & Prototyping (Wochen)
- Ziel: Validieren, dass AI das Problem in akzeptabler Qualität loesen kann
- Aktivitaeten: Prompt-Experimente, Modellvergleiche, Quick Prototypes
- PM-Rolle: Problem klar genug definieren, um einen Prototyp bewertbar zu machen
- Haeufiger Fehler: Diese Phase ueberspringen und sich nach einer Demo zum Full Build commiten
Phase 2: Evaluation & Hardening (Wochen bis Monate)
- Ziel: Robuste Eval-Infrastruktur aufbauen und Quality Baselines setzen
- Aktivitaeten: Eval Datasets erstellen, automatisierte Eval Pipelines, Human Evaluations
- PM-Rolle: Definieren was “gut genug” für Nutzer bedeutet
- Haeufiger Fehler: Ohne Eval-Infrastruktur launchen — “wir messen Qualität später”
Phase 3: Production & Scaling (Monate)
- Ziel: An Nutzer ausliefern und realen Traffic verarbeiten
- PM-Rolle: Quality Metrics monitoren, User Feedback managen, Verbesserungen priorisieren
- Haeufiger Fehler: Launch als Ziellinie behandeln statt als Startlinie
Phase 4: Continuous Improvement (fortlaufend)
- Ziel: Qualität aufrechterhalten und verbessern
- Aktivitaeten: Model Updates, Prompt Refinement, Eval Dataset-Erweiterung
- PM-Rolle: Improvement-Arbeit gegen neue Features priorisieren
- Haeufiger Fehler: Nach Launch nicht mehr investieren und Qualität degradieren lassen
Model Versioning & Migration
Abschnitt betitelt „Model Versioning & Migration“Wenn Anthropic Claude aktualisiert, wenn OpenAI ein neues GPT veroeffentlicht — ändert sich das Verhalten Deines Produkts. Manchmal dramatisch.
Best Practices:
- Produktionsmodelle nie automatisch upgraden — immer auf spezifische Versionen pinnen
- Eval Suite auf neuem Modell laufen lassen, bevor migriert wird
- Prompt-Anpassungen einplanen — optimierte Prompts für Modell A funktionieren anders auf Modell B
- Rollback ermoeglichen — alte Konfiguration mindestens 2 Wochen nach Migration deploybar halten
Die Upgrade-Falle: Ein neues Modell kann auf allgemeinen Benchmarks besser abschneiden, aber auf Deinem spezifischen Use Case schlechter performen. Immer auf DEINEM Eval-Dataset evaluieren.
Drei Ebenen des Monitorings
Abschnitt betitelt „Drei Ebenen des Monitorings“| Ebene | Was wird gemessen | Beispiele |
|---|---|---|
| Infrastructure | Standard-Betrieb | Uptime, Error Rates, Latency, Throughput |
| Quality (AI-spezifisch) | Output-Qualität | Sample Evaluations, Thumbs up/down Rate, Edit Distance, Drift Detection |
| Business Impact | Geschaeftswirkung | Adoption Trends, Task Completion, Cost-per-Query, Revenue Attribution |
Ein Modell kann online und innerhalb der SLA sein, waehrend es schreckliche Outputs produziert. Quality Monitoring ist nicht optional.
Framework
Abschnitt betitelt „Framework“Prioritaeten für Post-Launch Arbeit:
| Priorität | Trigger | Aktion |
|---|---|---|
| URGENT | Quality Regression (Metriken unter Launch-Schwellenwerten) | Sofort fixen |
| HIGH | Model Provider Deprecation Notice | Migration mit Eval-Zyklus planen |
| MEDIUM | Graduelle Qualitaetsdrift (Metriken sinken langsam) | Improvement Sprint einplanen |
| LOW | Neues Modell mit besseren Benchmarks verfügbar | Evaluieren wenn aktuelle Performance nicht reicht |
Immer: Eval-Infrastruktur als erstklassiges Produkt-Concern behandeln.
Scenario
Abschnitt betitelt „Scenario“Du bist PM eines AI-Schreibassistenten. Vor 4 Monaten habt ihr gelauncht. Die Situation heute:
- Acceptance Rate (Nutzer übernehmen AI-Vorschlag): von 68% bei Launch auf 54% gefallen
- Regeneration Rate (Nutzer klicken “Neu generieren”): von 12% auf 23% gestiegen
- Latency: unveraendert bei P95 von 2,1 Sekunden
- Kosten: $2.800/Monat, im Budget
- Modell: Ihr nutzt immer noch die gleiche Version
- Wissens-Update: Die interne Style-Guide-Datenbank wurde seit Launch nicht aktualisiert
- Euer CEO fragt: “Sollen wir auf das neueste Modell upgraden? Das ist doch bestimmt besser.”
Die Infrastruktur-Metriken sind alle gruen. Aber die Qualität degradiert offensichtlich.
Wie wuerdest Du entscheiden?
Die beste Entscheidung: Nicht sofort auf ein neues Modell upgraden. Zuerst die Ursache der Qualitaetsdrift diagnostizieren.
Konkrete Schritte:
- Style-Guide-Datenbank aktualisieren. Die wahrscheinlichste Ursache: Veralteter Context fuehrt zu Outputs, die nicht mehr zum aktuellen Stil passen
- Sample-Analyse der Regenerations: Die 23% Regenerations-Faelle analysieren — gibt es Muster? Bestimmte Texttypen? Bestimmte Nutzergruppen?
- Erst dann Modell-Upgrade evaluieren — auf dem eigenen Eval-Dataset, nicht auf allgemeinen Benchmarks
Warum nicht sofort upgraden:
- Ein Modell-Upgrade ändert das Verhalten ueberall — auch dort, wo es gut funktioniert
- Wenn die Ursache veralteter Context ist, hilft ein neues Modell nicht
- Upgrade ohne Diagnose ist Symptombehandlung
Was viele falsch machen: Bei Qualitaetsproblemen reflexartig auf das neueste Modell upgraden, ohne die eigentliche Ursache zu verstehen. Oft ist es der Context, nicht das Modell.
Reflect
Abschnitt betitelt „Reflect“AI-Produkte haben keinen stabilen Endzustand — der Launch ist die Startlinie, nicht die Ziellinie.
- Model Drift, Data Drift und sich aendernde Nutzererwartungen erfordern kontinuierliche Arbeit
- Quality Monitoring ist getrennt von Infrastructure Monitoring — ein System kann online sein und trotzdem schlechte Outputs liefern
- Model Upgrades sind keine kostenlosen Verbesserungen — jedes Upgrade braucht Evaluation auf dem eigenen Dataset
Quellen: Anthropic Documentation — Model Cards & Migration Guides (2025), Stripe Engineering Blog — ML System Lifecycle, Chip Huyen “Designing Machine Learning Systems” (O’Reilly, 2022)