Warum macht die KI es immer falsch? Sie ist nicht dumm – du hast es nur nicht klar gesagt

Zuerst eine Szene, die du höchstwahrscheinlich schon erlebt hast.

Du lässt die KI etwas für dich bauen, wartest voller Erwartung auf das Ergebnis, und am Ende ist das, was herauskommt, meilenweit von dem entfernt, was du dir vorgestellt hast. Du korrigierst einen Satz, sie macht dafür an anderer Stelle einen Fehler, ihr geht ein paar Runden hin und her, und schließlich hast du die Nase voll und es rutscht dir heraus: „Diese KI ist eben auch nicht besser.”

In diesen Monaten arbeite ich fast täglich mit KI und tappe täglich in genau diese Falle. Aber mit der Zeit habe ich meine Meinung geändert. Denn ich habe eine sehr ernüchternde Regelmäßigkeit entdeckt: Dieselbe Anforderung, ich formuliere sie anders, und sie macht es beim ersten Versuch richtig.

Ein-, zweimal ist Zufall, aber acht-, zehnmal ist es keiner mehr. Nach und nach musste ich mir eine Sache eingestehen: Wenn die KI etwas falsch macht, liegt es meistens nicht daran, dass sie dumm ist, sondern daran, dass ich es nicht klar gesagt habe.

Das ist keine Esoterik, dahinter steckt eine ganz schlichte Wahrheit, so schlicht, dass sie schon fast grausam ist:

Die KI kann keine Gedanken lesen. Sie tut nur, was du „sagst”, nicht, was du „denkst”.

Die Anforderung in deinem Kopf ist dreidimensional – sie hat einen Hintergrund, hat Standardannahmen, die dir gar nicht bewusst sind, hat ein ganzes Bündel an „das ist doch offensichtlich”-Alltagswissen. Aber der Satz, den du in das Dialogfeld tippst, ist oft nur noch eine dünne Schale davon. Die KI bekommt genau diese Schale, den Rest muss sie erraten. Rät sie richtig, hast du Glück gehabt, rät sie falsch, hältst du sie auch noch für dumm.

Nachdem ich das durchschaut hatte, habe ich aufgehört, darüber nachzugrübeln, „welche KI klüger ist”, und mich stattdessen an einer wertvolleren Sache geübt: wie ich die dreidimensionale Anforderung aus meinem Kopf vollständig in das Dialogfeld übertrage. Dieser Text ist meine komplette Methode dafür. Alles zum direkten Nachmachen, keine einzige Zeile, für die man Talent bräuchte.

Und ich muss sagen: Für Produktmanager ist das eine riesige gute Nachricht. Anforderungen zu beschreiben ist ohnehin die Kernkompetenz eines PM. Früher hast du die Anforderung der Entwicklung erklärt, heute erklärst du sie der KI – der einzige Unterschied ist: Die Entwicklung ergänzt aus Erfahrung, was du nicht gesagt hast, und fragt bei dir nach, die KI ist gehorsamer und „ehrlicher”, sie macht genau so viel, wie du sagst. Deshalb musst du es der KI gegenüber ein kleines bisschen klarer sagen als der Entwicklung. Genau dieses kleine bisschen ist die Hürde – und die Wasserscheide.

Eine Anforderung, die die KI beim ersten Versuch richtig macht, hat fünf Bauteile

Ich habe die Anforderungen, die ich „klar gesagt” hatte, aufgedröselt und festgestellt: Sie haben immer fünf Dinge beisammen. Fehlt eines davon, entscheidet die KI genau an dieser Stelle selbst für mich.

Du musst nicht jedes Mal alle fünf ausschreiben und daraus ein Schema machen. Aber du musst diese fünf Fächer im Kopf haben – wirf vor dem Abschicken einen Blick darauf: Welches Fach leer ist, dort wird die KI eigenmächtig handeln.

Bauteil eins: Was – benenne das Substantiv zuerst genau

Das Grundlegendste und zugleich das, worüber man am leichtesten hinweghuscht.

