Ein Tag als PM im KI-Zeitalter: Wie ich aus einem Satz einen klickbaren Prototyp mache

Fangen wir mit einer konkreten Sache an. Letzten Mittwochnachmittag kam mir ein vager Gedanke: „Ich hätte gern so ein kleines Ding, mit dem ich nebenbei meine Ausgaben mitschreiben kann.” Gut zwei Stunden später hat ein Kollege es tatsächlich auf meinem Handy angetippt — auf „Buchung hinzufügen” getippt, Betrag eingegeben, Kategorie gewählt, zurück auf die Startseite, und dort sieht man, wie viel in diesem Monat ausgegeben wurde, und ein Tortendiagramm, das das in ein paar Segmente aufteilt. Keine einzige Zeile Code.

Ich erzähle das nicht, um zu zeigen, wie großartig die KI ist. Ich will auf etwas Kontraintuitives hinaus: Viele glauben, jetzt wo die KI da ist, müsse ein Product Manager schnell programmieren lernen, um nicht ausrangiert zu werden. Aber mein Eindruck aus dem letzten halben Jahr ist genau der umgekehrte — die Hürde, Code zu schreiben, bricht rasend schnell weg. Was wirklich wertvoll und zugleich selten wird, ist etwas anderes: eine Sache so klar zu sagen, dass die KI sie beim ersten Mal richtig macht.

In diesem Text geht es mir nicht um diese Erkenntnis an sich, sondern darum, wie ich es konkret angestellt habe. Ich nehme genau dieses kleine Ausgaben-Ding als Beispiel und zerlege es Schritt für Schritt für dich, samt der Fallen, in die ich getappt bin. Falls du selbst eine Idee mit dir herumträgst, die du seit Langem nicht angepackt hast — nach dem Lesen kannst du es wahrscheinlich selbst einmal probieren.

Schritt eins: Lass es nicht sofort loslegen, lass es erst mich zurückfragen

Als ich anfing, Dinge mit KI zu bauen, war mein liebster Fehler, den vagen Satz aus meinem Kopf einfach hinzuwerfen — „Bau mir eine App zum Ausgaben-Tracken” — und dann auf ein fertiges Produkt zu warten.

Das Ergebnis war immer dasselbe: Sie gab mir das, was sie glaubte, dass ich wollte, und das lag Welten von dem entfernt, was ich im Kopf hatte. Ich korrigierte Stück für Stück, sie lief Stück für Stück in die Irre, und wir saßen da und rieten uns gegenseitig an — bis ich die Krise bekam.

Dann habe ich eine Gewohnheit geändert, ein Einzeiler eigentlich, aber absurd wirksam: Ich lasse sie nicht mehr direkt loslegen, ich lasse sie erst mich zurückfragen. Ich sage: „Ich will ein kleines Tool zum Ausgaben-Tracken bauen, schreib noch nichts. Stell mir zuerst 5 Fragen zu den Dingen, die du klären musst, die ich aber noch nicht gesagt habe.”

Und dann fragt sie: Für wen ist das, nur für dich oder für mehrere? Willst du Kategorien, legst du die selbst fest oder soll ich ein paar voreinstellen? Soll der Betrag zwischen Einnahmen und Ausgaben unterscheiden? Reicht es, die Daten lokal auf dem Handy zu speichern, oder willst du sie geräteübergreifend sehen? Willst du eine Budget-Erinnerung?

Siehst du — all diese Fragen sind genau die Stellen, an denen es in meinem Kopf ursprünglich Brei war, die ich noch nicht durchdacht hatte. Sie hat für mich das „Was will ich eigentlich?” herausgekitzelt. Als ich diese 5 Fragen beantwortet hatte, war mir die Form dieses Dings selbst erst mal klar. Wenn man sie erst dann loslegen lässt, ist die Wahrscheinlichkeit, dass es beim ersten Mal sitzt, viel höher.

Die Falle, in die ich getappt bin: Die zwei Minuten, die du dir durch das Überspringen dieses Schritts sparst, zahlst du hinten mit zwei Stunden zurück. Einmal war mir das Nachfragen zu lästig, ich habe sie direkt loslegen lassen — heraus kam etwas funktional Vollständiges, aber völlig nicht das, was ich wollte, und die Nacharbeit war am Ende schlimmer als ein Neuanfang. Diesen Schritt lasse ich mir heute unter keinen Umständen mehr nehmen.

