KI im Product-Manager-Workflow: Wo sie hilft, wo sie versagt

Jedes PM-Tool hat inzwischen einen "KI"-Schalter. Notion AI entwirft Ihre PRD. Linear fasst Ihren Sprint zusammen. Productboard extrahiert Themen aus Feedback. Jira schreibt Abnahmekriterien. Der Schalter ist überall, und das meiste, was dabei herauskommt, ist Schrott. Schrott-Specs, die Entwickler ab Woche drei nicht mehr lesen. Schrott-Research-Zusammenfassungen, die das eine seltsame Zitat plattbügeln, das eigentlich die Erkenntnis war. Schrott-Priorisierung, die selbstbewusst Features einstuft, nach denen niemand gefragt hat.

Der PM, der den PRD-Entwurf von Notion AI per Copy-and-paste in Jira kippt, ist der PM, dessen Entwicklungsteam still und leise aufhört, PRDs zu lesen. Ich habe das im letzten Jahr in drei Teams erlebt. Das Muster ist identisch: Der PM wird schneller, das Entwicklungsteam wird stiller, und sechs Wochen später liefert jemand das Falsche aus, weil die Spec von einem Modell geschrieben wurde, das nie einen Kunden getroffen hat.

Das ist also der ehrliche Rahmen. KI ist ein Hebel für die langweilige Mitte Ihres Workflows. Sie ersetzt nicht die zwei Dinge, für die Sie eigentlich bezahlt werden: Urteilsvermögen und Kundenwahrheit. Der Rest dieses Artikels ist die Sicht eines praktizierenden PM darauf, wo KI sich rechnet, wo sie es definitiv nicht tut, welche Workflow-Muster unter Druck standhalten und wie ein 30-Tage-Plan aussieht, um die Routine aufzubauen.

Wo KI hilft (Nutzen Sie sie täglich)

Die langweilige Mitte ist real. Es sind die 60 % der PM-Arbeit, die aus mechanischer Synthese, Entwürfen, Durchsehen und Mustererkennung bestehen. KI ist großartig darin, wenn Sie sie an der kurzen Leine halten.

Synthese von Interview-Transkripten. Das ist der Einstieg mit dem höchsten ROI. Holen Sie sich ein Gong- oder Grain-Transkript, fügen Sie den vollständigen Text in Claude ein (nicht eine Zusammenfassung, den vollständigen Text) und bitten Sie um wörtliche Zitate, gruppiert nach einem bestimmten Thema. Die Prompt-Struktur, die funktioniert: "Extrahiere wörtliche Zitate zu Preiseinwänden aus diesem Transkript. Gruppiere nach Persona, falls mehrere Sprecher beteiligt sind. Paraphrasiere nicht. Wenn ein Sprecher relativiert, behalte die Relativierung bei." Dieser letzte Satz ist wichtig, weil Modelle standardmäßig zu selbstbewussten Zusammenfassungen neigen und Sie dabei die Textur verlieren.

Spec-Entwürfe. Erster Entwurf von User Storys, Grenzfällen und Abnahmekriterien, ausgehend von einem strukturierten Briefing, das Sie selbst geschrieben haben. Das Briefing ist die Arbeit. Der Entwurf ist nur Tippen. Wenn Sie dem Modell Ihre Problembeschreibung, Ihre Annahmen zum Datenmodell und Ihre drei bekannten Grenzfälle vorlegen, spuckt es ein brauchbares Gerüst aus. Sie werden trotzdem die Hälfte davon umschreiben. Das ist in Ordnung. Sie haben sich die Hälfte gespart, die Sie nicht umgeschrieben haben.

Wettbewerbsanalysen. Werfen Sie acht Changelogs von Wettbewerbern in ein Modell und bitten Sie um einen Abgleich mit Ihrer Roadmap. Fragen Sie, welche ihrer Releases ein Kundensegment treffen, das Sie ebenfalls bedienen. Das ist Fleißarbeit, die früher einen halben Freitag verschlungen hat. Jetzt frisst sie 20 Minuten, und die restliche Zeit verbringen Sie damit zu entscheiden, was Sie damit anfangen, was die eigentliche Arbeit ist.

Copy für Fake-Door-Varianten. Sechs Landing-Page-Überschriften für einen A/B test generieren? In Ordnung. Die Strategie hinter der Wahl der richtigen Fake Door generieren? Nicht in Ordnung. Das Modell ist gut an der Oberfläche, schlecht bei der Entscheidung. Nutzen Sie es für die Oberfläche.

