Synthese: Execution
The Big Picture
Abschnitt betitelt „The Big Picture“Du hast fuenf Lektionen durchgearbeitet: wie man AI PRDs mit Eval-Kriterien schreibt, warum AI-Produkte einen kontinuierlichen Lifecycle haben, wie cross-funktionale Teams bei AI zusammenarbeiten, warum Datenqualitaet Produktqualitaet ist, und wie Agile für AI-Entwicklung angepasst werden muss.
Einzeln sind das Werkzeuge für verschiedene Aspekte der Execution. Zusammen ergeben sie ein Execution-Modell, das auf einer zentralen Erkenntnis basiert: AI Product Execution ist Uncertainty Management. Traditionelle Produktentwicklung minimiert Unsicherheit durch Upfront-Spezifikation. AI-Produktentwicklung akzeptiert Unsicherheit und managt sie durch kontinuierliche Evaluation und schnelle Iteration.
Connections
Abschnitt betitelt „Connections“1. Von PRDs zu Lifecycle — Evaluation als roter Faden
Abschnitt betitelt „1. Von PRDs zu Lifecycle — Evaluation als roter Faden“AI PRDs definieren Eval-Kriterien (Lektion 1). Der Lifecycle nutzt diese Kriterien als Baseline für Monitoring und Verbesserung (Lektion 2). Ohne definierte Schwellenwerte weisst Du beim Launch nicht, ob die Qualität reicht — und nach dem Launch nicht, ob sie sinkt.
Für Dich als PM: Die Eval-Kriterien aus dem PRD sind nicht nur ein Launch-Gate. Sie sind das Fundament für den gesamten Lifecycle.
2. Von Cross-Functional zu Agile — Rituale verbinden Rollen und Prozesse
Abschnitt betitelt „2. Von Cross-Functional zu Agile — Rituale verbinden Rollen und Prozesse“Das Eval Review Ritual (Lektion 3) ist die Bruecke zwischen cross-funktionaler Zusammenarbeit und dem Agile-Prozess (Lektion 5). Es gibt dem Dual-Track-Ansatz seinen Rhythmus: Experiment-Ergebnisse reviewen, Improvement Actions priorisieren, nächste Timeboxes definieren.
Für Dich als PM: Ein einziges strukturiertes Meeting pro Woche kann Ad-hoc-Alignment ersetzen und haelt beide Tracks synchron.
3. Von Data Quality zu PRDs — Daten als Spezifikation
Abschnitt betitelt „3. Von Data Quality zu PRDs — Daten als Spezifikation“Die Data Quality-Anforderungen (Lektion 4) gehören ins AI PRD (Lektion 1). Welche Knowledge-Base-Qualität wird erwartet? Wie oft werden Dokumente aktualisiert? Welche Data Governance Policies gelten? Diese Fragen gehören in die Spezifikation — nicht erst in die Retro nach dem Launch.
Für Dich als PM: Wenn Dein AI PRD keinen Abschnitt zur Datenqualitaet hat, ist es unvollstaendig.
4. Von Lifecycle zu Data Quality — Degradation hat zwei Ursachen
Abschnitt betitelt „4. Von Lifecycle zu Data Quality — Degradation hat zwei Ursachen“AI-Produkte degradieren (Lektion 2) entweder durch Model Drift oder durch Data Drift (Lektion 4). In der Praxis ist Data Drift die haeufigere Ursache — veraltete Wissensdatenbanken, neue Nutzeranfragen ausserhalb der Coverage, akkumulierte Widersprueche.
Für Dich als PM: Wenn Qualität sinkt, pruefe zuerst die Daten, dann das Modell.
5. Von Agile zu Cross-Functional — Experimente brauchen alle Perspektiven
Abschnitt betitelt „5. Von Agile zu Cross-Functional — Experimente brauchen alle Perspektiven“Experiment-Spikes (Lektion 5) produzieren nur dann verwertbare Ergebnisse, wenn alle Perspektiven eingebunden sind (Lektion 3). Ein ML-Engineer der alleine experimentiert, optimiert für technische Metriken. Ein PM der alleine evaluiert, uebersieht technische Constraints.
Für Dich als PM: Decision Gates nach Experiment-Spikes sollten PM, Tech Lead und (bei UX-relevanten Experimenten) Designer einbeziehen.
The Meta-Insight
Abschnitt betitelt „The Meta-Insight“AI Product Execution folgt einem Kreislauf: Spezifizieren (PRD) → Managen (Lifecycle) → Zusammenarbeiten (Cross-Functional) → Daten pflegen (Quality) → Prozess anpassen (Agile) → Wiederholen. Teams, die die beste Eval-Infrastruktur bauen, bauen die besten AI-Produkte.
Your Execution Checklist
Abschnitt betitelt „Your Execution Checklist“Was Du jetzt können solltest:
- Ein AI PRD mit Eval-Kriterien, Quality Thresholds und Failure Modes schreiben — Lektion 1
- Den AI Product Lifecycle von Exploration bis Continuous Improvement managen — Lektion 2
- Zwischen Researcher- und Product-Mindset uebersetzen und Eval Review Rituale etablieren — Lektion 3
- Data Quality als Produktanforderung definieren und Data Governance Fragen beantworten — Lektion 4
- Dual-Track-Entwicklung mit timeboxed Experimenten und Kill-Kriterien umsetzen — Lektion 5
- Qualitaetsdrift diagnostizieren: Ist es das Modell oder sind es die Daten? — Lektionen 2 + 4
Wenn Du bei einem Punkt unsicher bist, geh zurück zur entsprechenden Lektion. Execution ist die Bruecke zwischen Strategie und Ergebnis.
Weiter mit: AI Leadership
Abschnitt betitelt „Weiter mit: AI Leadership“Du lieferst AI-Features. Kapitel 9 zeigt, wie Du AI-Organisationen aufbaust und skalierst.
Self-Assessment
Abschnitt betitelt „Self-Assessment“Drei Szenarien, die mehrere Konzepte aus diesem Kapitel kombinieren. Ueberleg Dir Deine Antwort, bevor Du die Aufloesung oeffnest.
Szenario 1: Der Launch ohne Eval-Kriterien
Abschnitt betitelt „Szenario 1: Der Launch ohne Eval-Kriterien“Dein AI-Feature (ein interner Support-Bot) ist seit drei Monaten live. Nutzer beschweren sich über sinkende Antwortqualitaet, aber niemand kann quantifizieren, wie schlecht es wirklich ist — es gibt keine Baseline-Metriken vom Launch. Der VP Product will einen sofortigen Fix. Was schlägst Du vor?
Aufloesung
Hier fehlt die Verbindung zwischen PRD (Lektion 1) und Lifecycle (Lektion 2). Ohne Eval-Kriterien im PRD gibt es keine Baseline — Du weisst nicht, ob das Modell degradiert oder die Daten veraltet sind. Erster Schritt: Retroaktiv Eval-Kriterien definieren und eine Baseline messen. Zweiter Schritt: Data Quality prüfen (Lektion 4) — ist die Knowledge Base aktuell? Dritter Schritt: Ein Eval Review Ritual etablieren (Lektion 3), damit das Problem nicht wieder unbemerkt bleibt. Der sofortige Fix ohne Diagnose wäre blinder Aktionismus.
Szenario 2: Der Solo-Experiment-Sprint
Abschnitt betitelt „Szenario 2: Der Solo-Experiment-Sprint“Dein ML-Engineer hat in einem zweiwöchigen Experiment-Spike drei Prompt-Varianten getestet und will die mit der hoechsten Accuracy deployen. Die UX-Designerin wurde nicht einbezogen, weil “es nur um Prompts geht”. Der Engineer praesentiert beeindruckende technische Metriken. Stimmst Du dem Deploy zu?
Aufloesung
Dieses Szenario verbindet Agile für AI (Lektion 5) mit Cross-Functional Collaboration (Lektion 3). Experiment-Spikes brauchen alle Perspektiven — technische Accuracy allein sagt nichts über User Experience. Die Prompt-Variante mit der hoechsten Accuracy könnte die laengsten, unlesbarsten Antworten produzieren. Als PM solltest Du ein Decision Gate einberufen mit PM, Tech Lead und Designer. Erst wenn auch User-facing Metriken (Response Clarity, Task Completion) geprueft sind, wird deployed. Das verlangsamt den Deploy um Tage, verhindert aber einen Rollback nach Wochen.
Szenario 3: Die veraltete Knowledge Base
Abschnitt betitelt „Szenario 3: Die veraltete Knowledge Base“Dein AI-Produkt beantwortet Kundenfragen zu Versicherungspolicen. Die Knowledge Base wurde seit sechs Monaten nicht aktualisiert, aber es gab in dieser Zeit drei Policy-Aenderungen. Dein Data-Team sagt, sie haetten keine Kapazitaet für Updates. Die Hallucination Rate steigt messbar. Was priorisierst Du?
Aufloesung
Hier treffen Data Quality (Lektion 4) und Lifecycle Management (Lektion 2) aufeinander. Steigende Hallucination Rate bei unveraendertem Modell ist ein klares Signal für Data Drift — die Realität hat sich weiterentwickelt, die Daten nicht. Das gehört ins AI PRD als Anforderung (Lektion 1): Wie oft müssen Dokumente aktualisiert werden? Die Priorität ist eindeutig: Knowledge-Base-Update vor jedem Feature-Work. Ein AI-Produkt, das veraltete Informationen als Fakten praesentiert, zerstoert Vertrauen schneller als fehlende Features.
Quellen: Aufbauend auf Lektionen 1–5. Anthropic Documentation (2025), Google Cloud Engineering Blog, Spotify Engineering Blog, LangChain Community Reports