Du sagst „bau mir irgendwas für die Nutzerverwaltung”, aber was ist dieses „irgendwas”? Eine Seite? Eine Tabelle? Ein ganzes Backend? Die KI kann sich nur eins davon aussuchen und raten.

Ersetze es durch: „Bau eine Nutzerlisten-Seite, eine Tabelle, die Avatar, Name, E-Mail, Registrierungszeit und Status anzeigt.” – Und schon weiß sie, wo sie ansetzen muss.

Der Kniff in einem Satz: Ersetze schwammige Wörter wie „Ding”, „Funktion”, „Modul” durch konkrete Substantive. Seite, Tabelle, Button, Formular, Diagramm, Pop-up. Erst wenn du sagen kannst, was es eigentlich „ist”, kann die KI daran anknüpfen.

Bauteil zwei: Für wen, warum – das wird am leichtesten vergessen und ist am wertvollsten

Diesen Punkt lassen gerade Leute mit technischem Hintergrund oft weg, dabei ist er genau die Paradedisziplin des PM – du solltest dich von Natur aus dafür interessieren, „wer es benutzt und warum”.

Vergleich mal. Du sagst „bau ein Daten-Dashboard, pack alle möglichen Daten drauf”, dann kippt sie dir einen ganzen Bildschirm voller Diagramme hin, die du vielleicht gar nicht anschaust.

Sag stattdessen: „Bau ein Daten-Dashboard, das sich der Filialleiter jeden Morgen anschaut. Ihn interessiert am meisten: wie viel gestern verkauft wurde, ob es gegenüber vorgestern gestiegen oder gefallen ist, welche Kategorie sich am besten verkauft – diese drei am prominentesten, der Rest zweitrangig.”

Siehst du den Unterschied? Mit „wer nutzt es + was ihn am meisten interessiert” weiß die KI, was hervorgehoben und was zurückgenommen werden muss – sie bekommt „Prioritäten”, statt alle Informationen flach nebeneinanderzulegen.

Ich habe mir inzwischen fast eine Gewohnheit angewöhnt: Hinter jede Anforderung setze ich einen Satz „das ist für wen gedacht, welches Problem will er lösen”. Dieser Satz ist oft mehr wert als alle vorangegangenen Beschreibungen zusammen.

Bauteil drei: Die konkrete Gestalt – sag, „wie es aussieht”

Die Idee hat in deinem Kopf ein Bild, aber du wirfst nur ein abstraktes Wort raus.

„Bau eine Filterfunktion” – die KI weiß nicht, wonach du filtern willst und wie.

„Füge über der Tabelle eine Filterleiste hinzu: einen Datumsbereichs-Wähler, ein ‚Status’-Dropdown (Alle / Aktiv / Gesperrt), ein Suchfeld (Suche nach Name oder E-Mail); der Filter wirkt sofort, nach der Auswahl aktualisiert sich alles direkt, kein Bestätigen nötig.” – Das kann sie eins zu eins nachbauen.

Du musst nicht designen können, du musst nur das Bild in deinem Kopf in Alltagssprache beschreiben: welche Blöcke es gibt, was jeder Block ist, wo er liegt, wie man ihn benutzt. Kannst du es beschreiben, kann sie es nachbauen; kannst du es nicht beschreiben, heißt das, du hast es selbst noch nicht klar durchdacht – und das ist gut so, das ist ein Signal, ich zeige später, wie man es umgekehrt nutzt, um selbst klar zu werden.

Bauteil vier: Die Grenzen – die Wasserscheide zwischen „sieht lauffähig aus” und „ist wirklich benutzbar”

Zu diesem Punkt muss ich ein paar Worte mehr sagen, denn er ist der wahre Unterschied zwischen Anfänger und PM.

