Wir haben einen E-Mail-Outreach-Agenten für ein Vertriebsteam gebaut: ein KI-System, das personalisierte Akquise-Mails in großem Maßstab generieren sollte. Hohe Anforderungen: markenkonsistent, präzise, innerhalb klar definierter Grenzen. Wir hatten den Setup-Sprint abgeschlossen, den richtigen Kontext eingebettet und befanden uns in der Iterationsphase. Die Outputs wurden besser. Wir hatten Varianten in Persona, Winkel, Betreffzeile. Wir brauchten den Sales Lead, der Batches reviewt und uns eine Richtung gibt. Aber Quartalsende. Er war im Abschluss.
Wir hätten einfach weitermachen können, Annahmen treffen, Richtungen wählen, etwas ausliefern. Stattdessen zog sich das Projekt in die Länge. Aus zwei potenziellen Iterationstagen wurden zwei Wartwochen. Der Engpass war nicht die KI. Es war die Organisationsstruktur.
Dieses Projekt hat uns etwas gelehrt, das sich seitdem in jedem KI-Projekt wiederholt: KI-Entwicklung verändert nicht nur, wie schnell gebaut wird. Es verändert, wann menschliches Input gebraucht wird, wie oft, und welcher Art. Teams, die das wie normales Agile mit schnelleren Sprints behandeln, laufen immer wieder gegen dieselbe Wand.
Das Paradox
KI macht Entwicklung schneller, erfordert aber mehr Beteiligung des Fachbereichs, nicht weniger.
Die übliche Erwartung ist die entgegengesetzte. KI automatisiert die Ausführung, also kann die Fachseite einen Schritt zurücktreten. Das Tech-Team kümmert sich um Prompting, Output, Iteration. Der Fachbereich schaut bei Demos rein, wie immer.
KI-Output wird generiert, nicht spezifiziert. In klassischer Softwareentwicklung schreibt ein Entwickler Code, der genau das tut, was die Anforderungen sagen. Wenn die Anforderungen falsch waren, ist der Output falsch, aber auf eine spezifische, nachvollziehbare Weise. Mit KI beschreibt man das gewünschte Ergebnis, und das Modell produziert etwas Plausibles. "Plausibel" und "richtig für unseren Geschäftskontext" sind zwei verschiedene Dinge. Nur der Fachbereich kann diese Lücke schließen.
BCGs Analyse von KI-Deployments in Unternehmen zeigt, dass erfolgreiche Projekte etwa 10% des Aufwands auf Algorithmen verwenden, 20% auf Technologie und Daten, und 70% auf Menschen und Prozesse. Diese 70% sind kein Kostenfaktor, sondern der eigentliche Arbeitsinhalt. Und dieser Aufwand wirkt sich stärker aus, je kürzer der Iterationszyklus wird.
Die Rechnung verändert sich
In einem klassischen Agile-Sprint wird zwei Wochen gebaut und einmal gedemo. Der Fachbereich hat einen strukturierten Touchpoint pro Sprint. Das funktioniert, wenn die Arbeit Wochen dauert.
Wenn ein KI-gestützter Workflow drei funktionierende Iterationen vor der Mittagspause liefern kann, bricht "ein Demo pro Sprint" sofort zusammen.
McKinsey hat das beziffert: ein Ergebnis, das früher fünf Tage und zwei Iterationen brauchte, braucht jetzt zwei Tage und fünfzehn Iterationen. Der Kalender verdichtet sich. Die Entscheidungsbedarfe multiplizieren sich. Wer früher zwei Business-Entscheidungen in fünf Tagen brauchte, braucht jetzt fünfzehn in zwei. Die Verfügbarkeitsannahmen des klassischen Agile halten dieser Rechnung nicht stand.
Zwei Phasen, nicht eine
KI-Entwicklung verläuft nicht gleichmäßig. Sie teilt sich in zwei strukturell unterschiedliche Phasen.
Phase 1: Setup-Sprint. Das sieht aus wie normales Agile. Gebaut wird der Harness: der Flow, die Integrationen, die Prompt-Architektur. Der Takt ist regelmäßig, die Entscheidungen sind größtenteils technischer Natur, ein Standardprozess funktioniert gut. Ungefähr zwei Wochen.
Phase 2: Intensive Iteration. Hier bricht die übliche Struktur zusammen. Die KI läuft, der Output kommt rein, und er muss mehrmals täglich bewertet und gesteuert werden. Im Service-Case-Klassifizierungsprojekt, das wir durchgeführt haben, bedeutete das: Klassifizierungs-Prompt anpassen, Output-Genauigkeit mit dem Fachbereich verifizieren, und wiederholen, manchmal drei bis vier Mal an einem einzigen Tag. Der Fachbereich musste bestätigen, nicht nur ob einzelne Fälle korrekt klassifiziert wurden, sondern ob die Gesamtgenauigkeit dem Schwellenwert entsprach, den man in der Produktion akzeptieren würde.
Einen etablierten Namen gibt es für diese zweite Phase noch nicht. "Inspect and Adapt Iterations" kommt nahe, erfasst aber nicht ganz die Frequenz und den Business-Anteil. Was sie von klassischer Sprint-Arbeit unterscheidet: nicht-deterministischer Output bedeutet, man kann nicht einmal testen und dann ausliefern. Das Urteilsvermögen des Fachbereichs wird kontinuierlich gebraucht, nicht bei einer Zeremonie.
Was scheitert, wenn der Fachbereich nicht mitkommt
Es gibt drei Fehlermuster, und jedes ins Stocken geratene Projekt passt in eines davon.
Das Wartespiel. Die KI liefert Optionen in Stunden. Der Product Owner ist zwei Tage in Meetings. Wenn Feedback ankommt, ist der Schwung weg und der Kontext zum Teil verblasst. Aus einem Zwei-Tage-Projekt wird ein Zwei-Wochen-Projekt.
Die Annahmen-Spirale. Das Team kann nicht unbegrenzt warten und fängt an, selbst Entscheidungen zu treffen. Was würde der Fachbereich hier wollen? Was liegt wahrscheinlich innerhalb der Markenrichtlinien? Jede einzelne Annahme ist klein. Zusammen summieren sie sich. Nach einer Woche ungesteuerter Iteration entspricht der Output nicht dem, was der Fachbereich im Sinn hatte. Nicht weil jemand etwas falsch gemacht hat. Richtungsdrift ist unsichtbar, bis man demonstriert, und was sich nach Fortschritt anfühlte, war keiner.
Der Qualitätszusammenbruch. Der Zeitplan ist eng, der Fachbereich unter Druck, der Review oberflächlich. "Sieht gut aus" wird ausgeliefert. Dann fällt auf: der Ton stimmt nicht, Randfälle sind falsch, der Content hält der Prüfung nicht stand. Der Geschwindigkeitsvorteil löst sich im Rework auf.
Das Muster, das geholfen hat
Das E-Mail-Outreach-Projekt hat mehr gelehrt als nur "mehr Fachbereich einbinden".
Weil KI-Output nicht-deterministisch ist, lässt er sich nicht anhand einer Handvoll Testfälle beurteilen. Ein Prompt, der bei fünf Beispielen funktioniert, kann beim siebenundzwanzigsten auf interessante Weise scheitern. Bewertet werden muss Volumen: vielfältige Outputs über Personas, Randfälle, unterschiedliche Eingabeszenarien. Aber der Business-Stakeholder ist nicht verfügbar, um in Echtzeit durch fünfzig Beispiele zu klicken.
Das Output-Review-Pattern trennt die beiden Aktivitäten. Das Tech-Team generiert einen großen, dokumentierten Batch verschiedener Outputs. Der Business-Stakeholder reviewt den Inhalt nach eigenem Zeitplan: was funktioniert, was nicht, welche Richtungen man fallen lässt. Nicht das Testen selbst, sondern die Bewertung der Ergebnisse. Das reduziert die Anzahl der Tests, die der Fachbereich selbst durchführen muss, und erhöht gleichzeitig die Bandbreite des betrachteten Outputs.
Live-Testing ersetzt das nicht. Aber es ermöglicht, dass ein Sales Lead dreißig Prospect-E-Mail-Varianten auf dem Weg zur Arbeit reviewt, statt zwei Stunden in einem Call den Agenten zu beobachten.
Verfügbarkeit des Fachbereichs ist ein Projektfaktor, keine Annahme
Der häufigste Fehler in Projektplänen: Business-Verfügbarkeit wird wie eine Hintergrundbedingung behandelt, wie Strom. Sie ist da, wenn man sie braucht.
Das stimmt nicht.
Inzwischen wird Business-Beteiligung so geplant wie technische Ressourcen. Vor Projektstart wird konkret: Phase 2 erfordert ungefähr X Stunden pro Woche von einer namentlich benannten Person aus dem Fachbereich, ab diesem Datum. Ohne diese Zusage stockt das Projekt. Nicht verlangsamt. Stockt.
RANDs Untersuchung von KI-Projektscheitern identifizierte "mangelndes Stakeholder-Engagement" als eine der häufigsten Ursachen, neben Missverständnissen über die Projektabsicht und passivem Widerstand von Fachexperten. Das sind alles organisatorische, keine technischen Probleme. Die Technologie hat funktioniert. Die Organisationsstruktur darum herum nicht.
Das verändert, was KI-Projektmanagement eigentlich bedeutet. Die technische Arbeit ist meistens lösbar. Das schwierigere Problem ist, eine Kollaborationsstruktur zu gestalten, in der das Urteilsvermögen des Fachbereichs verfügbar ist, wenn die KI es braucht, und nicht zwei Wochen später.
Was sich für Product Owner verändert
Die Rolle des Product Owners wird in KI-Projekten anspruchsvoller, auf spezifische Weise.
Ein klassischer Product Owner schreibt Anforderungen, reviewt Sprint-Demos und hält den Backlog priorisiert. In einem KI-Projekt gilt das weiterhin, aber Phase 2 fügt etwas anderes hinzu: Output schnell zu bewerten, direktionales Feedback zu geben, das für Prompt-Engineering nutzbar ist, und innerhalb klarer Leitplanken zu delegieren, damit nicht jede Micro-Entscheidung eskaliert.
Dieser letzte Punkt ist am wichtigsten. Wer sagen kann "innerhalb dieser Rahmenbedingungen habt ihr Spielraum: eskaliert nur bei diesen spezifischen Dingen", gibt die Geschwindigkeit frei, die KI versprechen soll. Wer alles persönlich reviewt, wird zum Engpass.
Anthropics Forschung zur Zusammenarbeit von Menschen mit KI-Agenten zeigt, dass erfahrene Nutzer vom Genehmigen jeder Einzelaktion zu strategischem Monitoring wechseln. Sie greifen an den Entscheidungspunkten ein, die wirklich zählen, statt bei allem in der Schleife zu bleiben. Diese Verschiebung ist erlernbar. Aber sie muss bewusst herbeigeführt werden.
Der Aufwand in einem KI-Projekt verschwindet nicht. Er verlagert sich vom Warten auf Entwicklung zum Steuern von Output: mehr Entscheidungsbedarfe, die schneller ankommen. Teams, die es schaffen, das Urteilsvermögen des Fachbereichs bei dieser Geschwindigkeit verfügbar zu machen, sind diejenigen, bei denen KI das Geschwindigkeitsversprechen tatsächlich einlöst. Die anderen fragen sich, warum ihr Zwei-Tage-Projekt drei Wochen gedauert hat.
Bereit für AI-Workflows, die sich aufbauen?
Ich helfe PM-Teams dabei, von Ad-hoc AI-Nutzung zu integrierten Systemen zu kommen.
Kontakt aufnehmen