Plausibilitätsprüfung der Kohortenanalyse. Fügen Sie eine SQL-Ergebnistabelle ein und fragen Sie: "Was fehlt hier, wogegen würde ein skeptischer Data Scientist Einwände erheben?" Sie bitten nicht um eine Analyse. Sie bitten um ein zweites Augenpaar dafür, ob Ihre Kohorte verunreinigt ist, Ihr Zeitfenster seltsam ist oder Ihr Filter genau die Population ausschließt, auf die es ankommt. Es fängt dumme Fehler ab. Das ist es wert.

Wo KI versagt (Machen Sie das jedes Mal selbst)

Das ist der Teil, den die meisten "KI für PMs"-Artikel überspringen, weil er keine Tools verkauft. Aber das ist der Teil, der darüber entscheidet, ob Sie in zwei Jahren noch Ihren Job haben.

Problem Framing. Der eine Satz, der sagt "Was lösen wir eigentlich und für wen", ist Ihr Job. Immer. Ein Modell produziert ein flüssig klingendes Framing, das wie jedes andere Framing klingt, das es je gelesen hat. Ihres muss spezifisch sein für Ihre Kunden, Ihre Daten, Ihren Moment im Markt. Wenn Ihr Framing klingt, als könnte es auf jedes Unternehmen Ihrer Kategorie zutreffen, haben Sie den wichtigsten Satz der Spec ausgelagert.

Priorisierungsgewichtungen. RICE- und ICE-Zahlen aus einem LLM sind reines Bauchgefühl. Die Reach-Zahl stammt aus einem echten Gespräch mit dem Marketing darüber, welches Segment es nächstes Quartal anvisiert. Die Effort-Zahl stammt aus einem 10-minütigen Gespräch mit Ihrem Tech Lead. Die Confidence-Zahl ergibt sich daraus, mit wie vielen Kunden Sie tatsächlich darüber gesprochen haben. Keine dieser Zahlen existiert in den Trainingsdaten eines Modells für Ihre spezifische Roadmap. Wenn Sie die KI die Scores generieren lassen, haben Sie den am wenigsten wertvollen Teil der Priorisierung automatisiert (die Rechnerei) und den wertvollsten Teil übersprungen (die Abwägungsgespräche, aus denen die Eingangswerte entstanden sind).

Kundenwahrheit. Lassen Sie KI niemals 12 Interviews in 3 Themen zusammenfassen, ohne dass Sie die Rohtranskripte gelesen haben. Modelle komprimieren in Richtung Mittelwert. Die eigentliche Erkenntnis ist fast immer der Ausreißer: der eine Kunde, der etwas gesagt hat, das niemand sonst gesagt hat, auf eine Weise, die Ihre Annahme neu rahmte. Kompression tötet Ausreißer. Lesen Sie die Transkripte. Nutzen Sie KI, um Zitate zu extrahieren, nicht um Schlussfolgerungen zu extrahieren.

Urteile bei Umfangskürzungen. Ein Modell kann jede Option zum Kürzen des Umfangs vor einer Deadline auflisten. Es kann nicht den Raum führen, wenn die Entwicklung erschöpft ist, das Design in der Defensive ist und der GM die ursprüngliche Zusage will. Das ist kein Prompt-Problem. Es ist ein "Sie müssen tatsächlich dabei sein"-Problem.

Workflow-Muster, die wirklich funktionieren

Ein paar Muster, die ich wöchentlich anwende. Keines davon ist clever. Der Punkt ist, dass sie langweilig und wiederholbar sind.

Gong/Grain plus Claude für die Interview-Synthese. Das genaue Muster: Zeichnen Sie das Gespräch auf (Gong, wenn es ein vertriebsnaher Discovery-Call ist, Grain, wenn es reine Forschung ist). Holen Sie sich das vollständige Transkript. Fügen Sie es in eine frische Claude-Konversation ein. Verwenden Sie einen straffen Extraktions-Prompt, keinen Zusammenfassungs-Prompt. Verifizieren Sie, indem Sie das Originaltranskript für die zwei oder drei wichtigsten Zitate lesen, die das Modell hervorgebracht hat. Wenn das Modell irgendetwas Wesentliches paraphrasiert hat, werfen Sie das Ergebnis weg und prompten Sie mit strengerer Sprache erneut. Der Verifizierungsschritt ist die Arbeit. Überspringen Sie ihn, und Sie zitieren einen Kunden mit etwas, das er nicht gesagt hat, was bei einem Stakeholder-Readout ein karrierebeendender Zug ist.