Schritt zwei: Immer nur eine Sache auf einmal ändern

Die erste Version ist da, man kann sie antippen, aber irgendwas stimmt garantiert nicht. Und genau hier lauert die zweite Falle: In einem Rutsch alle zehn Dinge nennen, die dir nicht passen.

„Die Startseite ist farblich zu blass, die Kategorie-Icons sind hässlich, die Farben im Tortendiagramm will ich ändern, der Knopf zum Buchen-Hinzufügen ist zu klein, und kann der Betrag automatisch Nachkommastellen mitbringen, ach ja, bau nebenbei noch eine Suche ein …”

Früher habe ich genau das gemacht, aus Ungeduld. Das Ergebnis: Sie ändert es, die Farbe stimmt, aber den Knopf hat sie vergessen; oder der Knopf ist repariert, dafür ist das Tortendiagramm kaputt. Wird der Batzen an Änderungen zu groß, verliert sie den Überblick, und auch du weißt nicht mehr, welcher Satz was bewirkt hat und welchen sie klammheimlich unter den Tisch fallen ließ.

Heute nenne ich immer nur eine Änderung auf einmal, tippe danach einmal auf dem Handy nach, bestätige, dass diese eine Stelle stimmt, und nenne dann die nächste. Langsam? Sieht langsam aus. Aber jeder Schritt sitzt und muss nicht zurückgenommen werden. Ich habe es nachgerechnet: So durchgezogen ist man am Ende viel schneller als mit „erst alles auf einmal sagen und dann gemeinsam nacharbeiten”, und ich weiß die ganze Zeit, wo ich gerade stehe.

Das ist kein KI-Trick, das ist die schlichteste Regel des Produktebauens überhaupt: Kleine Schritte, jeder Schritt überprüfbar. Nur dass die KI die Kosten jedes Schritts extrem tief drückt — du hast also noch weniger Grund, gierig zu werden.

Ein Einschub: Wie du jede Änderung formulierst, damit die KI sie versteht

Oben hieß es „immer nur eine ändern”, aber „eine” allein reicht nicht — entscheidend ist, wie du diese eine sagst. Das ist für mich der praxisnächste Punkt im ganzen Text und der, bei dem man am schnellsten einen Effekt sieht.

Die größte Falle, in die ich getappt bin: der KI Anweisungen mit Adjektiven geben. „Mach die Startseite schöner”, „Mach den Knopf großzügiger”, „Mach die Farben edler” — in dem Moment, in dem ich das ausspreche, gebe ich das Urteil komplett wieder an sie ab, denn „schön” und „edel” haben bei ihr zehntausend Auflösungen, sie greift sich irgendeine heraus, und das ist meistens nicht die, die du wolltest.

Danach habe ich mich zu zwei Dingen gezwungen: Gib eine Referenz, gib einen Zustand, gib keine Adjektive.

Eine Referenz geben heißt: Sag nicht „mach es schöner”, sag „bei den Karten auf der Startseite orientier dich beim Weißraum an „WeChat Read”, drei, vier Einträge pro Bildschirm, nicht gedrängt”. Sie weiß sofort, was du willst — weil du ihr etwas Konkretes gegeben hast, an dem sie sich ausrichten kann, statt einer vagen Bewertung, mit der sie tun kann, was sie will.

Einen Zustand geben heißt: Sag nicht „kümmer dich um den Fall, dass keine Buchung da ist”, sag „wenn keine einzige Buchung da ist, zeig in der Mitte der Startseite eine graue Zeile: ‚Noch keine Buchungen, unten rechts auf Hinzufügen tippen’, und zeig kein leeres Tortendiagramm”. Sag für jeden Zustand konkret, wie der Bildschirm aussehen soll — wie mit Daten, wie ohne Daten, wie während des Ladens, wie im Fehlerfall. Je konkreter du es sagst, desto weniger Spielraum hat sie, sich zu etwas „frei auszutoben”, das du nicht willst.

Mein Selbsttest heute lautet: Wenn ich eine Anweisung ausgesprochen habe, schau ich noch mal, ob ein Adjektiv drinsteckt. Sind da Wörter wie „schön, großzügig, edel, mal optimieren”, halte ich inne und übersetze es in „an wem orientieren, wie genau aussehen”. Diese kleine Handbewegung wirkt besser als jeder KI-Trick, den ich je gelernt habe.

Schritt drei: Schon die erste Version bekommt echte Daten, keine „Beispieltexte”

