Ein KI-Coding-Assistent kann einen plausiblen ersten Entwurf erzeugen, bevor das Team festgelegt hat, was die Funktion leisten soll. Der Code kommt schnell. Die schwierigeren Fragen bleiben: Welcher Nutzer-Workflow verdient Aufmerksamkeit, was geschieht bei einer falschen Antwort, auf welche Daten darf das System zugreifen und woran erkennt jemand, ob das Release geholfen hat.
Hier bekommt die Entwicklerrolle in der KI eine stärkere Produktprägung. Der Ingenieur baut weiterhin das System, braucht jedoch genug Kunden- und Domänenkontext, um eine unklare Anfrage in eine begrenzte Fähigkeit mit belastbaren Nachweisen zu verwandeln.
KI macht Output im ersten Entwurf günstiger und erhöht damit den Wert von Produkturteil bei Kontext, Evaluation, Feedback und Geschäftsergebnissen. Für Teams, die diese Verbindung in einem realen Workflow benötigen, ist Forward-Deployed AI Engineering ein Delivery-Modell, das auf engem Kontakt zwischen Ingenieuren und Nutzern beruht.
Die Bezeichnung KI-Produktmanager kann dafür eine nützliche Kurzform sein. Sie beschreibt eine Mischung von Fähigkeiten und keinen vollständigen Berufswechsel. Produkt und Engineering bleiben getrennte Disziplinen mit wichtigen Verantwortlichkeiten auf beiden Seiten.
KI hat den Engpass verändert, Entwickler verantworten weiterhin das Ergebnis
KI-Werkzeuge können den Aufwand für Routinecode, Tests oder Interface-Entwürfe senken. Dadurch ist das Ergebnis noch nicht produktionsreif. Jemand muss weiterhin beurteilen, ob die Änderung zur Architektur passt, Berechtigungen korrekt behandelt, Grenzfälle übersteht und den Workflow verbessert, dem sie dienen soll.
Die Stimmung unter Entwicklern zeigt diese Lücke. In der Stack Overflow Developer Survey 2025 gaben 46 % der Befragten an, der Genauigkeit von KI-Werkzeugen zu misstrauen, gegenüber 33 %, die ihr vertrauten. Fast richtige Vorschläge frustrierten 66 %, und 45 % nannten die Zeit für das Debugging von KI-generiertem Code. Die Umfrage beruht auf Selbstselektion, daher sind die Werte keine Bevölkerungsschätzungen. Sie stellen dennoch die Annahme infrage, dass Generierung den Bedarf an Engineering-Urteil beseitigt habe.
Auch die Produktivitätsevidenz ist gemischt. Eine randomisierte METR-Studie begleitete 16 erfahrene Open-Source-Entwickler bei 246 realen Aufgaben in ihnen bekannten Repositories. Mit Werkzeugen von Anfang 2025 brauchten sie im Durchschnitt 19 % länger, wenn KI verfügbar war. Die Stichprobe war klein und spezialisiert, die Werkzeuge waren eine Momentaufnahme von Februar bis Juni 2025. Die brauchbare Lehre ist enger: Jedes Team muss sein eigenes Delivery-Ergebnis messen, einschliesslich Review- und Debugging-Zeit.
Bei vielen KI-gestützten Workflows kann Generierung den Engpass zu Kontext, Review und Verifikation verschieben. Teams müssen feststellen, ob das resultierende System für reale Nutzer funktioniert. Das ist der produktgeprägte Teil moderner Entwicklung.
Die produktgeprägte Arbeit in der KI-Entwicklung
Eine herkömmliche Funktion beginnt oft mit Verhalten, das ein Team im Voraus spezifizieren kann. Viele generative KI-Funktionen zeigen dagegen probabilistisches Verhalten. Ähnliche Eingaben können unterschiedliche Antworten erzeugen, und ein Modell-Update kann das Verhalten ändern, ohne den umgebenden Anwendungscode zu verändern. Deshalb wird Produkturteil Teil der Implementierung.
Für Entwickler beginnt die Arbeit vor der Modellwahl oder dem Öffnen eines Editors:
- Beobachten Sie den Ziel-Workflow und benennen Sie das Ergebnis, das dem Unternehmen wichtig ist. Kürzere Bearbeitungszeit, eine niedrigere Korrekturrate oder bessere Conversion können Messgrössen sein. Generierte Codezeilen sind es nicht.
- Bestimmen Sie die Kosten einer falschen Antwort und definieren Sie Fälle, die zu einem Menschen gehen müssen. Dazu gehören Berechtigungen, sensible Daten und Handlungen, die das System nie selbst ausführen darf.
- Entscheiden Sie, ob die Aufgabe ein Modell, Retrieval aus einer vertrauenswürdigen Quelle, eine deterministische Regel oder eine Kombination braucht. Manche Workflow-Schritte sollten unverändert bleiben.
- Machen Sie aus historischen und bewusst schwierigen Beispielen Evaluationsfälle mit klaren Release-Kriterien.
- Instrumentieren Sie die laufende Funktion, damit das Team Overrides, Fehler, Nutzerkorrekturen und die Geschäftskennzahl nach dem Release sehen kann.
Diese Entscheidungen betreffen Nutzerwert und Abwägungen, deshalb haben sie Produktcharakter. Sie bleiben Engineering-Arbeit, weil sie zu Tests, Datenflüssen, Zugriffskontrollen und beobachtbarem Produktionsverhalten werden müssen. Dieselbe Lücke zwischen einer überzeugenden Modell-Demo und einem verlässlichen Workflow behandelt das KI-Last-Mile-Problem.
Engineering und Produktmanagement behalten unterschiedliche Verantwortlichkeiten
Der Titel „KI-Produktmanager“ kann Rollen verwischen, die ein Delivery-Team weiterhin braucht. Ein Entwickler kann das Ergebnis eines Workflows verantworten, ohne die Produktstrategie zu übernehmen. Ein Produktmanager kann helfen, Erfolg zu definieren, ohne für die Systemzuverlässigkeit verantwortlich zu werden. Nutzen Sie die folgende Aufteilung als praktischen Ausgangspunkt. Passen Sie sie an Teamgrösse, regulierte Pflichten und bestehende Entscheidungsrechte an.
| Verantwortung | Engineering Lead | Produkt- oder Business Lead | Gemeinsame Entscheidung |
|---|---|---|---|
| Architektur, Integrationen und Datengrenzen | Verantwortlich | Konsultiert | Wahl akzeptabler Abwägungen |
| Zuverlässigkeit, Latenz, Sicherheit und Incident Response | Verantwortlich | Informiert | Risikotoleranz beim Release |
| Kundenerkenntnisse und Problemauswahl | Liefert technischen Einblick | Verantwortlich | Workflow-Umfang |
| Portfolio-Reihenfolge, Preis und Adoptionsstrategie | Konsultiert | Verantwortlich | Investitionsfall |
| Evaluationskriterien und Nutzerfeedback | Baut wiederholbare Nachweise | Definiert gewünschtes Ergebnis und gewinnt Nutzer | Release- und Änderungsentscheidungen |
Tiefes Engineering-Können zählt mindestens ebenso stark, wenn generierter Code ins System gelangt. Eine grössere Änderung kann eintreffen, bevor das Team sie versteht. Architektur, Review, Observability und Incident Response verhindern, dass diese Geschwindigkeit zu fragiler Software führt.
Produktmanagement bleibt ebenfalls eine echte Spezialisierung. Einen Markt zu wählen, Kundensegmente zu vergleichen oder Investitionen über Teams hinweg zu priorisieren, verlangt breitere Evidenz, als ein Entwickler üblicherweise sieht. Die produktive Verschiebung findet an der Grenze statt: Entwickler gewinnen Produkturteil für die Fähigkeit, die sie bauen, und Produktverantwortliche werden präziser bei Evidenz und technischen Einschränkungen.
Ein kleines Team braucht klare Entscheidungsrechte
Ein KMU braucht selten einen neuen Titel für jeden KI-Piloten. Es braucht benannte Verantwortliche von der ersten Workflow-Diskussion bis zum ersten Produktionsreview. In einer kleinen Firma kann eine Person beide Hüte tragen, die beiden Verantwortlichkeiten sollten jedoch sichtbar bleiben. Eine mögliche Zuordnung lautet:
| Entscheidung | Verantwortlicher Lead | Unverzichtbarer Partner | Nachweis vor der Skalierung |
|---|---|---|---|
| Ziel-Workflow und Geschäftskennzahl | Produkt- oder Business Owner | Entwickler | Ausgangsmessung und benannte Nutzergruppe |
| KI- oder konventionelle Architektur und Datenzugriff | Entwickler oder technischer Lead | Security- oder Data Owner | Datenfluss-Review und Fallback-Pfad |
| Evaluationsmenge und Release-Schwelle | Entwickler oder technischer Lead | Produkt- oder Domänenexperte | Repräsentative Fälle und Bestehenskriterien |
| Modell, Anbieter und Kostenabwägung | Entwickler oder technischer Lead | Produkt- oder Business Owner | Vergleich von Qualität, Latenz, Kosten und Datenschutz |
| Produktionsfeedback und Änderungsentscheidung | Gemeinsam | Support oder Operations | Masse für Override, Fehler, Adoption und Ergebnis |
Diese Tabelle passt auf eine Seite. Ihr Wert liegt darin, Lücken in der Verantwortung zu verhindern. Ein Modell kann eine plausible Antwort liefern, während alle annehmen, jemand anderes habe die Quelle geprüft, den Eskalationsweg definiert oder gemessen, was danach geschah.
Zugang zu Nutzern ist ebenfalls eine Delivery-Abhängigkeit. Wenn Sie einen Entwickler bitten, aus einem unklaren Prompt einen Agenten zu bauen, bleiben die wichtigsten Produktentscheidungen offen. Geben Sie dem technischen Owner Zeit mit den Menschen, die die Arbeit ausführen, und mit dem Domänenexperten, der die kostspieligen Ausnahmen kennt.
Evaluation ist Teil des Produkts
Bei herkömmlicher Software kann ein Test prüfen, ob dieselbe Eingabe die erwartete Ausgabe erzeugt. KI-Systeme benötigen eine breitere Evidenzschleife. Korrektheit kann vom Kontext abhängen, Nützlichkeit kann subjektiv sein und manche Fehler sind wesentlich folgenreicher als andere.
Das NIST AI Risk Management Framework ordnet diese Arbeit den Funktionen Govern, Map, Measure und Manage zu. Es fordert Tests vor dem Deployment, regelmässige Evaluation im Betrieb, dokumentierte Verantwortlichkeiten und Monitoring. Das ist auch dann ein praktisches Delivery-Modell, wenn ein System nicht in eine regulierte Kategorie fällt.
Ein kompaktes Evidenzpaket für eine KMU-Funktion sollte enthalten:
- Die vorgesehenen Nutzer, den Ziel-Workflow und eine messbare Ausgangslage.
- Repräsentative Evaluationsbeispiele sowie unzulässige Antworten und vorhersehbare Missbrauchsfälle.
- Die Daten- und Zugriffskarte, den menschlichen Eskalationsweg und das Fallback-Verhalten.
- Eine Release-Schwelle, benannte Verantwortliche und einen Eintrag zu Modell- oder Prompt-Änderungen.
- Produktionsmessungen zu Korrekturen, Overrides, Vorfällen, Review-Aufwand und dem gewählten Geschäftsergebnis.
Hier wird Produkturteil konkret. Ein Ziel wie „Support-Mitarbeitern helfen, schneller zu antworten“ muss zu einer Evaluationsmenge und einer Schwelle werden, die das Team vertreten kann. Die technische Umsetzung dieser Schleife behandelt KI-Agent-Testing und Evals ausführlicher.
Europäische Teams müssen den Anwendungsfall zudem klassifizieren, bevor sie annehmen, welche rechtlichen Pflichten gelten. Der EU AI Act legt je nach Rolle und Risikokategorie unterschiedliche Pflichten fest. Sein territorialer Geltungsbereich kann Anbieter oder Betreiber ausserhalb der EU erfassen, wenn die Ausgabe eines KI-Systems in der Union verwendet wird. Der Schweizer Sitz allein entscheidet den Geltungsbereich daher nicht. Der Leitfaden zum EU AI Act für KI-Agenten bietet den weiteren Compliance-Kontext. Bei folgenreichen Anwendungsfällen verdient die rechtliche Einordnung fachliche Beratung.
Wo das Bild des KI-Produktmanagers an Grenzen stösst
Die Mischung von Fähigkeiten hat Grenzen. Drei Situationen verdienen besondere Sorgfalt.
Der Entwickler hat wenig Kundenzugang. Produkturteil braucht Evidenz von Nutzern und dem Business. Ohne sie kann ein Entwickler lokale Interface-Entscheidungen treffen, aber weder das richtige Problem verlässlich wählen noch einen Markt vertreten.
Das System liegt in einer Legacy- oder regulierten Umgebung. Integration, Identität, Auditierbarkeit und Fehlerbehandlung können den Arbeitsaufwand dominieren. Starke Produktinstinkte helfen bei Abwägungen, während spezialisiertes Engineering und Domänenreview entscheidend bleiben.
Die Organisation muss Portfolio-Entscheidungen treffen. Ein Entwickler nahe an einem Workflow kann zu dessen stärkstem Fürsprecher werden. Jemand muss diese Investition weiterhin mit anderen Kundenbedürfnissen und kommerziellen Prioritäten im Unternehmen vergleichen.
Das Bild bricht auch dann zusammen, wenn Führungskräfte Discovery, Delivery und kommerzielle Verantwortung ohne Zeit oder Autorität auf eine Person laden. Funktionsübergreifende Arbeit lässt sich besser steuern, wenn die Grenze ausdrücklich ist und beide Seiten Zugang zu den nötigen Nachweisen haben.
Ein praktischer 90-Tage-Plan für die Fähigkeit
Ein Pilot über 90 Tage ist lang genug, um eine Evidenzschleife aufzubauen, und kurz genug, um den anfänglichen Umfang eng zu halten. Der folgende Zeitplan ist illustrativ. Passen Sie ihn an Integrationskomplexität und Fehlerkosten an.
Tage 1 bis 15: Workflow wählen. Beobachten Sie Nutzer, erfassen Sie eine Ausgangslage und bestimmen Sie ein Ergebnis. Benennen Sie Fälle ausserhalb des Umfangs und den menschlichen Owner für Ausnahmen. Entscheiden Sie bei jedem Schritt, ob KI gerechtfertigt ist.
Tage 16 bis 35: Evidenzpaket aufbauen. Wählen Sie repräsentative historische Fälle, ergänzen Sie schwierige und unzulässige Beispiele, dokumentieren Sie den Datenzugriff und vereinbaren Sie eine Release-Schwelle. Hier machen Produkt- und Technikverantwortliche ihre gemeinsamen Annahmen überprüfbar.
Tage 36 bis 65: gegen die Evaluation bauen. Implementieren Sie den kleinsten nützlichen Ausschnitt, verbinden Sie nur die nötigen Daten und prüfen Sie generierten Code nach denselben Standards wie menschlich geschriebenen Code. Verfolgen Sie Evaluationsergebnisse neben Latenz, Kosten und betrieblichen Einschränkungen.
Tage 66 bis 90: mit reversiblem Pfad releasen. Beginnen Sie mit menschlichem Review oder einer begrenzten Nutzergruppe. Protokollieren Sie Korrekturen und Vorfälle, vergleichen Sie das Ergebnis mit der Ausgangslage und entscheiden Sie über Skalierung, Überarbeitung oder Stopp.
Bewerten Sie am Ende das Team ebenso wie die Funktion. Kann der Entwickler das Nutzerergebnis und die Fehlerkosten erklären? Kann der Produktverantwortliche die Evaluationsschwelle und technischen Einschränkungen erklären? Können beide auf Produktionsnachweise zeigen? Die Antworten zeigen, ob die Organisation die Fähigkeit hinter dem Etikett KI-Produktmanager entwickelt hat.
Die Zukunft von Softwareentwicklern wird sich kaum auf einen einzigen hybriden Titel reduzieren. Eine klarere Veränderung ist bereits in der Arbeit sichtbar: Generierung wird einfacher, während Verantwortung für Kontext und Nachweis näher an den Ingenieur rückt, der die Funktion baut. Teams, die unterschiedliche Spezialisierungen schützen und das Ergebnis teilen, können diese Verschiebung in bessere Produkte verwandeln statt in einen grösseren Stapel plausiblen Codes.
Häufige Fragen
Wird jeder Entwickler zum KI-Produktmanager?
Nein. Der Begriff beschreibt eine wachsende Mischung von Fähigkeiten und keinen allgemeinen Berufswechsel. Entwickler, die KI-gestützte Workflows bauen, müssen zunehmend Nutzer verstehen, Evaluationskriterien definieren und Ergebnisse in der Produktion verfolgen. Produktmanager verantworten weiterhin die breitere Discovery, Portfolio-Prioritäten und kommerzielle Abwägungen, während Ingenieure für Architektur, Integration, Sicherheit und einen verlässlichen Betrieb zuständig bleiben.
Was macht ein KI-Produktmanager anders als ein Softwareentwickler?
Ein KI-Produktmanager führt üblicherweise Problemauswahl, Kundenerkenntnisse, Priorisierung und den Business Case. Ein Softwareentwickler setzt diese Entscheidungen in ein sicheres, beobachtbares System um und liefert Nachweise für dessen Funktion. Die Arbeit überschneidet sich bei Umfang, Evaluationskriterien, Feedback und Release-Entscheidungen. Die Grenze hängt von Teamgrösse, Regulierung und der Nähe jeder Person zu den Nutzern ab.
Welche Produktkompetenzen brauchen Entwickler für KI-Produktentwicklung?
Nützlich sind Workflow-Beobachtung, eine klare Ergebnisdefinition, Evaluationsdesign und disziplinierte Feedback-Erhebung. Ein Entwickler sollte verstehen, wer die Funktion nutzt, wie teuer ein Fehler ist, wann ein Mensch übernehmen muss und welche Geschäftskennzahl sich verändern soll. Er oder sie muss nicht das gesamte Aufgabenfeld des Produktmanagements übernehmen, um dieses Urteil für eine einzelne Fähigkeit anzuwenden.
Wie sollte ein kleines Unternehmen eine KI-Funktion evaluieren?
Beginnen Sie mit repräsentativen Fällen aus dem Ziel-Workflow und definieren Sie korrektes, nützliches und unzulässiges Verhalten vor dem Start. Halten Sie die Datengrenze, den Fallback-Pfad und den verantwortlichen Owner fest. Verfolgen Sie bei einem kontrollierten Release Review-Zeit, Korrekturen, Overrides, Vorfälle und das gewählte Geschäftsergebnis. Überarbeiten Sie die Testmenge, wenn Nutzer neue Fehlerbilder finden oder sich Modell und Workflow ändern.
Kann eine Person Produkt- und Engineering-Seite eines KI-Piloten verantworten?
Ja, besonders in einem kleinen Unternehmen, sofern die beiden Entscheidungsbereiche ausdrücklich bleiben. Diese Person muss technisches Verhalten testen und mit Zugang zu echten Nutzern fundierte Workflow-Entscheidungen treffen können. Bei folgenreichen oder regulierten Anwendungsfällen sollten Sie die nötige Fach-, Sicherheits- oder Rechtskompetenz einbeziehen. Eine kombinierte Rolle hebt den Bedarf an unabhängiger Prüfung nicht auf, wenn die Fehlerkosten sie erfordern.