Ein Prompt, der sich rechnet, wörtlich:

Du extrahierst Zitate aus einem Transkript eines Kundeninterviews. Ich füge das Transkript unten ein. Deine Aufgabe: Ziehe jedes direkte Zitat heraus, in dem der Sprecher Preis, Budget oder Beschaffung erwähnt. Paraphrasiere nicht. Fasse nicht zusammen. Bewahre Relativierungen, Füllwörter und Widersprüche des Sprechers exakt. Gib das Ergebnis als Aufzählungsliste mit Zeitstempel zurück, falls verfügbar. Wenn keine relevanten Zitate existieren, sage "keine Zitate gefunden" und erfinde nichts.

Die Zeile "erfinde nichts" ist wichtig. Ohne sie halluzinieren Modelle Zitate, die plausibel klingen.

Cursor als Spec-Beschleuniger. Nur dann nützlich, wenn Ihr Engineering-Team es ebenfalls verwendet. Cursor (oder ein beliebiges KI-Pair-Coding-Tool, das das Team eingeführt hat) bedeutet, dass Entwickler Ihre Spec lesen, während sie im selben Editor Code entwerfen. Wenn sie es nutzen und Sie nicht, driftet Ihre Spec davon ab, wie der Code tatsächlich geschrieben wird. Wenn keiner von beiden es nutzt, in Ordnung, schreiben Sie Specs auf die alte Weise. Die Falle ist der PM, der es allein nutzt und annimmt, dass das Entwicklungsteam die Spec genauso erlebt wie er. Fragen Sie nach. Passen Sie sich ihrem Workflow an.

Die "KI-geschriebene PRD"-Falle. Entwickler erkennen eine gefälschte PRD sofort. Die Anzeichen: generische Grenzfälle ("Netzwerkausfälle elegant behandeln"), Abnahmekriterien, die richtig klingen, aber das tatsächliche Datenmodell verfehlen ("Nutzer kann seine Präferenzen speichern"), und ein verdächtiges Fehlen der unsauberen Details, die daraus entstehen, dass man das Produkt tatsächlich benutzt. Der Geruchstest: Wenn Sie nicht jede Zeile der Spec im Standup verteidigen können, löschen Sie sie vor dem Standup.

Eine PRD-Plausibilitäts-Checkliste, die es sich lohnt durchzugehen, bevor Sie das Dokument ausliefern:

Kann ich den Kunden benennen, der danach gefragt hat, und ihn zitieren?
Kann ich das Datenmodell ohne Notizen auf ein Whiteboard zeichnen?
Verweisen meine Grenzfälle auf unsere tatsächlichen Fehlerzustände, nicht auf generische?
Habe ich mindestens eine Sache aufgeführt, die wir explizit nicht bauen, und warum?
Würde mein Tech Lead diese Spec lesen und etwas lernen, das er nicht schon wusste?

Wenn irgendeine Antwort Nein lautet, ist die Spec zu dünn. KI hat Ihnen nicht geholfen. Sie hat Ihnen geholfen, einen Entwurf auszuliefern, den Sie nicht verteidigen können.

Die Perspektive des ACE-Frameworks (Optional)

Wenn Sie genug Strategie-Decks lesen, stoßen Sie auf das ACE-Framework: Ingest, Analyze, Predict, Generate, Execute. PMs sitzen am nächsten an Analyze und Generate (Synthese und Entwürfe). Genau dort liegt der Hebel dieses Artikels. Ingest (Daten-Verkabelung, ETL, Embedding-Pipelines) gehört normalerweise zum Data Engineering. Execute (die Workflow-Automatisierung, die ohne einen Menschen im Loop läuft) gehört normalerweise zu Ops oder Platform.

Sie müssen das nicht auswendig lernen. Aber es lohnt sich, das Vokabular zu kennen, denn in dem Moment, in dem KI-Features auf Ihrer Roadmap landen, werden Ihre Eng-Leads und Ihr Data-Team diese Wörter verwenden. Sie ersparen sich ein Meeting, wenn Sie bereits wissen, welche Capability Sie kaufen statt bauen.

Ihr 30-Tage-Plan, um die Routine aufzubauen

Vier Wochen. Ein Workflow nach dem anderen. Kein Tool-Wildwuchs. Der Punkt ist, einen kleinen Satz wiederholbarer Schritte aufzubauen, denen Sie unter Deadline-Druck vertrauen.

