Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASAKI ist die Antwort auf alle Probleme in der Softwareentwicklung:KI beschreibt Anforderungen.KI schreibt Code.KI übernimmt den Betrieb.Zumindest, wenn wir dem Hype auf LinkedIn rund um KI Glauben schenken. Zweifelsohne ist generative KI die spannendste Technologie seit der Erfindung des Internets. Und richtig eingesetzt wird sie viele Probleme lösen – aber nicht auf magische Weise. Sondern weiterhin durch Produktmanagement.Welchen Regeln folgt dieses KI-Produktmanagement?Ersetzt es gar agile Softwareentwicklung?Oder Produktmanagement mit Scrum?Genau das schauen wir uns heute an.Natürlich bin ich kein Experte. Weder habe ich einen Lehrstuhl am MIT zur KI-Forschung inne, noch arbeite ich bei OpenAI.Ich dokumentiere hier meine Erfahrungen als Anwender:Mittlerweile habe ich über 10 Jahre Erfahrung im Produktmanagement. Begonnen habe ich 2015 als Product-Owner.Davor habe ich Mathematik studiert und gerade genug Vorlesungen über maschinelles Lernen besucht, dass ich glaube, die Transformer-Theorie grob zu verstehen.In den letzten zwei Jahren habe ich mehrere Kunden als Berater begleitet, die generative KI-Anwendungen entwickelt haben. Unter anderem ein KI-Start-up aus Berlin.Was ich dabei gelernt habe:KI-Produktmanagement folgt anderen Regeln als klassische Softwareentwicklung.Los geht’s ... Schritt #1: Problem-Discovery – Verstehen wir das Problem wirklich? Was kommt zuerst: Technologie oder Problem?Aus Sicht eines Produktmanagers ist die Frage einfach zu beantworten. Erfolgreiche Produkte lösen immer Probleme ihrer (zukünftigen) Nutzer. Deshalb müssen wir zuerst diese Probleme verstehen.Aber machen wir uns nichts vor:Es ist 2026. Der KI-Hype ist in vollem Gange. Und manchmal beginnt ein KI-Projekt nicht mit einem Problem – sondern mit einem Satz im Management-Meeting:„Wir brauchen auch etwas mit KI.“Trotzdem bleibt die Frage entscheidend: Sollten wir es bauen?Diese Frage beantwortet Problem-Discovery wie gewohnt – Interviews, Nutzungsdaten, Markt- und Wettbewerbsanalyse. Was sich ändert, ist die Folgefrage: Ist KI hier überhaupt die richtige Lösung?Aber bevor wir dazu kommen, brauchen wir ein konkretes Problem. Betrachten wir das PSM-III-Bootcamp – eine Community, die Scrum Master auf die PSM-III-Prüfung vorbereitet.Ich nutze bewusst mein eigenes Bootcamp als Beispiel, weil ich dort alles selbst umsetze – von Hypothesen über Prototypen bis zu Evals und Kosten – und frei darüber schreiben kann.Feedback und Bewertungen („Wie hilfreich ist persönlichen Feedback von Marc und Simon“) der Angebote im Camp zeigen, dass Teilnehmer mit einer Sache sehr unzufrieden waren:„Ich wünsche mir mehr Feedback von euch, jede Antwort von euch zusätzlich beantwortet zu bekommen.“„Das Feedback hat sich im Laufe des Bootcamps sehr stark auf bestimmte Personen konzentriert, meist auf die, die in einem ähnlichen Zeitfenster geantwortet haben.“„Ich glaube, mir hätte noch mehr Feedback von euch beiden geholfen.“Natürlich ist das nicht einfach möglich. Meine Zeit ist auch begrenzt. Anschließende Interviews haben mir gezeigt, dass der Wunsch hinter diesem Wunsch ist:Als Camper möchte ich wissen, ob meine Antwort zum Bestehen der Prüfung reicht.Das war der Startpunkt, um nach Lösungen für dieses Problem zu suchen.Schritt #2: Solution-Discovery – Ist KI hier die richtige Wahl? Ist generative KI die richtige Lösung?Large-Language-Modelle (LLMs) liefern als Antwort auf Texteingaben teilweise beeindruckende Texte als Ausgabe.Aber davon sollten wir uns nicht blenden lassen. Es bleiben statistische Modelle. Was uns vor ein Problem stellt, das sich in der klassischen IT eigentlich nicht auftun sollte:Kann die KI das Problem gleichbleibend gut lösen?Klassische Softwarelösungen können wir uns wie Wenn-dann-Sätze vorstellen. Wenn ich auf „Senden“ drücke, dann wird die E-Mail versendet. Das erwarten wir – und zwar jedes Mal. Alles andere wäre ein Fehler in der Software und müsste behoben werden. Generative KI hat das Potenzial, uns mit jedem Input komplett neue Outputs zu liefern. Was beeindruckend klingt, zeigt aber auch, dass eine generative KI für die Lösung vieler Probleme verstörend wirken würde. (Ich stelle mir gerade dein Gesicht vor, wenn du auf „Senden“ drückst und die E-Mail daraufhin gelöscht wird.) Deshalb lautet die erste Frage bei der Solution-Discovery:Ist generative KI die richtige Lösung für das Problem unserer Nutzer?Zur Beantwortung dieser Frage brauchen wir andere Tests und Prototypen. Statt mit einem Requirement-Dokument und einem Wireframe zu starten, beginnen wir mit einer einfachen Beschreibung der generativen KI-Lösung.Was wollen wir in die KI eingeben, was soll sie ausgeben?Konkret beschreiben wir die gewünschte Kombination aus Eingabe und Ausgabe eines Large Language Models. Das kann etwa ein Fließtext aus einem Gespräch mit einem Chatbot sein.Hier ein Beispiel aus meinen ersten Prototypen.Eingabe: Antwort auf eine Frage.Ausgabe: Bestehe ich mit dieser Antwort die Prüfung?Die offensichtlich falsche Beantwortung der Frage erkennt die KI sofort.Allerdings erkennt sie eine ungenügende Antwort nicht als ungenügend. Die KI übersieht, dass es bei Scrum um Wertmaximierung geht. Zu viel Handlungsfreiheit für das Modell, zu wenig Kontrolle über das Ergebnis.Bei der Entwicklung generativer KI sollten wir uns deshalb an einem klaren Prinzip orientieren: zuerst Prototypen mit viel Kontrolle und wenig Handlungsfreiheit entwickeln – und erst später mehr Handlungsfreiheit zulassen.Für einen Assistenten, der Support-Tickets bearbeitet, könnte das so aussehen:Version 1 – Routing: klassifiziert und leitet das Ticket an die richtige Abteilung weiter.Version 2 – Copilot: leitet weiter, greift auf relevante SOPs oder frühere Antworten zu und schlägt mögliche Lösungen vor.Version 3 – Lösungsassistent: erstellt Entwürfe oder löst häufige Tickets automatisch mithilfe abgerufener Kontexte.Konkret bedeutet die Suche nach einer Lösung: Prompt-Prototypen schreiben, die KI-Produktstrategie justieren und Bewertungen aufsetzen. Also iterieren, iterieren und iterieren ...Hier am Beispiel:Der Prompt, unterschiedliche LLMs, die KI-Antwort und die menschliche Bewertung der Antwort werden genutzt, um der Lösung näher zu kommen.Schritt #3: MVP-Testlauf – Vom Prototyp zum Golden Dataset Funktioniert es zuverlässig – und lohnt es sich wirtschaftlich?Wenn du mit einem Prototyp zeigen kannst, dass das Kundenproblem grundsätzlich gelöst werden kann, stellst du dir zwei Fragen:Funktioniert die Lösung stabil genug?Können wir sie wirtschaftlich betreiben?Am Ende dieses Schritts steht keine technische Entscheidung, sondern eine Produktentscheidung:Gehen wir live – oder stoppen wir hier?Du gehst nur live, wenn beide Bedingungen erfüllt sind.Frage #1: Funktioniert die Lösung stabil genug? Unser Ziel ist nicht, dass die KI manchmal gute Ergebnisse liefert, sondern dass sie das Problem gleichbleibend gut löst.Dafür brauchst du Bewertungen.Meist als „Evals“ abgekürzt. Ähnlich wie beim Test-Driven-Development definierst du Testfälle, mit denen du überprüfst, ob deine Lösung zuverlässig funktioniert. Diese Testfälle basieren idealerweise auf echten Nutzerinteraktionen. Testläufe können mit internen Nutzern, Pilotnutzern oder in Labs durchgeführt werden. Es geht darum, unter realen Bedingungen Edge-Cases kennenzulernen und zu verstehen, wo das Modell versagt.Spätestens dann entsteht ein Goldstandard-Datensatz. Dieser besteht typischerweise aus:Input (z. B. Nutzerfrage, Text, Ticket)erwarteter Output (die „richtige“ Antwort)optional: Bewertungskriterien (z. B. korrekt, hilfreich, vollständig)Ohne wirkliche Expertise laufen wir Gefahr, dass uns der eloquente Output des LLMs blendet.Im Fall eines Agenten für den Kundensupport kann die Erstellung von Evals sehr aufwendig sein. Konkret müsste man durch viele Hundert Gespräche von Kunden mit Support-Mitarbeitern gehen und bewerten, welche Antworten die Probleme der Kunden lösen konnten und welche nicht.Ich spreche hier aus leidvoller Erfahrung.Und erst wenn ein klar gesetztes Erfolgsziel erreicht wird – beispielsweise 70 % der manuell gemanagten Evals oder 95 % der Nutzerinteraktionen laufen gut –, erfüllst du die erste Bedingung.Frage #2: Lohnt sich die Lösung wirtschaftlich? KI-Produkte kosten Geld.Nicht in der Entwicklung – sondern im Betrieb: Eine einzelne, kontextreiche Interaktion mit einem Modell wie GPT-4 kann leicht 15.000 Tokens verbrauchen (System-Prompt + RAG-Daten + Historie). Bei einem Preis von ca. 0,01 Euro pro 1.000 Tokens kostet eine einzige Anfrage bereits 0,15 Euro.Klingt erst einmal nicht nach viel.Allerdings entstehen bei 10 000 Interaktionen pro Tag Kosten von 1.500 Euro täglich, was auf den Monat gerechnet ca. 45.000 Euro allein für die API-Gebühren entspricht. Noch ohne Infrastruktur oder Wartung.Weiter entstehen die Kosten eines KI-Features nicht durch einen Prompt – sondern durch das Verhalten deiner Nutzer. Je mehr es genutzt wird, desto mehr Kosten entstehen.Und die Computing-Kosten stiegen im Zeitraum von 2023 bis 2025 um fast 89 %. Weshalb 70 % der Führungskräfte laut einer Studie von IBM sagen, dass GenAI-Anwendungen die IT-Kosten massiv steigen lassen.Die entscheidende Frage ist deshalb nicht, ob die KI funktioniert – sondern ob sie zu diesen Kosten noch Wert erzeugt.Wenn beide Bedingungen erfüllt sind, geht das Produkt live. Wenn die Kosten den erzeugten Wert übersteigen, ist die Entscheidung hoffentlich auch klar. Konkret sollte ab jetzt eine Software zur Beobachtung der Inputs und Outputs, für Nutzerfeedback zu Antworten und für Prompt-Management implementiert sein.Schritt #4: Ausrollen & Betrieb – Aufbau von GenAI-Operations Wie behalten wir die Qualität unter Kontrolle – bei Skalierung?Ab jetzt sollten Evals automatisiert sein. Aufgrund der breiten Nutzung bist du nicht mehr in der Lage, alle Dialoge selbst mitzulesen. Konkret sollte ab jetzt eine Software zur Beobachtung der Inputs und Outputs, für Nutzerfeedback zu Antworten und für Prompt-Management implementiert sein.Hier einige Eval-Methoden im Überblick:LLM-as-Judge: Ein starkes LLM bewertet die Ausgaben deines Modells anhand eines Rubrics. Skaliert gut und benötigt keine manuellen Labels, ist allerdings anfällig für Biases des Judge-Modells.A/B-Testing: Nutzergruppen bekommen unterschiedliche Modellversionen oder Prompts. Dann werden Metriken wie Conversion, Retention und Zufriedenheit verglichen.Red-Teaming: Tester versuchen gezielt, das Modell zu Fehlern zu bringen: Promptinjektionen, Edge-Cases, widersprüchliche Inputs. Essenziell vor dem Launch, um Sicherheitslücken zu finden.All diese Bewertungen sollten uns aber nicht darüber hinwegtäuschen:KI bleibt eine Sammlung statistischer Modelle.Immer zu 100 % gleiche Ergebnisse gibt es nicht. Und wenn bei 10 000 Anfragen 500 Fehler gemacht werden, ist das für meine KI im Bootcamp akzeptabel – aber auch für eine Versicherung, die somit ihre Kunden falsch berät?Beim Betrieb hörte es bei mir bisher immer auf. Ich habe den Aufbau von Infrastruktur, Monitoring und Compliance begleitet – aber nicht selbst gemanagt. Was ich sagen kann: Diese fünf Bereiche existieren und du brauchst für jeden eine Antwort, bevor du live gehst.Infrastruktur und Provider-Management: die technische Basis deiner KI-Anwendung. Hier wird geregelt, über welche Anbieter Anfragen laufen, wie API-Keys sicher verwaltet werden und was passiert, wenn ein Anbieter ausfällt.Prompt- und Modell-Lifecycle: Änderungen an Prompts werden kontrolliert eingeführt, ähnlich wie Code-Deployments. Prompts oder Modelle werden versioniert, getestet, mit dem Golden Dataset geprüft und schrittweise ausgerollt.Observability und Monitoring: der Blick in den laufenden Betrieb deiner KI-Anwendung. Hier wird sichtbar, wie schnell sie antwortet, wo Fehler auftreten, was ein Request kostet und ob die Qualität nachlässt, – damit rechtzeitig eingegriffen werden kann, bevor es deine Nutzer bemerken.Kosten- und Performance-Optimierung: Einfache Anfragen werden an günstigere Modelle weitergeleitet, häufige Antworten werden gecacht und nicht zeitkritische Tasks gebündelt verarbeitet – damit die Qualität gleich bleibt, aber die Rechnung nicht explodiert.Sicherheit und Compliance: Personenbezogene Daten werden herausgefiltert, bevor sie an externe APIs gehen, Modellantworten werden auf problematische Inhalte geprüft und jede KI-Entscheidung wird nachvollziehbar dokumentiert – besonders wichtig unter Berücksichtigung der DSGVO und des EU AI Act.Meine Beobachtung: Was bedeutet das für Product-Owner? Jeder Entwicklungsprozess folgt eigenen Regeln.Hardware-Entwicklung nutzt Wasserfall – weil physische Prototypen teuer und Änderungen nach der Produktion kaum möglich sind.Software-Entwicklung nutzt agile Ansätze – weil Code anpassbarer ist und schnelle Iterationen ermöglicht.Und KI? Das wird sich noch zeigen.Meine Beobachtung nach über zwei Jahren Begleitung von KI-Projekten:KI-Entwicklung ist viel experimenteller als klassische Softwareentwicklung.Bei klassischer Software wissen wir oft relativ früh, ob eine Lösung technisch machbar ist. Bei KI bleibt die Frage „Kann das Modell unser Problem konsistent genug lösen?“ bis weit in die Entwicklung hinein offen. Das verändert den gesamten Discovery-Prozess. Es werden mehr Prototypen gebaut. Es wird mehr getestet. Es wird mehr iteriert – nur nicht primär am Produktdesign, sondern am Prompt, am Modell und am Kontext.Vielleicht ist das so, weil die Technologie noch jung ist.Vielleicht auch, weil das nicht deterministische Verhalten von LLMs ein neues Produktrisiko darstellt, das wir erst lernen zu managen.Oder weil wir als Product-Owner erst lernen müssen, mit Unsicherheit anders umzugehen.Gerade deshalb glaube ich nicht, dass KI-Entwicklung die Entwicklung von Produkten mit Scrum ersetzt.Eher im Gegenteil.KI-Entwicklung zeigt die Grundidee von Scrum in Reinform: empirisches Arbeiten. Du kannst nicht planen, wie gut dein Modell oder Prompt performen wird. Du musst bauen. Testen. Messen. Anpassen. Und das immer wieder.Vielleicht folgt KI-Produktmanagement also keinen völlig neuen Regeln, sondern zwingt uns nur, empirisches Arbeiten endlich ernst zu nehmen.
PS: Mehr davon – live und mit KI? In meinen “Scrum mit KI“-Trainings arbeiten wir genau an diesen Themen. Hier findest du die nächsten Termine.