Ich habe 3 AI-Demos erstellt, warum bekomme ich trotzdem keine Einladung zu einem Vorstellungsgespräch?

Drei funktionierende AI-Demos führen trotzdem nicht zu einem Vorstellungsgespräch? Das Problem liegt nicht in der Anzahl der Projekte, sondern darin, dass deine eigenen Überlegungen im Projekt fehlen. Ausgehend von den Auswahlkriterien für AI-Produktmanager werden in diesem Artikel vier ineffektive Demos analysiert, eine 8-Punkte-Checkliste bereitgestellt und gezeigt, wie du Projekte so in deinen Lebenslauf aufnimmst, dass der Interviewer dein Produktdenken und deine Fähigkeit zur Abwägung von Vor- und Nachteilen erkennt.

Ich habe drei Demos erstellt: ein RAG-System, ein Agent und ein Low-Code-Assistent. Die Links lassen sich öffnen, die Abläufe funktionieren einwandfrei, aber nach dem Versenden des Lebenslaufs gibt es kaum Rückmeldungen.

Viele Menschen glauben, das Problem sei unzureichende Projekterfahrung, also wechseln sie das Modell, fügen mehrere Tools hinzu und erstellen einen komplexeren Workflow. Aber Unternehmen suchen nicht nach solchen Dingen, sondern nach Personen, die das Projekt verständlich erläutern können.

Ich arbeite seit über zehn Jahren im Produktbereich und habe viele Dinge gesehen, die „bei der Demonstration toll aussehen, aber bei der tatsächlichen Nutzung Probleme bereiten“. Besonders bei AI-Projekten passiert das leicht: Bei der Demo sind die Eingaben vorbereitet, die Daten sauber und die Abläufe durchdacht, aber im echten Einsatz werden die Nutzer nicht so kooperativ sein.

Deshalb bekommt man trotz drei funktionierender Demos keine Einladung zum Vorstellungsgespräch – das Problem liegt wahrscheinlich nicht in der Anzahl, sondern darin, dass dein eigener Mehrwert im Projekt nicht sichtbar wird.

1. Ein funktionierender Demo beweist nur die Hälfte

Ein im Lebenslauf häufig zu findender Satz lautet:

Ich habe selbstständig ein intelligentes Kundenservice-System aufgebaut, das an ein großes Sprachmodell und eine Wissensdatenbank angeschlossen ist, um mehrstufige Frage-Antwort-Prozesse zu realisieren und die Effizienz des Kundenservices zu steigern.

Dieser Satz ist nicht falsch, aber er lässt viele Fragen unbeantwortet. Welche Art von Problemen löst der Kundenservice täglich? Warum wird eine Wissensdatenbank verwendet und keine Suchmaschine? Was passiert, wenn die Daten aktualisiert werden? Welche Konsequenzen hat eine einzige falsche Antwort? Welcher Schritt wird durch die „Effizienzsteigerung“ konkret eingespart?

Wenn es keine Antworten auf diese Fragen gibt, bleibt vom Projekt am Ende nur eine Liste von Tool-Namen übrig.

Jaclyn Konzelmann, Leiterin des AI-Produktbereichs bei Google, hat öffentlich die Aufgaben geteilt, mit denen sie AI-Produktmanager auswählt. Eine davon bittet die Bewerber, den selbst erstellten AI-Workflow zu analysieren und vor allem über das unerwartetste Misserfolg und die anschließende Anpassung des Designs zu berichten.

Diese Aufgabe verlangt nicht, dass Bewerber das Architekturdiagramm auswendig lernen. Sie will herausfinden: Hast du das System wirklich bis an seine Grenzen getestet?

Das Projekt muss nicht groß sein. Auch ohne Daten aus dem offiziellen Betrieb ist das kein Problem. Du solltest mindestens drei Dinge klar erklären können: Warum du das Projekt erstellt hast, wo du Fehler gemacht hast und woran du erkannt hast, dass die Anpassung erfolgreich war.

2. Vier wenig aussagekräftige Demo-Typen

1. Universelle Assistenten

Er kann Dateien lesen, im Internet surfen, Inhalte zusammenfassen, E-Mails senden und ein kleines bisschen alles. Die Demonstration wirkt lebendig, aber die Nutzer wissen nicht, wem genau er welche Zeit einspart.