Anfänger beschreiben in ihrer Anforderung nur den „Normalfall”: Der Nutzer füllt brav aus, die Daten sind alle in Ordnung, das Netz ist durchgehend da. Aber in der echten Welt füllt der Nutzer Unsinn ein, sind Daten leer, bricht das Netz ab, ist die Eingabe überlang. Das nennt man „Randfälle”, und es ist genau das, worum sich ein PM am meisten kümmern sollte und was du der KI am dringendsten ausdrücklich sagen musst.

Du sagst „bau ein Feedback-Formular mit Name, E-Mail, Inhalt und einem Absende-Button”, dann baut sie dir den Normalpfad und ist fertig.

Wenn du es aber so sagst:

„…achte auf diese Fälle: Ist das E-Mail-Format falsch, markiere es unter dem Eingabefeld rot und lass es nicht absenden; ist der Feedback-Inhalt leer, lässt sich der Absende-Button nicht klicken; nach erfolgreichem Absenden das Formular leeren und ‚Danke für dein Feedback’ anzeigen; scheitert das Absenden (etwa bei Netzausfall), lösche NICHT, was der Nutzer schon eingetippt hat, und zeige ‚Absenden fehlgeschlagen, bitte erneut versuchen’.”

Diese paar zusätzlichen Zeilen sind die Professionalität des PM. Die KI kann das alles durchaus verarbeiten, aber sagst du es nicht, macht sie standardmäßig nur den „Normalpfad”. Listest du die Grenzen auf, macht sie es dir beim ersten Versuch vollständig.

Am Rande bemerkt: Auch „was als fertig gilt” und „was nicht gemacht wird” gehören zu den Grenzen und müssen ebenso gesagt werden. Ein Satz wie „diese Version macht nur Liste und Filter, Anlegen/Bearbeiten/Löschen vorerst nicht” hält dir einen Haufen Zeug vom Leib, das du in dieser Runde gar nicht wolltest.

Bauteil fünf: Die Referenz – gib ihr ein Maß

Stil, Farbe, Nutzungserlebnis – solche „Gefühls”-Dinge sind am schwersten in Worte zu fassen. Der einfachste Weg: eine Referenz geben.

„Mach die Farben schön und professionell” – „schön” und „professionell” verstehen hundert Leute auf hundert Arten.

„Als Hauptfarbe das Marken-Blau #3B82F6, das Gesamt-Farbschema und der Weißraum orientieren sich an dem sauberen, zurückhaltenden Stil der Stripe-Website.” – Jetzt hat sie ein Maß und muss dein „schön” nicht blind erraten.

Eine Referenz kann ein Farbwert sein, ein Produkt, das du gut findest („wie Notion”), ein Standard. Gibst du eine Referenz, muss die KI nicht auf deinen Geschmack wetten.

Fünf häufigste „Unklarheiten” und wie man sie behebt

Oben war die positive Zerlegung. Unten sind die fünf Fallen, die ich am häufigsten sehe und selbst am häufigsten begehe – eine nach der anderen zum Selbstcheck.

Falle eins: zu allgemein. „Bau eine schöne Seite” – sie gibt dir etwas Mittelmäßiges, und du kannst nicht mal sagen, was daran nicht stimmt. Behebung: Zwing dich eine Ebene ins Konkrete, ersetze Adjektive durch Substantive und Details.

Falle zwei: nur Befehle geben, keinen Kontext. „Füg eine Export-Funktion hinzu” – exportiere was? Wohin? In welches Format? Wo hinzufügen? Behebung: Ergänze „wo + exportiere was + in welches Format”, zum Beispiel „füge oben rechts auf der Report-Seite einen ‚Export’-Button hinzu, der die Tabelle unter den aktuellen Filterbedingungen als CSV zum Download exportiert”.

Falle drei: auf einen Schlag einen Haufen fordern. In einer Nachricht fünfzehn Anforderungen stopfen, das Ergebnis ist ein Chaos, und du weißt nicht mal, wo du anfangen sollst zu korrigieren. Behebung: In kleinen Schritten vorangehen, immer nur eine auf einmal. Erst das Grundgerüst bauen, laufen lassen, den Effekt sehen, dann eins nach dem anderen draufsetzen. Diese Regel ist die wichtigste von allen, ohne Ausnahme.

