Schritt für Schritt zur Generative AI Applikation – Ein praktisches Generative AI Playbook für ProduktmanagerInnen

ℹ️ Dies ist der erste Artikel aus einer in den kommenden Monaten entstehenden Serie. Er stellt ein allgemeines Playbook für die Entwicklung von Generative AI Anwendungen vor. In Folgeartikeln werden die einzelnen Schritte jeweils detailliert behandelt.

Wilde Zeiten. Generative AI wirbelt den Möglichkeitenraum für die Entwicklung digitaler Produkte deutlich um. Ein Hype, der mich in vielen Bereichen an die Zeiten der Mobile-Revolution erinnert, als das Internet auf einmal in die Hosentasche wanderte und in deren Fahrwasser rückblickend viel wertlose Software produziert wurde – "Lasst uns mal die Firmenwebsite als App umsetzen."

Neben der Unklarheit darüber, wo wir die neuen Möglichkeiten gut einsetzen, sehe ich aber auch noch weitere Parallelen, nämlich in der Polarisierung der Diskussionen. Nur geht es auf LinkedIn, in Blogs und unter KollegInnen, heute eben nicht darum, ob morgen der Desktop Computer abgeschafft wird, sondern um Generative-AI-Extreme:

"Dank Cursor erledigt ein Engineer die Arbeit von einem ganzen Team." vs. "Vibe Coding ist weit davon entfernt, jemals Production Software zu liefern." "Mithilfe von KI kann ich jeden Aspekt meiner Arbeit automatisieren." vs. "KI halluziniert und gibt mir Banalitäten zurück, da bin ich manuell schneller." "AGI könnte noch im Dezember Realität sein und die Menschheit abschaffen." vs. "Ein statistisches Modell, welches die Wahrscheinlichkeit von Wortfetzen generiert, kann nichts Intelligentes liefern."

Die Wahrheit liegt allerdings dazwischen: Wir haben es mit Large Language Models mit einer Technologie zu tun, die zwar ohne Frage wertstiftend eingesetzt werden kann, die aber nicht in der Lage ist, magisch alle Probleme zu lösen. Das weiß ich nicht nur theoretisch, als jemand, der Transformer-Technologie zumindest modellhaft versteht, sondern auch praktisch, weil ich inzwischen in sechs Projekten involviert war, die Large Language Models intensiv nutzen. Damit würde ich mich auf keinen Fall als Experten bezeichnen, mir fällt jedoch auf, dass das mitunter mehr Erfahrung ist, als so manch ein dedizierter KI-Berater für sich beanspruchen kann.

Kombiniert mit inzwischen mehr als zwölf Jahren Erfahrung im Produktmanagement fühle ich mich gerade so eben selbstsicher genug, ein Framework für die Entwicklung von AI-Produkten zur Diskussion zu stellen. Wieso tue ich das? Nun, einfache Antwort: Ich will demystifizieren! Mit generative AI, so scheint es, reden viele Stimmen gerade mehr über die neueste Technologie und sehr wenige über den praktischen Einsatz im Produkt. Das hat mich oft mehr verwirrt, als das es Fokus geschaffen hat und entsprechend möchte ich das hier anders machen. LLMs sind statistische Modelle, die uns einen beeindruckenden Output auf einen Input liefern – lasst diesen simplen Fakt zur Anwendung bringen und nicht in halbreligiösen Diskussionen um AGI (Artificial General Intelligence) verlieren.

Wie nähern wir uns AI Product Management?

Dies ist der erste Artikel einer Serie, in welcher ich Schritt für Schritt aus der Perspektive eines Product Managers beschreibe, wie eine Generative-AI-Anwendung, welche Large Language Models nutzt, praktisch zu bauen ist. In diesem ersten Artikel beschreibe ich das Vorgehen auf einer allgemeinen Ebene. Danach werde ich weitere Artikel verfassen, die jeweils in die einzelnen Schritte hineinzoomen und im Detail beschreiben, was zu tun ist.

Disclaimer: Wir finden alle gerade heraus, wie man diese neue Technologie gut einsetzt, und auch wenn ich meine, hier ein Muster erkannt zu haben, kann es gut sein, dass einzelne Aspekte keinen langfristigen Bestand haben. Ich bitte Euch daher, diese Artikelserie als Vorschlag zu betrachten, während ich ihn als lebendes Dokument zu kontinuierlich überarbeite. Unten wird jeweils ein Changelog aufgeführt, damit wir gemeinsam nachvollziehen können, wie sich die Herangehensweise anpasst.