Wenn du den Anwendungsbereich eingrenzt, bekommt das Projekt erst Inhalt. Wenn du zum Beispiel einen Assistenten erstellst, der nach Vertriebsbesuchen die Einwände der Kunden zusammenfasst, stößt du auf eine Reihe praktischer Probleme: Lassen sich die unausgesprochenen Gedanken des Kunden ableiten? Müssen die zugesagten Termine im Originalwortlaut festgehalten werden? Wer muss die Inhalte bestätigen, bevor sie zurück in das System geschrieben werden? Das sind erst die eigentlichen Produktaufgaben.

2. Nur mit Screenshots von erfolgreichen Ergebnissen

Du selbst hast die Wissensdatenbank getestet und kennst sie am besten. Du weißt, was in den Dokumenten steht und vermeidest bei Fragen natürlich schwierige Fragestellungen.

Wenn eine andere Person das System nutzt, besteht die Frage vielleicht nur aus einem Halbsatz, es gibt zwei Versionen der Dokumente und in der Antwort fehlt eine wichtige Bedingung. Das Modell kann trotzdem einen vollständigen Text ausgeben, aber Vollständigkeit bedeutet nicht Richtigkeit.

Füge in dein Portfolio auch ein Beispiel für eine fehlgeschlagene Ausgabe ein und erläutere, worin der Fehler lag: Fehlende Informationen in der Eingabe, falsch abgerufene Dokumente, unzureichend eingeschränkte Prompts oder keine Möglichkeit für den Nutzer, Fehler über die Oberfläche zu korrigieren. Das ist viel nützlicher als ein weiterer Screenshot eines erfolgreichen Ergebnisses.

3. Nur mit Funktionen, ohne Bewertung

Aussagen wie „hohe Genauigkeit“, „gutes Nutzungserlebnis“ oder „grundsätzlich funktionsfähig“ lassen sich nicht nachprüfen.

Bei Frage-Antwort-Produkten kannst du prüfen, ob die Zitate mit dem Originaltext übereinstimmen und ob bei unzureichenden Informationen nachgefragt wird. Bei Inhaltsgenerierung kannst du die Erfolgsrate pro Durchgang, die Anzahl der erforderlichen Änderungen und die Kosten pro Abfrage dokumentieren. Bei Agent-Systemen solltest du prüfen, ob die Aufgabe abgeschlossen wurde, ob die richtigen Tools ausgewählt wurden und ob das System anhält, wenn ein menschlicher Eingriff erforderlich ist.

Verlass dich nicht nur auf den Durchschnittswert. Bei zehn Versuchen neun richtige Antworten, aber bei dem zehnten werden wichtige Informationen umgekehrt dargestellt – der Nutzer wird sich normalerweise nur an diesen Fehler erinnern. Das Gleiche gilt für lange Ablaufketten: Jeder einzelne Schritt funktioniert halbwegs, aber wenn sie zusammen ausgeführt werden, kann das Ganze nicht mehr funktionieren.

4. Kein Bezug zu früheren Berufserfahrungen

Wenn du zu AI wechselst und alle Projekte der letzten drei Jahre aus deinem Lebenslauf löschst und nur noch Begriffe wie Prompt, RAG und Agent übrig lässt, wirken deine Projekte wie kurzfristige Hausaufgaben.

Wenn du Erfahrung im E-Commerce hast, kannst du das Projekt im Bereich Produktdaten, Kundenservice oder Produktauswahl ansiedeln. Wenn du im Content-Bereich gearbeitet hast, fokussiere dich auf Suche, Prüfung oder Erstellungshilfen. Wenn du im Unternehmensdienstleistungsbereich tätig warst, kannst du bei Wissensdatenbanken, Vertriebsunterstützung oder Prozessautomatisierung anknüpfen. Deine Erfahrungen mit unsauberen Daten, Zugriffsrechten und Reibungsverlusten bei der Zusammenarbeit im jeweiligen Geschäftsfeld sind mehr wert als eine Liste von Tool-Namen.

3. 8-Punkte-Checkliste

Du musst das Projekt nicht noch einmal deutlich umfangreicher machen, prüfe zuerst, ob diese acht Punkte vollständig sind:

Problem: Wer trifft in welchem Szenario auf welche Schwierigkeit.

Grenzen: Was die KI erledigen kann und was nicht.