Falle vier: keine Referenz geben, den Geschmack ganz erraten lassen. Behebung siehe Bauteil fünf: gib einen Farbwert, gib ein Referenzobjekt, gib einen Standard.

Falle fünf: nur den Normalfall sagen, nicht die Ausnahmen. Die Demo läuft glatt, aber gib es echten Nutzern in die Hand, und alles Mögliche stürzt ab. Behebung: Frag dich vor dem Abschicken drei Sätze – Was, wenn die Daten leer sind? Was, wenn der Nutzer Unsinn einfüllt? Was, wenn das Netz abbricht? Schreib die Antworten in die Anforderung.

Drei Kniffe: die KI von einer „Hand” in einen „Kopf” verwandeln

Wenn du das Obige beherrschst, bist du schon besser als die meisten. Die folgenden drei Kniffe nutze ich, um die KI von einer „gehorsamen Hand” in einen „Kopf, der für mich mitdenkt” zu verwandeln.

Kniff eins: Lass sie erst zurückfragen, nicht sofort loslegen. Das ist der Kniff, den ich am meisten nutze und der am kontraintuitivsten ist: Je wichtiger die Anforderung, desto weniger solltest du sie gleich loslegen lassen, sondern sie erst fragen lassen.

„Ich habe eine Idee: ein Tool zum Sammeln und Analysieren von Kundenfeedback bauen. Leg noch nicht los – stell mir zuerst die fünf entscheidendsten Fragen, damit wir Zielnutzer, Kernzweck, unverzichtbare Funktionen und Grenzen alle sauber klären.”

Die Fragen, die sie stellt, sind mit hoher Wahrscheinlichkeit genau die Stellen, die du selbst noch nicht klar durchdacht hast. Der Vorgang des Antwortens ist der Vorgang, in dem du die Anforderung von „einem verschwommenen Klumpen” zu „einer klaren Linie” zwingst. Wenn du fertig geantwortet hast, hat sie bereits eine vollständige Anforderung in der Hand, und das Ergebnis stimmt dann natürlich. Der Kern dieses Kniffs ist: die KI nutzen, um selbst klar zu denken, nicht nur, um etwas herzustellen – ist es einmal klar durchdacht, ergibt sich das Richtige von selbst.

Kniff zwei: Gib ein Positiv- und ein Gegenbeispiel. Wenn Worte es nicht klar machen, sind Beispiele am schnellsten, besonders bei „ich will das, nicht jenes”.

„Schreib mir den Hinweistext, der nach dem Klick auf diesen Button erscheint. Er soll so sein: kurz, umgangssprachlich, gibt Sicherheit – ‚Gespeichert, alles gut’. Nicht so: behördlich, umständlich – ‚Ihr Vorgang wurde erfolgreich an den Server übermittelt und dauerhaft gespeichert’.”

Ein Positiv- plus ein Gegenbeispiel wirkt besser, als wenn du drei Zeilen Adjektive schreibst.

Kniff drei: Lass sie zur Bestätigung wiederholen, bevor sie loslegt. Ist die Anforderung komplex, lass sie erst ihr Verständnis wiedergeben, und erst wenn du bestätigt hast, dass es stimmt, legt sie los.

„Die Anforderung, die ich gerade genannt habe, mach sie noch nicht. Bestätige sie mir zuerst in drei Sätzen: was du vorhast zu tun, in wie viele Teile es zerfällt, und ob es Stellen gibt, bei denen du dir unsicher bist. Wenn ich bestätigt habe, fängst du an.”

Dieser Schritt kostet dreißig Sekunden und erspart dir eine halbe Stunde Nacharbeit. Während sie wiederholt, entdeckst du oft auf der Stelle „hoppla, was ich hier gesagt habe, ist nicht das, was ich gemeint habe” – solange sie noch nicht losgelegt hat, schnell korrigieren.

Einmal komplett durch: von einem verschwommenen Satz bis zum ersten richtigen Wurf