Du arbeitest praktisch mit Large Language Models und möchtest einzelne Punkte ergänzen oder siehst sie anders? Cool! Schreibe mir gerne und wir schauen, wie wir Deine Beobachtung einbauen! jan@produktkraft.com

In welchen Aspekten unterscheidet sich AI Product Management vom digitalen Produktmanagement für deterministische Anwendungen?

Ein wichtiger Merksatz ist: Die Grundprinzipien guter digitaler Produktentwicklung bleiben erhalten. Unterschiede finden sich meiner Ansicht nach vor allem in den folgenden drei Detailfragen.

Erstens muss man sich vor Augen führen, welche Risiken man in der Produktarbeit mitigieren möchte. In klassischer Softwareentwicklung stellen sich dabei bspw. Fragen, ob eine UI verstanden wird. Risiko Nummer eins im AI Product Management jedoch, ob die KI unser Problem konsistent lösen kann. Entsprechend brauchen wir Methoden, die diese Frage zuerst beantworten.

Zweitens haben wir den Unterschied zwischen deterministischer Software, also Software, die basierend auf klaren Wenn-Dann-Sätzen ein erwartbares Verhalten zeigen soll, und Software, die uns durch komplett neue Outputs überraschen kann. Die Software macht also was sie will und diesem Spannungsfeld muss man ebenfalls mit neuen Techniken entgegentreten.

Drittens spielt die Kostenkontrolle eine größere Rolle, wenn wir Generative AI einsetzen. Gegebenenfalls kann KI unser Problem zwar lösen, aber zu Infrastrukturkosten, die letztlich so hoch sind, dass unser Business Case nicht mehr aufgeht. Ein Chatbot mit 1000 Nutzern täglich kann schnell 500–5000€/Monat kosten – weit mehr als eine klassische Web-Anwendung.

All diese drei Aspekte greift das Framework gezielt auf, während es mit allen sonstigen Aspekten moderner Produktarbeit kompatibel ist. Wir beginnen in diesem Artikel wie gesagt mit der Übersicht, bevor dann in den folgenden Monaten die Doppelklicks in die einzelnen Stufen folgen. Alles klar? Los geht's!

Wie sind die Schritte zur Entwicklung von Generative AI Produkten zu verstehen?

Basierend auf dem, was ich in der praktischen Produktarbeit in den vergangenen Jahren erlebt habe, schlage ich vor, Generative AI Anwendungen, welche auf Large Language Models basieren, in sechs Stufen anzugehen. Diese folgen nicht sequenziell aufeinander, sondern bauen aufeinander auf. In der Anwendung heißt das, dass man zwar von links nach rechts durch die Schritte läuft, aber keinen jemals abschließt: Vielmehr kommt einfach mehr dazu. Versteht die Darstellung als idealtypische Orientierungsgebung, das gerade am Anfang dabei hilft, Komplexität zu reduzieren und auf keinen Fall als starres Framework.

Ich möchte zudem noch vorwegstellen, dass dieses Modell sich auf die Entwicklung von Anwendungen fokussiert, welche Large-Language-Models einsetzen. Teile davon mögen auch für andere Generative-AI-Anwendungen oder sogar Discriminative-AI sinnvoll sein, diese nehme ich hier aber explizit nicht in den Blick. Darüber hinaus soll es sich hierbei nicht darum gehen, wie KI-Tools die Arbeit als Produktmanager verändern können, sondern der volle Fokus auf dem Produkt liegen.

Playbook für die Entwicklung von LLM Applikationen

Stufe 1 – Verstehen

Der idealistische Produktmanagement-Theoretiker in mir fühlt sich manchmal zu einer Struktur hingezogen, in welcher man grundsätzlich beim Problem startet. Eine klare Produktvision gibt eine Richtung an, der Spielraum wird durch eine explizite Strategie eingegrenzt und Opportunity Solution Trees schaffen Übersicht zu allen möglichen Lösungen. Erst nach einigen Experimenten entscheiden wir uns dann für die Lösung mit der besten Chance dafür, wirklich gut zu sein – ungeachtet des Tech-Stacks oder dessen, ob jemand schon früh eine konkrete Featureidee hatte. Mir ist aber auch klar, dass die Realität anders aussieht. Gerade in der aktuellen Phase des Hype Cycles heißt es in vielen Organisationen einfach: "Lasst uns mal KI einsetzen", ohne dass klar ist, wieso eigentlich.

Ich sage als Hot Take einmal: Das ist in der aktuellen Phase als Startpunkt okay! Nur durch Praxis und Experimentieren können wir lernen, welche Probleme sich gut mit Generative AI lösen lassen und welche Themen dafür nicht geeignet sind. Also lasst uns die Hände schmutzig machen, auch wenn in manchen Fällen infrage steht, ob man die Probleme nicht auch ohne KI lösen könnte.