Das ist der Punkt, der meiner Meinung nach am leichtesten übersehen wird und das Ergebnis am stärksten beeinflusst.

Viele bauen einen Prototyp so, dass sie die KI erst ein „Gerüst” hinstellen lassen — mit Fake-Zeug wie „Überschrift 1”, „Inhaltsplatzhalter”, „¥000,00” drin, in der Annahme „Struktur stimmt, Inhalt kommt später”.

Das mache ich nicht mehr. Schon die erste Version bekommt echte Daten. Beim Ausgaben-Beispiel habe ich sie direkt ein paar Ausgaben voreintragen lassen, die ich gestern wirklich hatte: Frühstück 12, Taxi 28, Lebensmittel 63, und eine, die richtig wehtat — 2000 für einen Kurs, in den ich mein Kind angemeldet habe.

Warum? Weil Fake-Daten dich täuschen. Wenn alles „¥000,00” ist, sieht die Oberfläche schön aufgeräumt aus, und du denkst „passt doch”. Aber sobald du eine echte, unregelmäßig lange Zahl wie „2000” hineinsetzt, kommen die Probleme sofort alle zum Vorschein: Wird der Betrag lang, stößt er rechts an den Bildschirmrand; das Tortendiagramm wird von dieser einen 2000-Buchung so erdrückt, dass die anderen paar kaum noch zu sehen sind; ist ein Kategoriename nur ein bisschen länger, verzieht er das Layout.

Diese Fallen siehst du mit Fake-Daten nicht eine einzige, und nach dem Launch klatschen sie alle den echten Nutzern ins Gesicht. Mit echten Daten kommen sie schon in deiner eigenen ersten Version heraus, und je früher sie herauskommen, desto billiger sind sie zu beheben — jetzt ist es eine Sache von einer Zeile Text, aber wenn du erst nach dem Launch von den Nutzern beschimpft wirst und dann änderst, ist das eine ganz andere Nummer. Meine Gewohnheit heute: Wenn eine echte Zahl geht, dann nie ein Platzhalter, je echter und je extremer desto besser — der längste Name, der größte Betrag, der leerste Zustand (wie sieht die Oberfläche aus, wenn keine einzige Buchung da ist?), all das will ich schon in der ersten Version sehen.

Schritt vier: Auf dem echten Gerät unbedingt selbst einmal durchklicken

Wenn der Prototyp fertig ist, sagt die KI dir meistens sehr selbstbewusst „Erledigt, alle Funktionen sind umgesetzt”.

Glaub diesem Satz kein einziges Wort. Nicht dass sie lügt — sie hat keine Hände gewachsen, sie kann nicht wirklich antippen.

Diese Lektion habe ich bezahlt. Einmal versicherte sie mir hoch und heilig, Buchen, Löschen und Statistik seien alle fertig, ich fand auch in der Code-Logik keinen Fehler, also glaubte ich es. Dann nahm ein Kollege es, fügte eine Buchung hinzu — okay; tippte dann auf diese Buchung, um sie zu löschen — keine Reaktion. Den Löschen-Knopf hatte sie gezeichnet, aber die Aktion „nach dem Antippen wirklich löschen” hatte sie ausgelassen, und sie selbst wusste es überhaupt nicht, sondern meldete mir „Erledigt”.

Seitdem habe ich mir eine eiserne Regel gemacht: Jedes „Ist fertig” zählt erst, wenn ich selbst auf dem echten Gerät den entscheidenden Pfad eigenhändig einmal durchgegangen bin. Eine Buchung hinzufügen, sie in der Liste erscheinen sehen, sie löschen, die Statistik mitwandern sehen — solange ich diese Kette nicht eigenhändig durchklicke, gilt sie als nicht fertig. Dieser Schritt kostet keine drei Minuten, aber er ist die einzige Mauer zwischen dir und dem „Nach dem Launch von den Nutzern entdeckt”.

Wie ich das konkret mache, dafür habe ich auch einen simplen Trick: Bevor ich anfange, schreibe ich auf einen Zettel die zwei, drei entscheidenden Pfade dieses Dings. Beim Ausgaben-Ding habe ich geschrieben: „① eine Buchung hinzufügen und sie sehen können ② eine Buchung löschen können ③ Zahl auf der Startseite und Tortendiagramm wandern mit.” Nur diese drei. Wenn es fertig ist, schaue ich nicht, was die KI sagt, sondern nehme diesen Zettel und gehe Punkt für Punkt auf dem Handy durch. Geht ein Pfad durch, streiche ich ihn; was ich nicht streichen kann, ist nicht fertig.