Minimalversion: Ob der wichtigste Ablauf funktionieren kann.

Beweise: Speichere Eingaben, Ausgaben und wichtige Entscheidungen.

Bewertung: Welcher Zustand gilt als erfolgreich.

Fehlertests: Teste absichtlich unklare Eingaben, fehlende Daten und lange Ablaufketten.

Iteration: Erläutere, was du geändert hast und warum.

Darstellung: Fasse das Projekt zu einer einseitigen Fallbeschreibung zusammen und füge einen funktionierenden Link hinzu.

Das soll nicht heißen, dass du einen langen Artikel zum Teilen schreiben musst. Ein fehlgeschlagenes Beispiel zusammen mit der Fehlerursache, der durchgeführten Änderung und dem Ergebnis des erneuten Tests ist schon viel konkreter als die Aussage „Prompts optimiert, um die Genauigkeit zu steigern“.

Auch Zahlen brauchen eine Herkunft. Wenn es keine echten Betriebsdaten gibt, gib an, dass es sich um Offlinetests handelt. Wenn das Projekt nicht online gestellt wurde, schreibe, dass es sich im Prototypstadium befindet. Wenn die Annahmen noch nicht überprüft wurden, sag das offen. Persönliche Projekte müssen nicht so tun, als wären sie bereits im Produktiveinsatz.

4. Projekte im Lebenslauf darstellen

Bei den Projekttiteln im Lebenslauf nenne zuerst das Geschäftsobjekt, dann die technische Lösung. Zum Beispiel ist „Frage-Antwort-Prototyp für Kundendaten für das Vertriebsteam“ viel verständlicher als „Intelligentes Frage-Antwort-System auf RAG-Basis“.

Für die Projektbeschreibung reichen vier Punkte: Welches Problem gelöst werden soll, welche wichtige Entscheidung du getroffen hast, wie du das Ergebnis überprüfst und welche Mängel das Projekt aktuell noch hat.

Beim Vorstellungsgespräch solltest du nicht links am Architekturdiagramm anfangen vorzulesen. Der Interviewer wird dich eher fragen: Warum hast du genau dieses Szenario ausgewählt? Warum verwendest du keine normale Suchmaschine? Welche Folgen hat eine falsche Antwort? Warum hast du zuerst die Abrufkomponente angepasst und nicht zuerst das Modell gewechselt? Welche Schritte müssen unbedingt von einem Menschen ausgeführt werden?

Abwägungen sind aussagekräftiger als eine Liste von Funktionen. Zum Beispiel einen Teil des Agent-Ablaufs zu entfernen, um die Stabilität zu erhöhen, den Kontext zu kürzen, um Kosten zu sparen, oder Hochrisiko-Aktionen zur menschlichen Bestätigung vorzusehen, um die Sicherheit zu gewährleisten – solche Entscheidungen haben keine allgemeingültige richtige Antwort, aber sie zeigen, ob du wirklich als Produktmanager arbeitest.

Außerdem solltest du eine Version vorbereiten, in der die ursprüngliche Lösung nicht mehr funktioniert. Bei öffentlichen Vorstellungsgesprächen für AI-Produktmanager gibt es eine Aufgabe, die annimmt, dass nach einem Modell-Update ein einziger API-Aufruf die ursprünglichen Kernfunktionen vollständig übernimmt – du sollst erläutern, wie das Produkt und das Team neu ausgerichtet werden.

Das verlangt nicht von dir, die Zukunft vorherzusagen.

Nach einem Modell-Update werden viele Tricks von gestern zu grundlegenden Funktionen, sodass der Mehrwert des Projekts neu definiert werden muss. Was am Ende wirklich bleibt, ist meist dein Verständnis für das Szenario, die Nutzerfeedback und die Geschäftsprozesse.

Wenn drei funktionierende Demos immer noch keine Einladung zum Vorstellungsgespräch bringen, erstelle nicht gleich einen vierten Demo. Nimm einen der vorhandenen Demos, suche nach einer Eingabe, die tatsächlich zu Problemen geführt hat, teste sie gründlich, notiere die Fehlerursache und die Lösung – nur so kannst du das Problem grundsätzlich beheben.

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „Jeder ist ein Produktmanager“ (ID: woshipm), Autor: Yiyan, veröffentlicht mit Genehmigung von 36kr.