Allerdings muss man mindestens verstehen, was die KI machen soll und wie ein guter Outcome aussieht, um gezielt arbeiten zu können. Ich habe in den vergangenen Jahren mit zu vielen Teams gesprochen, die irgendwie KI einsetzen, um irgendwas zu erreichen. Die Folge: Prompts werden umgeschrieben und umgeschrieben und umgeschrieben und irgendwann wird die AI-Initiative gestoppt, weil sie hinter den nebulösen nicht-definierten Erwartungen zurückbleibt.

Wie immer in der digitalen Produktentwicklung beginnen wir also damit, einen Problemraum zu verstehen, ein Problem in den Fokus zu nehmen und Ideen einer Lösung zu formulieren. Der Unterschied zur traditionellen digitalen Produktentwicklung liegt aber darin, dass wir die Idee nicht als PRD (Product Requirements Document) oder Wireframe skizzieren, sondern über eine gewünschte Input/Output-Kombination aus einem Large Language Model.

Man skizziert also beispielsweise einen Fließtext für eine ideale Konversation mit einem Chatbot oder eine ideale JSON-File, die aus unstrukturiertem Text produziert werden soll. Praktisch: Das sind dann die ersten Evals und diese können, ähnlich wie beim Ansatz von Test Driven Development, als Grundlage dafür dienen zu sehen, wann unsere Software gut genug ist.

Stufe 2 – MVP & Tech Stack

Ist einmal klar, was Ihr lösen wollt, gilt es in einem crossfunktionalen Team aus Product & Engineering einen Prototypen zur Validierung zu bauen. Beim Bau von probabilistischer Software sind zwei Themen besonders relevant: Kann die KI Euren Case überhaupt bearbeiten und was sind die Kosten? Beides könnt Ihr mit den internen Dev Tools der gängigen LLM Anbieter testen: Schreibt Prompts, die Ihr auch in der Software verwenden würdet, schaut Euch die Antworten an und beobachtet die Kosten für die Hochrechnung.

Habt Ihr daran einen grünen Haken, gilt es dann, eine erste Version der Generative AI Anwendung oder des Features zu bauen. Hier gelten in breiten Teilen dieselben Regeln wie bei jedem MVP. Ein paar Besonderheiten sollten jedoch beachtet werden, damit Ihr schnell iterieren könnt. Konkret sollte sofort eine Software für die Beobachtung der Inputs und Outputs (Traces), Nutzerfeedback auf Antworten (Human Annotations) und das Prompt Management implementiert werden.

Es gibt viele vergleichbare Large Language Model Engineering Plattformen, die diesen Funktionsumfang bereitstellen, und die meisten sind schnell eingebunden. Ich persönlich habe gute Erfahrungen mit LangFuse gemacht, Langsmith, Lilypad, LangWatch oder Lunary sollen allerdings ebenfalls gut sein. Auch wenn die Verlockung groß ist, beim MVP auf die Einbindung zu verzichten: Ich versichere Euch, dass das in der Regel kleine Investment seine Zeit wert ist. Denn nur wenn Ihr erkennt, was Eure NutzerInnen schreiben, Ihr die Qualität der Antworten bewerten könnt und Ihr Eure Prompts schnell anpassen könnt, könnt Ihr zielgerichtet lernen und entwickeln.

Stufe 3 – Interner MVP Testlauf

Das Team, welches den MVP entwickelt hat, testet die eigene Software mit klaren Hypothesen und wird viele Fälle, die man in offene Systeme einträgt, gar nicht auf dem Schirm haben. Beispiel: Die App meines eigenen Startups soll Fragen zur Psychotherapie beantworten, hat sich anfangs aber auch gerne dazu geäußert, wie hoch der Hamburger Fernsehturm ist. Viele dieser ersten Fallen kann man mit Mitgliedern der eigenen Organisation oder Freunden vorwegnehmen.

In diesem Schritt entstehen zudem weitere Evals, denn in der echten Nutzung lernt man die ersten Edge Cases kennen, welche dafür sorgen, dass das eigentlich für korrekt gehaltene Alignment wieder in Zweifel gezogen wird.

Erst wenn ein klar gesetztes Erfolgsziel, beispielsweise 70% der manuell gemanagten Evals oder 95% der Nutzerinteraktionen gut laufen, sollten externe TesterInnen das Produkt benutzen.

Stufe 4 – Externer MVP Testlauf