Unterschätz diesen Zettel nicht. Er zwingt dich, schon vor dem Anfangen klar zu haben, „auf welchen paar Dingen dieses Ding eigentlich steht” — viele verlieren auf halbem Weg den Faden, gerade weil sie diese zwei, drei Hauptpfade nie auf dem Papier festgelegt haben, sich beim Bauen von allerlei Details wegtragen lassen und am Ende einen Haufen Funktionen haben, während ausgerechnet der Kernpfad nicht durchgeht. Erst klar haben, welche paar Pfade durchgehen müssen, dann die KI bauen lassen, und am Ende diese Pfade eigenhändig prüfen — diese zwei Zettel am Anfang und am Ende sind wichtiger als alles, was sie dazwischen an Code geschrieben hat.

Schritt fünf: Die Abnahmelinie ist „Geht es durchzuklicken?”, nicht „Sieht es richtig aus?”

Reiht man die obigen Schritte aneinander, taucht in Wahrheit immer dasselbe Urteil auf: Woran mache ich eigentlich fest, ob dieses Ding taugt?

Meine Antwort für mich selbst lautet: Ob man einen vollständigen Pfad wirklich durchklicken kann, nicht ob es richtig aussieht.

„Sieht richtig aus” ist am leichtesten zu täuschen. Man schickt einen Screenshot in die Gruppe, alle sagen, schick, und vielleicht hat kein Einziger je wirklich eine Buchung erfasst. „Durchklicken können” dagegen ist hart — ein echter Mensch, vom Öffnen über das Erfassen einer Buchung bis zum Sehen des Ergebnisses, ohne unterwegs hängenzubleiben, ohne einen einzigen toten Knopf: Erst wenn dieser Pfad durchgeht, ist das Ding wirklich tragfähig.

Und genau das ist für mich die Stelle, die ein PM im KI-Zeitalter am ehesten halten sollte. Wenn die Kosten des Bauens auf nahezu null gedrückt sind, ist „etwas hinstellen, das ordentlich aussieht” nichts mehr wert, der Bildschirm ist voll davon. Wert hat, ob du noch beurteilen kannst: Ist dieses ordentlich aussehende Ding wirklich benutzbar, oder sieht es nur so aus. Dieses Urteil kann die KI dir nicht abnehmen, denn sie selbst ist genau der Typ, der selbstbewusst „Erledigt” sagt und dabei den Löschen-Knopf auslässt.

Also — soll man nun programmieren lernen oder nicht

Zurück zur Frage vom Anfang.

Meine Antwort lautet: Du musst nicht lernen, wie man Code schreibt, aber du musst lernen, eine Sache so zu sagen, dass die KI sie beim ersten Mal richtig baut — das sind zwei verschiedene Dinge. Ersteres ist das Erlernen eines Handwerks, das gerade an Wert verliert; Letzteres ist das Üben eines immer selteneren Urteilsvermögens: eine vage Idee klar zwingen, immer nur einen Schritt vorantreiben, mit dem Echten prüfen, erst eigenhändig durchklicken und dann glauben.

Diese paar Punkte sind, ehrlich gesagt, kein einziger „technisch”. Sie ähneln eher den Gewohnheiten, die ein Mensch, der klar hat, was er will, und bereit ist, Schritt für Schritt zu prüfen, ohnehin haben sollte. Die KI vervielfacht nur den Ertrag dieser Gewohnheiten um ein Vielfaches — je klarer du denkst, desto präziser gibt sie es dir zurück; je mehr du pfuschst, desto mehr pfuscht sie zurück.

Es gibt auch bei mir bis heute Dinge, die ich nicht durchdacht habe, die werfe ich dir einfach mal hin: Wenn „eine Idee in etwas Klickbares verwandeln” so schnell geht, dass man an einem Nachmittag mehrere Runden hin und her drehen kann — wo genau verläuft dann noch die Linie zwischen einem Product Manager und „einem ganz normalen Menschen, der klar hat, was er will”? Ich suche selbst noch nach der Antwort. Aber eines weiß ich zumindest: Diese Linie liegt nicht beim „Kann man programmieren oder nicht” — bei dem kleinen Ausgaben-Ding letzte Woche habe ich von Anfang bis Ende keine einzige Zeile Code angefasst.