Verknüpfen wir das Obige und gehen einmal einen echten Ablauf durch. Angenommen, in meinem Kopf gibt es nur einen verschwommenen Satz: „Ich will irgendwas, mit dem ich Nutzerfeedback ansehen kann.”

Erster Schritt: Ich lasse sie nicht gleich loslegen, sondern lasse sie mir zuerst beim Klardenken helfen (Kniff eins): Ich lasse sie mir fünf entscheidende Fragen stellen. Sie wird fragen: Wer nutzt es (die Kollegen aus dem Betrieb)? Woher kommt das Feedback (eine CSV-Datei)? Was will ich am meisten daraus gewinnen (schnell erkennen, worüber sich alle am meisten beschweren)? Soll nach Schweregrad sortiert werden (ja)? Braucht diese Version einen Filter (vorerst nicht)?

Zweiter Schritt: Die Antworten zu einer vollständigen Anforderung zusammensetzen, die fünf Bauteile sind gerade beisammen: für den Betrieb gedacht, Ziel ist es, schnell zu erkennen, worüber sich die Nutzer am meisten beschweren (für wen, warum); oben ein Upload-Bereich für die CSV, darunter zeigt sich automatisch die thematische Einordnung des Feedbacks, wie viele Einträge je Thema, welcher Anteil, sortiert nach Anzahl (was, Gestalt); ist die CSV leer oder das Format falsch, den Hinweis „Einlesen fehlgeschlagen, bitte Format prüfen” zeigen, in dieser Version vorerst kein Filter und keine Suche (Grenzen); sauber und zurückhaltend, Hauptfarbe #3B82F6, das Layout an Notion orientiert (Referenz). Erst mit Fake-Daten aufbauen, einen lokalen Server laufen lassen, damit ich es in der Vorschau sehe.

Dritter Schritt: Läuft es und ich sehe den Effekt, dann in kleinen Schritten ergänzen (Behebung von Falle drei): eins nach dem anderen – „hinter jedes Thema einen Fortschrittsbalken für den Anteil”, „bei Klick auf ein Thema drei Original-Feedbacks dieser Kategorie ausklappen”, „Themen nach Schweregrad einfärben, Rot ist hochfrequent, Gelb mittel, Grau niedrig”.

Vierter Schritt: Sie selbst nach Problemen suchen lassen: „Klick alle anklickbaren Stellen einmal durch, finde Fehlermeldungen, Hänger, Abweichungen vom Erwarteten, und mach eine Liste.”

Den ganzen Weg habe ich keine einzige Zeile Code geschrieben, aber jeden Schritt glasklar gesagt. Genau das ist heute der Alltag – du bist fürs Klardenken und Klarsagen zuständig, sie fürs Herstellen.

Zum Schluss

Bevor ich Enter drücke, gehe ich in der Regel zehn Sekunden lang im Kopf diese Fächer durch: Was (ist es ein konkretes Substantiv?), für wen und warum, wie es aussieht, Grenzen (leere Daten, Unsinn-Eingabe, Fehlschlag, was nicht gemacht wird – alles gesagt?), Referenz, und – habe ich diesmal wirklich nur eine Anforderung gestellt? Kommen von sechs vier oder fünf durch, macht sie es im Grunde beim ersten Versuch richtig.

Die Leute, die mit KI umgehen können, werden immer mehr, aber die Leute, die Anforderungen klar sagen können, sind stets eine Minderheit. Das Erste ist die Hürde, jeder kann sie überschreiten; das Zweite ist die Wasserscheide, es teilt die Leute in zwei Lager.

Und du als Produktmanager verstehst ohnehin am besten die Nutzer, am besten die Prioritäten, am besten jene Grenzen, um die sich sonst niemand für dich kümmert. Was dir fehlt, war nie das – es ist die Gewohnheit, es auszusprechen. Übe einen Monat, und du wirst merken: Nicht die KI ist klüger geworden, sondern du hast endlich gelernt, die Anforderung in deinem Kopf vollständig herauszugeben.