Als Nächstes sollte man eine Gruppe realer Pilot-NutzerInnen in die aktive Nutzung bringen. Dabei ist nicht nur wichtig, ob diese die App benutzen, sondern das Verhalten sollte im Detail erfasst werden, um möglichst schnell und viel zu lernen. Das heißt konkret: Lest die Dialoge Eurer NutzerInnen und führt qualitative Interviews durch. AI won't help you here! Ihr müsst einen Product Sense für Eure Generative AI Software aufbauen und das geht nur, indem Ihr die wirklichen Dialoge kennt und empathisch versteht, wie sich die Nutzung anfühlt. Jeder, der Euch einen magischen Prompt verkaufen will, lügt. Aber seht es einmal positiv, durch das lesen der Traces seid Ihr an den Nutzungssessions Euer NutzerInnen deutlich näher dran, als wir es aus deterministischer Software gewohnt sind.

Stufe 5 – Aufbau von GenAI Operations

Sofern die Testnutzung aus dem externen MVP Testlauf gut funktioniert, solltet Ihr in Vorbereitung für den großen Launch die Operations hinter Eurem Feature gut ausbauen. Konkret heißt das, basierend auf dem Gelernten Eure Prompts zu modularisieren, Playgrounds für schnelleres Prompt Engineering einzusetzen, A/B Testing zu bedenken und spätestens jetzt das Prompt Deployment zwischen Staging und Production Systemen zu differenzieren. Diese Grundlage wird Euch helfen, die Komplexität beim breiten Rollout besser zu handhaben.

Wichtig auf dieser Stufe ist es, einen kühlen Kopf zu bewahren und jedes Werkzeug einzusetzen, das die LLM-Toolbox zur Verfügung stellt. Ebenso wenig, wie jede Domäne zwingend einen eigenen Microservice braucht oder jeder Aspekt einer App Test-Coverage braucht, muss für jedes Projekt die volle Gen-AI-Bandbreite genutzt werden.

Stufe 6 – Full Rollout & Skalierung

Full Launch! Im finalen Schritt braucht Ihr LLM as a Judge Evals, da Ihr nun hoffentlich aufgrund der breiten Nutzung nicht mehr in der Lage seid, alle Dialoge selbst mitzulesen. Hinzu kommt die Problematik, dass Ihr im langfristigen Betrieb immer mal wieder Model-Upgrades mitmachen werdet, für welche automatische Evals ebenfalls Gold wert sind.

Mit dem Ausrollen der Anwendung an viele AnwenderInnen muss zudem auch verstärkt auf Kostenoptimierung geachtet werden, was den Bewussten Einsatz von verschieden LLMs und das dazugehörige Model-Routing in den Blick rückt.

Was ist zusammenfassend wichtig für die Produktentwicklung von Large Language Model Software?

Ich betone es nochmal: Auf der Ebene von Prinzipien hat mit Generative AI nichts geändert. Digitales Produktmanagement bedeutet weiterhin, dass wir ein Problem verstehen müssen, um dann in möglichst schnellen Feedbackzyklen eine Lösung zu finden, die für Nutzende und unser Business funktioniert. Definiert Euer Ziel und rennt auf den Build-Measure-Learn-Zyklus zu, um im Austausch mit der Realität iterieren zu können. Der Unterschied liegt lediglich darin, dass andere Risiken zu beachten sind, andere Methoden für die QA benötigt werden und sich die Kostenstruktur verändert hat.

Das obige Framework ist inzwischen meine Leitschnur, mit der ich den anderen Herausforderungen bisher am besten gerecht wurde. Wenn Du aus Deiner Praxis einen noch schlankeren und fokussierteren Weg im Product Management zu Generative AI Anwendungen kennst, dann melde Dich gerne bei mir – jan@produktkraft.com – ich freue mich auf den Austausch und auf gemeinsames Lernen!

Wie es nun weitergeht

Wie gesagt sind wir als Branche gerade erst dabei zu lernen, wie man Anwendungen basierend auf Large Language Models effektiv und effizient baut, und es ist gut möglich, dass der von mir beschriebene Prozess einzelne Aspekte, die in Eurer Arbeit wichtig sind, übersieht. Entsprechend möchte ich zunächst einmal ein paar Wochen warten und Feedback für diese Struktur einsammeln und gegebenenfalls einarbeiten. Daraufhin werde ich damit beginnen, sechs weitere Artikel zu schreiben und jeweils im Detail auf die einzelnen Schritte eingehen.

Ich hoffe, der Beitrag hilft insbesondere denjenigen unter Euch, die bisher noch keine volle AI Anwendung gebaut haben, dabei, ein besseres Verständnis für die eigentliche Praxis zu gewinnen und sich nicht im Buzzword Bingo verloren zu gehen.