Wann ist ein Feature, eine User Story, eine Funktion gut genug, um produktiv eingesetzt zu werden? Wer mit klassischen Softwareprojekten groß geworden ist, greift intuitiv zu Checklisten, Abnahmekriterien und Statusberichten. Doch generative KI-Systeme arbeiten nicht deterministisch. Sie verhalten sich. Und dieses Verhalten lässt sich nicht einfach abhaken.
Für uns bedeutet das eine Verschiebung, die tiefer geht als sie zunächst erscheint. Das zentrale Steuerungskonzept heißt nicht mehr „fertig", sondern „good enough". Dieser Artikel zeigt, was das konkret bedeutet und welche Praktiken dabei helfen, unter Unschärfe gute Entscheidungen zu treffen.
Es gibt eine Frage, die sich durch fast jedes KI-Projekt zieht. Manchmal wird sie laut gestellt, im Review, im Stakeholder-Meeting, gelegentlich sogar im Flur. Meistens aber bleibt sie unausgesprochen und hängt trotzdem über allem: Wann sind wir eigentlich fertig?
Wer klassische Softwareprojekte kennt, hat darauf eine trainierte Antwort. Wenn alle Anforderungen erfüllt sind. Wenn die Abnahmekriterien grünes Licht zeigen. Wenn die Checkliste durch ist. Diese Antwort hat jahrelang funktioniert, weil sie für Systeme gebaut wurde, die deterministisch arbeiten: Eine Funktion tut entweder das, was sie soll, oder sie tut es nicht. Richtig oder falsch. Fertig oder nicht fertig.
Generative KI interessiert sich nicht für diese Logik.
Ein KI-System liefert keine binären Ergebnisse. Es verhält sich. Es reagiert auf Kontext, Tonalität, auf die genaue Formulierung einer Frage. Dieselbe Anfrage kann heute eine präzise, hilfreiche Antwort produzieren und morgen eine, die den Nutzer ratlos zurücklässt. Nicht weil etwas kaputt ist. Sondern weil das Modell so arbeitet. Für Product Owner und Projektmanager:innen bedeutet das eine Verschiebung, die tiefer geht als sie zunächst erscheint: Das wichtigste Werkzeug ist nicht mehr die Checkliste. Es ist das Urteilsvermögen.
„Good enough" klingt nach Entschuldigung. Nach dem Kompromiss, den man eingeht, wenn die Zeit knapp wird oder das Budget nicht reicht. Diese Lesart ist nicht nur falsch. Sie ist produktionsschädlich.
In KI-Projekten ist „good enough" eine bewusste, informierte Entscheidung. Keine Kapitulation. Die eigentliche Frage lautet: Ab welchem Punkt entfaltet dieses Feature im echten Nutzungskontext ausreichend Wirkung, auch wenn es technisch noch nicht am Anschlag ist? Diese Frage zu beantworten ist schwerer, als sie klingt. Sie verlangt Urteil und Interpretation nicht-deterministischer Antworten statt die Überprüfung eindeutiger Ergebnisse. Der Unterschied zwischen beiden Lesarten entscheidet darüber, ob Teams in Optimierungsschleifen versinken oder ob sie liefern, lernen und vorankommen.
Eine der folgenreichsten Priorisierungsentscheidungen in GenAI-Projekten betrifft die Reihenfolge. Viele Teams investieren früh in Tonalität, sprachliche Eleganz, visuelle Aufbereitung. Das ist verständlich: Diese Aspekte sind in Demos sichtbar, sie beeindrucken. Sie sind trotzdem die falsche Baustelle zu Beginn.
Mindestens genauso gefährlich ist der umgekehrte Fehler: zu früh mit Technik zu skalieren, bevor das inhaltliche Fundament steht. Man kann innerhalb kurzer Zeit sehr viele Agenten in Produktion bringen. Wenn das fachliche Fundament und der Datenkontext nicht stimmt, bringt das trotzdem nichts. Wer ein ausgefeiltes System auf mangelndem Datenverständnis, fehlendem fachlichem Sparring mit dem Kunden und ungeklärten Impact-Fragen aufbaut, baut am falschen Ort. Technische Exzellenz schützt nicht vor inhaltlicher Leere, genauso wenig wie sprachliche Politur.
Fachliche Belastbarkeit hat Vorrang. Liefert das System inhaltlich verlässliche, nützliche Ergebnisse im Anwendungskontext? Erst wenn diese Frage bejaht werden kann, lohnt der Feinschliff. Wer vorher poliert, poliert eine Oberfläche auf einem instabilen Kern. Das klingt simpel. In der Praxis braucht es Standfestigkeit, den Druck früh zu glänzen auszuhalten. Dieser Druck ist real. Und er führt, unkontrolliert, in die falsche Richtung.
„Good enough" ist kein Zustand, den man einmal erreicht und abhakt. Es ist ein kontinuierlich ausgehandelter Referenzpunkt, der sich mit dem Nutzungskontext, den Stakeholder-Erwartungen und dem Lernstand des Systems verschiebt. Mal nach oben, mal nach unten, selten stabil.
Für Product Owner und Projektmanager:innen bedeutet das: Nicht das einmalige Festlegen eines Qualitätsniveaus ist die eigentliche Aufgabe. Es ist das iterative Nachschärfen, Kommunizieren und Verteidigen dieses Referenzpunkts über die gesamte Projektlaufzeit.
Die zielgerichtete Entwicklung eines KI-Systems benötigt Feedback. Viel Feedback. Und kaum etwas ist in diesem Moment wichtiger als die Fähigkeit, dieses Feedback zu sortieren. Wer alles gleich gewichtet, verliert sich im Rauschen. Wer nichts priorisiert, optimiert in alle Richtungen gleichzeitig. Das läuft auf dasselbe hinaus: man kommt nirgendwo an.
Die folgende Tabelle zeigt die vier Feedback-Kategorien und ihre Bedeutung für die Projektsteuerung:
| Kategorie | Beispiel | Was es bedeutet |
|---|---|---|
| Meinung | „Das klingt irgendwie komisch." | Subjektive Wahrnehmung, noch kein Handlungsauftrag |
| Anforderung | „Die KI soll den Nutzer duzen." | Konkreter Wunsch an das Systemverhalten |
| Erwartung | „Ich dachte, die KI macht mir Vorschläge." | Impliziter Bias, der nie kommuniziert wurde |
| Beobachtung | „Die Antworten kommen immer in Bullet Points." | Beschreibbares, wiederholbares Systemverhalten |
Diese Unterscheidung ist kein akademisches Spielzeug. Sie verändert, welche Reaktion folgt. Eine Meinung braucht eine andere Antwort als eine Anforderung. Eine Erwartung, die nie ausgesprochen wurde, muss erst sichtbar gemacht werden, bevor sie adressiert werden kann.
Beispiel aus der Praxis: Ein Fachbereich äußert in einem Meeting den Wunsch, die KI solle Ergebnisse nur anzeigen, wenn sie sich sicher ist. Klingt vernünftig. Aber was bedeutet „sicher" technisch? Eine Wahrscheinlichkeit über 95 Prozent? Keine nachweisbaren Halluzinationen? Konsens über mehrere Modelle? Wer diesen Wunsch unübersetzt als Anforderung ins Backlog schreibt, schickt das Entwicklungsteam in eine unlösbare Aufgabe. Wer ihn als implizite Erwartung behandelt, die zunächst operationalisiert werden muss, schafft die Grundlage für eine echte Lösung.
Product Owner und Projektmanager:innen werden in diesem Prozess zu Kuratorinnen und Kuratoren des Feedbacks. Sie sammeln, filtern, strukturieren und machen bewertbar, was andere fühlen oder beobachten. Das ist Übersetzungsarbeit. Und sie ist anspruchsvoller als sie aussieht.
Die beschriebenen Verschiebungen lassen sich nicht mit einem neuen Prozessmodell wegdefinieren, das die Unschärfe von GenAI-Projekten schlicht auflöst. Das heißt aber nicht, dass systematisches Vorgehen unmöglich wäre, im Gegenteil: Es braucht dafür andere Haltungen und Praktiken. Als Product Owner lässt sich Unschärfe durch klare Rollen, abgestimmte Qualitätskriterien und einen gemeinsamen Referenzrahmen im Team gezielt einschränken. Auf Architekturebene gibt es bewährte Muster, die Varianz beherrschbar machen, etwa eine sinnvolle Verankerung der Unschärfe direkt im Systemdesign via passendem Schnitt von Agenten und Datenzugriffen. Auch im Testing lässt sich das systematisch abbilden, etwa durch saubere Überführung fachlicher Kriterien in semantische Qualitätsmetriken (Stichwort Trust Index: https://arxiv.org/html/2507.16028v1). Was sich nicht wegdefinieren lässt, ist die Notwendigkeit zum Urteil.
Die zentrale Frage in der Qualitätsbewertung verändert sich grundlegend. Nicht mehr „Funktioniert das Feature?" steht im Mittelpunkt, sondern: Entfaltet es die gewünschte Wirkung im echten Nutzungskontext? Das erfordert Beobachtung statt Abnahme, echte Nutzerrückmeldung statt interner Testszenarien. Und es erfordert die Bereitschaft, Qualität als etwas zu begreifen, das sich erst im Gebrauch zeigt. Im echten, unaufgeräumten, unerwarteten Gebrauch.
Stakeholder, die klassische IT-Projekte gewohnt sind, bringen Erwartungsmuster mit, die für GenAI-Kontexte nicht passen. Sie wollen Planbarkeit, klare Meilensteine, verlässliche Prognosen. Diese Erwartungen zu ignorieren, erzeugt Enttäuschung. Sie unkritisch zu bedienen, erzeugt Druck, der zu schlechten Entscheidungen führt.
Der produktivere Weg: Erwartungen früh und transparent formen. Kommunizieren, wie sich Entwicklung im GenAI-Kontext anfühlt. Was es bedeutet, in Iterationen zu denken. Warum Ergebnisse variieren. Und warum das kein Versagen ist, sondern ein Wesensmerkmal dieser Technologie.
Hinweis für die Praxis: Sprechen Sie Stakeholder frühzeitig darauf an, dass Ergebnisse in GenAI-Projekten variieren können. Wer diese Erwartung aktiv setzt, verhindert Enttäuschungen und schafft Raum für ehrliches Feedback.
Feedback ist in GenAI-Projekten kein Korrektursignal am Ende eines Zyklus. Es ist das primäre Steuerungsinstrument über den gesamten Projektverlauf. Wer früh und systematisch Nutzerfeedback sammelt, aufbereitet und in die Weiterentwicklung von Prompts und Systemarchitektur einspeist, baut schrittweise ein belastbares Bild davon auf, was „good enough" für die eigene Nutzergruppe tatsächlich bedeutet.
Voraussetzung dafür ist, dass Feedback nicht ins Leere läuft. Es braucht klare Prozesse:
Diese Infrastruktur aufzubauen, gehört zu den am häufigsten unterschätzten Aufgaben in GenAI-Projekten.
Am Ende steht immer eine Entscheidung. Eine, die mit Restunschärfe getroffen werden muss. Es wird keinen Moment geben, in dem alle Informationen vollständig vorliegen, alle Stakeholder einig sind und das System sich in jeder Situation optimal verhält. Das ist kein Übergangszustand. Er löst sich nicht auf, wenn mehr Zeit oder mehr Budget vorhanden ist.
Projektmanager:innen, die in diesem Umfeld wirksam sind, sind nicht jene, die die meiste Sicherheit produzieren. Sie sind jene, die trotz Unsicherheit handlungsfähig bleiben, klare Entscheidungen treffen und diese gegenüber Teams und Stakeholdern vertreten. Das ist eine eigene Kunstform. Und sie lässt sich, anders als viele glauben, erlernen.
Die Frage, die am Anfang steht, bleibt bis zum Ende: Wann ist dieses Feature gut genug? Eine endgültige Antwort gibt es nicht. Was es gibt, ist das Handwerkszeug, um sie immer wieder neu zu beantworten, und den Mut, es auch einzusetzen.
Wer das verinnerlicht, liefert nicht weniger. Er liefert besser.