Woche 1: Wählen Sie einen Workflow und führen Sie ihn zweimal durch. Die Transkript-Synthese ist der Einstieg mit dem höchsten ROI. Wählen Sie ein Kundeninterview aus dieser Woche. Synthetisieren Sie es zuerst manuell. Lesen Sie das Transkript, schreiben Sie die drei Dinge auf, die Sie überrascht haben, listen Sie die wörtlichen Zitate auf, die sie stützen. Lassen Sie dann dasselbe Transkript mit einem Extraktions-Prompt durch Claude laufen. Vergleichen Sie. Sie lernen zwei Dinge: wo das Modell Geschwindigkeit hinzufügt und was es stillschweigend weglässt. Beides ist wichtig.

Woche 2: Schreiben Sie Ihre eigene Prompt-Bibliothek. Vier bis sechs Prompts, versioniert in einem geteilten Dokument. Einen für die Transkript-Extraktion. Einen für das Spec-Gerüst aus einem Briefing. Einen für die Wettbewerbsanalyse. Einen für die SQL-Plausibilitätsprüfung. Vielleicht einen für Fake-Door-Copy-Varianten. Das war's. Wenn Sie mehr als sechs Prompts haben, sammeln Sie Tools, statt sie zu nutzen. Jeder Prompt sollte ein klares Eingabeformat, ein klares Ausgabeformat und eine einzeilige Notiz dazu haben, was vor dem Vertrauen auf die Ausgabe zu verifizieren ist.

Woche 3: Zeigen Sie es einem Teammitglied. Geben Sie Ihre Prompts an einen anderen PM oder Ihren Tech Lead weiter. Bitten Sie ihn, einen davon bei einer echten Aufgabe zu nutzen. Wenn er Ihre Ausgabe nicht reproduzieren kann, ohne dass Sie danebenstehen, ist der Prompt zu spröde. Spröde Prompts sind eine einzelne Schwachstelle. An dem Tag, an dem Sie krank sind, stoppt Ihr Workflow. Verschärfen Sie den Prompt, bis er übertragbar ist.

Woche 4: Audit. Zwei Spalten. Linke Spalte: was KI Ihnen diesen Monat gespart hat (Stunden, beschleunigte Entscheidungen, Entwürfe, die Sie nicht tippen mussten). Rechte Spalte: was sie Sie an Vertrauen gekostet hat, bei der Entwicklung, bei Kunden, bei Ihrem eigenen Urteilsvermögen. Seien Sie ehrlich. Wenn ein Prompt eine Spec produziert hat, gegen die die Entwicklung Einwände hatte, schreiben Sie das auf. Wenn eine Synthese einen Ausreißer verpasst hat, den Sie später bemerkten, schreiben Sie das auf. Streichen Sie, was sich seinen Platz nicht verdient hat. Behalten Sie, was es getan hat. Jetzt haben Sie einen Workflow, kein Bauchgefühl.

Ich habe eine Version davon letztes Quartal bei einem Discovery-Zyklus ausprobiert. In Woche 1 war ich misstrauisch. Bis Woche 3 hatte ich meine Interview-Synthesezeit etwa halbiert, ertappte mich aber dabei, fast eine Themenzusammenfassung auszuliefern, die ich nicht gegen die Rohtranskripte verifiziert hatte. Beim Audit in Woche 4 blieb der Synthese-Prompt. Der Prompt "fasse 12 Interviews in Themen zusammen" wurde gelöscht. Das ist die Routine.

Das leise Schlussplädoyer

Die PMs, die die nächsten zwei Jahre gewinnen, sind nicht diejenigen, die die meiste KI nutzen. Es sind nicht diejenigen mit dem längsten Tool-Stack oder der meistgelikten Prompt-Bibliothek auf Notion. Es sind diejenigen, die genau wissen, wo KI aufhört zu funktionieren, und diese Teile des Jobs schützen. Problem Framing. Priorisierungsgewichtungen. Kundenwahrheit. Urteile unter Deadline-Druck.

Alles andere ist Freiwild. Nutzen Sie die Tools. Sparen Sie die Zeit. Aber verbringen Sie die gesparte Zeit mit den Teilen des Jobs, die ein Modell nicht erledigen kann: bei einem Kunden zu sitzen, bis Sie wirklich verstehen, was er sagt, im Raum für die richtige Umfangskürzung zu kämpfen, den einen Satz an die Spitze der Spec zu schreiben, der die nächsten 12 Wochen des Teams kohärent macht.

Das ist die Arbeit. KI ist ein Hebel, kein Ersatz.

Product Manager Playbooks