PM, Data Scientist, ML Engineer: Wer macht was im KI-Produktteam?
Marc GasserSerial Founder · GTM & MarketingVerbindet AI mit Revenue-Operations und baut autonome GTM-Systeme für vorhersehbares Wachstum.TL;DR
- Die teuersten KI-Team-Fehler sind Strukturfehler: Data Science als interner Dienstleister («Ticket rein, Modell raus»), Engineering als Integrations-Feuerwehr, PM als Übersetzer ohne Mandat. Empowered Teams im Sinne Cagans heissen bei KI: Das Trio wird zum Quartett – PM, Design, Engineering, Data.
- Zwei Fragen entscheiden über Lieferfähigkeit: Wer setzt die Qualitätsschwelle? (Produkt – aus Nutzersicht.) Wer entscheidet den Launch? (Produkt – auf Basis der Eval-Daten von Data Science und der Betriebs-Daten von Engineering.) Wo diese Fragen offen sind, entstehen Endlosschleifen.
- In europäischen Tech-Hubs ist das verbreitetste funktionierende Muster: zentrale ML-Plattform für Infrastruktur und Standards, eingebettete Data-Rollen in den Produktteams. Reine Zentralisierung erzeugt Warteschlangen, reine Dezentralisierung erzeugt Wildwuchs.
Kernaussagen
- Foundation-Modelle verschieben die Rollen: Weniger Teams trainieren selbst, mehr Teams orchestrieren – damit wandert ML-Kompetenz vom Spezialistenteam in die Breite, und AI-Literacy (seit Februar 2025 auch AI-Act-Pflicht) wird zur Teamfähigkeit statt zur Stellenbeschreibung.
- Der Unterschied zwischen Data Scientist und ML Engineer ist eine Produktionsgrenze: Der eine beweist, dass Qualität erreichbar ist, der andere, dass sie unter Last, Kosten und Latenz erreichbar bleibt. Teams, die beide Rollen in eine Person pressen, bekommen meist eines von beidem.
- Das unterschätzte Bindeglied ist Domänenwissen: Die besten Eval-Sets und Guardrails entstehen dort, wo Fachwissen dokumentiert und zugänglich ist – nicht in den Köpfen von zwei Veteranen.
Warum Übergaben KI-Features töten
Das Anti-Muster sieht überall gleich aus: Produkt schreibt eine Anforderung, Data Science baut monatelang ein Modell, Engineering soll es «nur noch integrieren» – und an jeder Übergabe geht Kontext verloren. Das Modell optimiert eine Metrik, die kein Nutzerproblem misst. Die Integration scheitert an Latenz und Kosten, die im Notebook nie auffielen. Und der PM erfährt zuletzt, dass «fertig» drei verschiedene Bedeutungen hatte.
Marty Cagans Antwort auf Übergabe-Organisationen gilt verschärft: Empowered Teams, die ein Problem besitzen statt Arbeitspakete zu tauschen. Für KI-Produkte heisst das, die Daten-Perspektive von Anfang an ins Team zu holen – als vierte Stimme im Trio, nicht als nachgelagerte Fachstelle. Wer beim Discovery-Interview sitzt, baut hinterher keine Metrik am Problem vorbei.
Die Rollenschnitte, die funktionieren
Product Manager. Besitzt das Problem, die Fehlertoleranz und die Qualitätsschwelle aus Nutzersicht – und entscheidet den Launch auf Basis der Evidenz der anderen. Der PM definiert nicht die Modellarchitektur, aber er definiert, was «gut genug» bedeutet und was ein Fehler kostet.
Data Scientist. Besitzt die Machbarkeits-Evidenz: Eval-Design, Experimente, Modell- oder Prompt-Wahl. Liefert keine Bauchgefühle, sondern Scores auf vereinbarten Testsets – und sagt ehrlich, wo die Qualitätsgrenze liegt.
ML / Software Engineer. Besitzt die Produktionsreife: Latenz, Kosten pro Anfrage, Skalierung, Guardrails, Fallbacks, Rollback. Verwandelt ein funktionierendes Experiment in ein betreibbares Feature – und hat ein Veto, wenn Betriebskosten den Business Case fressen.
Strukturell hat sich in europäischen Organisationen ein Hybrid bewährt: eine zentrale Plattform für gemeinsame Infrastruktur, Evaluation-Tooling und Compliance-Standards, kombiniert mit Daten-Rollen, die in Produktteams eingebettet arbeiten. Die Plattform verhindert, dass fünf Teams fünfmal dasselbe Logging bauen; die Einbettung verhindert die Warteschlange vor dem «KI-Team».
Der Rollen-Klarheits-Check für dein KI-Team
Klassisches Muster: Jeder optimiert sein Artefakt, niemand das Produkt. Kläre zuerst die zwei Launch-Fragen – wer setzt die Schwelle, wer entscheidet.
Hake an, was in deinem Team eindeutig geregelt ist – das Ergebnis zeigt, wo Verantwortung zwischen PM, Data Science und Engineering versickert.
Domänenwissen ist Team-Infrastruktur
Die unsichtbare vierte Rolle in jedem KI-Team ist das Domänenwissen: Welche Geschäftsregeln gelten, welche Ausnahmen existieren, warum eine Entscheidung 2023 so fiel. Eval-Sets, Guardrails und Prompts sind nur so gut wie dieses Wissen – und in den meisten Brownfield-Organisationen lebt es verteilt in Köpfen, Confluence-Ruinen und im Code selbst.
Deshalb ist Wissens-Infrastruktur eine Team-Entscheidung, keine Doku-Pflichtübung: Wenn Code, Tickets und Entscheidungen semantisch durchsuchbar sind, kann jede der drei Rollen ihre Fragen selbst beantworten – der Data Scientist findet die Geschäftsregel, der Engineer die Integrations-Historie, der PM die Begründung von damals. Das Team wird schneller, weil es weniger aufeinander warten muss.
Empfehlungen
- Beantworte die zwei Launch-Fragen schriftlich. Wer setzt die Qualitätsschwelle, wer entscheidet den Launch? Eine Zeile pro Feature in der Spec beendet die teuersten Endlosschleifen.
- Hole Data in die Discovery. Data Scientists sitzen in Kundeninterviews und Problem-Framing – nicht erst beim Modellbau. Machbarkeit ist ein Discovery-Risiko, kein Implementierungsdetail.
- Trenne Plattform von Produkt. Gemeinsames Eval-Tooling, Logging und Compliance zentral; Problem-Ownership eingebettet im Produktteam. So skaliert Qualität ohne Warteschlange.
- Investiere in durchsuchbares Wissen. Code, Entscheidungen und Tickets als gemeinsamer, semantischer Index – das ist die Infrastruktur, die alle drei Rollen gleichzeitig schneller macht.
Einordnung & Grenzen
- Rollenschnitte skalieren mit der Organisationsgrösse: In einem Zehn-Personen-Startup trägt eine Person zwei Hüte – entscheidend ist, dass die Verantwortungen explizit sind, nicht dass es drei Stellen gibt.
- Das Plattform-plus-Einbettung-Muster ist eine Praxis-Beobachtung aus europäischen Tech-Organisationen, keine kontrollierte Studie. Prüfe es gegen deine Teamgrösse und Compliance-Anforderungen statt es blind zu kopieren.
Fazit
KI-Produktteams scheitern nicht an fehlendem Talent, sondern an unklaren Besitzverhältnissen. Wer die zwei Launch-Fragen klärt, Data in die Discovery holt und Wissen durchsuchbar macht, verwandelt drei Disziplinen in ein Team – und Übergaben in Zusammenarbeit.
Passende Use Cases aus der Bibliothek
Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.
Kein neuer Beitrag ohne dich.
Neue Artikel, neue interaktive Tools, neue Evidenz – zuerst in deiner Inbox. Und wenn du antwortest, antworten wir: Du schreibst direkt mit den Autoren, nicht mit einem No-Reply.
Kein Spam, keine Weitergabe, jederzeit abmeldbar.