Wie KI Produktmanager über ihre Rolle hinaus antreibt

Der Weg ins Produktmanagement

Ich bin seit über 15 Jahren Produktmanager. Früher in meiner Karriere habe ich alles Mögliche gemacht – Design, Vertrieb, Beratung, Marketing und sogar Programmieren in den PHP-Tagen – igitt.

Zum Produktmanagement bin ich gekommen, weil ich es mochte, zwischen verschiedenen Themenbereichen zu wechseln und mit Nutzern, Entwicklern, Führungskräften usw. zusammenzuarbeiten. Außerdem hatte ich ein gutes Auge für Design und ein gutes Gespür für Produkte. Nach umfangreicher Recherche fand ich heraus, dass es eine Rolle gab, die all das sehr gut zusammenbrachte – das Produktmanagement. Also habe ich mich auf meine erste PM-Stelle beworben und so bin ich hier gelandet.

Ich habe in allen möglichen Branchen gearbeitet: B2B, B2B2C, Einzelhandel und Verbrauchersoftware. Vor über zehn Jahren begann ich, Produktmanagement bei General Assembly zu unterrichten. Danach habe ich eigene Online-Kurse unabhängig bei Udemy und später bei LinkedIn Learning veröffentlicht. Heute habe ich über beide Plattformen hinweg mehr als 1,6 Millionen Studierende. Außerdem habe ich auf vielen Konferenzen über Produkt- und Projektmanagement gesprochen und unter anderem zusammen mit Google einen Produktkurs in Kiew, Ukraine geleitet.

Zurzeit arbeite ich mit Probably.dev, einer von a16z finanzierten deterministischen Daten-Agenten-App. Wir sind ein kleines Team, daher bin ich nicht nur PM, sondern auch Entwickler, Vertriebsmitarbeiter, Designer usw.

Unsere App ist eine native Desktop-Anwendung, die deterministische Datenwissenschaft auf Promotionsniveau samt unterstützender Visualisierungen betreibt, um jede beliebige natürliche Sprachabfrage direkt zu beantworten, ohne dass sensible Daten den eigenen Rechner verlassen. Man kann sie sich als einen „Daten-Copiloten" vorstellen. Wir arbeiten direkt auf Datenschema-Basis von Data Warehouses (z. B. BigQuery, Snowflake, Clickhouse usw.) und auch mit lokalen Dateien wie CSV, JSON und Parquet. Alle Antworten unseres Agenten sind von Menschen nachvollziehbar und reproduzierbar, sodass typische LLM-Halluzinationen kein Problem sind. Es ist nicht einfach ein weiterer SQL-Generator-Agent, und wir können Milliarden von Zeilen/Spalten und komplexe Schemata mit zehntausenden Tabellen verarbeiten.

You should also read

• Das ultimative Glossar der Projektmanagement-Begriffe

• 12 Best Practices für Remote-Projektmanagement im Jahr 2026

• Was ist digitales Projektmanagement? [Ultimativer Leitfaden]

Wie KI Teams hilft, mehr pro Person zu schaffen

KI hat meine Arbeit stark beeinflusst. Früher war ich „nur ein PM". Das klingt seltsam, weil PMs ohnehin so viel machen, aber jetzt kann ich auch in Bereichen wie Entwicklung und Vertrieb beitragen. Das beschleunigt das Team. Da KI das Projektmanagement transformiert, werden die traditionellen Rollengrenzen immer durchlässiger.

Zeitintensive Aufgaben wie Recherche und Analyse gehen viel schneller, und diese Zeitersparnis sorgt dafür, dass deutlich mehr Austausch und Kommunikation mit Stakeholdern möglich ist. Zudem werden Entscheidungen schneller getroffen.

Ein großer Teil der PM-Aufgabe ist es, dafür zu sorgen, dass alle anderen effektiv arbeiten können. Dadurch, dass ich selbst noch mehr beitragen kann, schaffen wir pro Kopf viel mehr. Dieser Mensch-KI-Hybrid-Ansatz wird für moderne Delivery-Teams immer wichtiger.

Warum ein tiefes Verständnis von KI Produktmanagern fast alles ermöglicht

Je tiefer ich einsteige, desto mehr realisiere ich, wie steil die Lernkurve für den effektiven und effizienten Einsatz von KI/LLMs wirklich ist – sowie die Unterkompetenz, den Einsatz nahtlos in die bevorzugten Workflows der eigenen Umgebung oder des Teams zu integrieren. Das bestätigt meine Überzeugung, dass wirklich jede Person im Unternehmen nicht nur LLMs generell und die verfügbaren Modelle kennen sollte, sondern auch all die umgebenden Tools im Ökosystem wie MCPs, Modalitäten wie CLI, GUI – und am wichtigsten: die Transformer-Architektur. Wer sein Wissen vertiefen will, sollte einen Blick in Bücher zum KI-Projektmanagement werfen, um wertvolle Einblicke zu erhalten, wie sich solche Technologien implementieren lassen.

Mit KI zurechtzukommen im Meer der heutigen KI-Beliebigkeit – egal ob Inhalte oder Tools – ist eine Fähigkeit, die nur mit Erfahrung wächst. Man muss verstehen, wie LLMs funktionieren und was sie können und eben nicht können, um sie optimal einzusetzen.

Viele „bahnbrechende" SaaS-Produkte und Tools erscheinen zwar als gute Lösungen – z. B. PRDs zu erstellen – aber ich habe festgestellt, dass 99 % von all dem, was man tun muss, selbst günstiger, schneller, individueller und weitaus besser erledigt werden können. Vorausgesetzt, man versteht die angesprochenen Konzepte und kann LLMs kompetent nutzen.

Es ist wie bei diesen Teleshopping-Werbespots, wo jemand etwas Einfaches macht, dann gezeigt wird, wie „kompliziert" das ist, und dann ein Gerät verkauft werden soll, das genau dieses kleine Problem löst. Statt einfach eine Banane mit einem Messer zu schneiden wie jeder andere, soll man sich einen bananenförmigen Schneider kaufen, der alle Stücke in einem Zug schneidet...

Das Messer ist ein LLM und der Bananenschneider eine überflüssige Nischen-App. Lerne, das verdammte Messer zu benutzen. Kaufe dir ein qualitativ hochwertiges, benutze es, mache dich damit vertraut, und hör auf, nach sinnlosem Zeug zu suchen, nur weil dir das Tech-Twitter erzählt, dass irgendeine zufällige SaaS-App jetzt „Designer überflüssig gemacht“ oder „das Programmieren getötet“ habe.

Es gibt im Grunde nichts, was du mit einem LLM über die Kommandozeile, im Webbrowser und gelegentlich mit einem offenen, aufgabenunabhängigen Automatisierungstool wie n8n nicht erledigen könntest.

Spar dein Geld und lerne, Dinge zu bauen, die die Weisheit deiner gesammelten Erfahrungen widerspiegeln, statt das Ergebnis eines über Nacht entstandenen, kurzlebigen SaaS-Tools zu akzeptieren.

Die einzige Ausnahme hiervon sind Werkzeuge mit einem einzigen Zweck, die speziell dafür gemacht sind, Probleme zu lösen, bei denen die Transformer-LLM-Architektur in einfachen Frontier-Modellen (also nicht feinjustiert) grundlegend Schwächen aufweist. Zum Beispiel im Bereich großangelegter Datenwissenschaft oder Mathematik.

Wie man als Produktmanager mit dem Lernen zu KI beginnt

Das Beste an LLMs ist, dass du sie fragen kannst, wie du mehr über sie lernen kannst. Wenn du wie ich ein visueller Lerntyp bist, ist YouTube das Sahnehäubchen – dort gibt es eine Fülle guter Ressourcen zu KI und LLMs.

Wenn ich noch einmal neu anfangen würde, würde ich den Lernprozess so angehen: Sage einem LLM, dass du alles über den Bereich KI/LLM lernen möchtest – auf dein aktuelles technisches Verständnis abgestimmt. Du kannst es sogar so anweisen, dir immer technischere Fragen zu stellen, um dein aktuelles Niveau im Bereich KI/LLM zu erfassen, beginnend mit den Grundlagen. Und wenn du an einen Punkt kommst, an dem du nicht mehr weiterweißt, kannst du dir Themen vorschlagen lassen, die du lernen solltest – von den Grundprinzipien der Transformer-Architektur bis hin zur Funktionsweise einer App wie ChatGPT.

Die Idee ist, eine Liste von Themen zu erhalten, zu jedem auf YouTube nach Videos zu suchen und so jedes Thema zu verstehen.

Beispiel für einen Prompt:

Agiere als mein KI/LLM-„Startpunkt“-Beurteiler.

Stelle mir bis zu 12 Fragen (eine Mischung aus einfachen und technischen), um einzuschätzen:

• mein generelles technisches Gespür (Programmierung, Daten, APIs)
• mein Verständnis davon, wie LLMs funktionieren (Modi wie CLI, GUIs, sowie Tokens, Kontext, Halluzinationen usw.)
• meine Vertrautheit mit modernen LLM-App-Mustern (RAG/Embeddings, Agents/Tool-Nutzung)
• meine Fähigkeit, Qualität zu beurteilen (Evaluierung, Verifizierung)
• mein Bewusstsein für Risiken (Datenschutz, Prompt Injection usw.)
• mein Bewusstsein für KI-Einschränkungen (gute vs. schlechte Anwendungsfälle für LLMs, Genauigkeit, unkontrollierbare Natur von LLM-Ausgaben usw.)

Nachdem ich geantwortet habe, gib NUR aus:

• 5–10 Stichpunkte der YouTube-Themen mit dem höchsten Mehrwert, die ich als nächstes lernen sollte, nach Priorität sortiert. Jeder Punkt muss ein YouTube-Suchbegriff sein (kein ganzer Satz) + eine 5–10 Wörter lange Begründung, warum das Thema wichtig ist.

Starte jetzt mit deinen Fragen.

Welche KI-Skills sollten Produktmanager zuerst lernen?

Meiner Meinung nach ist es wichtig zu verstehen, wo und wie man LLMs einsetzen kann. Damit meine ich zu verstehen, dass sie in einer App genutzt werden können, alternativ in deinem Computer-Terminal oder als Code innerhalb einer Automatisierung per MCPs oder APIs.

Zweitens musst du unbedingt begreifen, dass sie:

1. Nicht-deterministisch, unkontrollierbar und anfällig für Fehler sind
2. Niemals für verlässliche Informationen, insbesondere bei kritischen Entscheidungen, herangezogen werden sollten
3. Kreativ automatisiert werden können, um die Auswirkungen der beiden vorherigen Punkte – je nach Anwendungsfall – zu verringern

Ein klassisches Beispiel, das ich immer gebe: Niemals ein LLM bitten, den ganzen Aufsatz für dich zu schreiben – aber durchaus um ein paar Ideen bitten, in welche Richtung du als nächstes gehen könntest, wenn du an einem Punkt nicht weiterkommst. Anders gesagt: LLMs sind großartige Begleiter für den menschlichen Verstand, aber es ist gefährlich, wenn sie das vollständige Denken für den Menschen übernehmen sollen.

Der letzte Punkt, den ich hier erwähnen möchte: Während du diese Konzepte lernst, solltest du sie auch praktisch ausprobieren. Wenn du zum Beispiel etwas über Prompt Engineering lernst, solltest du ein und dieselbe Frage auf zwei verschiedene Arten an ein LLM stellen, um die Unterschiede in der Ausgabe zu sehen. Niemals nur theoretisch lernen – der Praxisteil muss immer dazu gehören.

Warum man hochwertige Kundeninteraktionen nicht mit KI automatisieren sollte

Sobald du das nötige Wissen hast, kannst du grundsätzlich alles machen. Aber das bedeutet nicht, dass du es auch machen solltest.

Gerade für ein junges Unternehmen mit einem Premium-Produkt erscheinen Kundenkontakte und Vertrieb am „reifsten“ für KI und Automatisierung. In der Praxis jedoch habe ich festgestellt, dass der menschliche Faktor absolut notwendig ist. Für mich ist der Kontakt mit Nutzern oder potenziellen Kunden ein riesiger Mehrwert für beide Seiten, und ich will das nicht einmal versuchen zu automatisieren.

Als PM würdest du dir selbst keinen Gefallen tun, wenn du dich in irgendeiner Form davon distanzierst, mit Nutzern zu sprechen. Je mehr du persönlich mit ihnen mit deiner eigenen Stimme sprichst, desto mehr Informationen gewinnst du, und desto mehr Vertrauen schaffst du.

Warum es schwierig — aber möglich — ist, dass Produktmanager zum Code beitragen

Ich bin also vorsichtig damit, wofür ich KI einsetze, aber ich nutze sie sehr häufig.

Zum Beispiel gibt es direkt vor einem Release auf Prod immer eine Bugfix-Hektik. Typischerweise übernehmen in einem größeren Unternehmen die Entwickler und das QA-Team diese letzten Handgriffe. Natürlich bleibt die leitende Produktperson im Loop, aber sie plant zugleich die nächsten Schritte und Strategien zur Begleitung des Releases, sammelt Nutzerfeedback, bereitet mehrere Zyklen im Voraus vor oder sammelt Metriken, sobald das Feature oder Produkt live ist.

Da ich derzeit in einem kleineren Unternehmen arbeite, hat sich für mich herausgestellt, dass es ein riesiger Vorteil ist, zusammen mit den Entwicklern Bugs zu beseitigen – und das konnte ich einzig durch den Einsatz von KI/LLMs erreichen.

Ich war in meiner Karriere zwar immer in das QA von Produkten und Features involviert, hatte aber selten die Chance, wirklich mit ins Getümmel zu gehen und einen Bug zu beheben, der Codeänderungen durch den gesamten Stack erforderte.

Erfahrene Tech-Leute wissen, dass Entwickler sehr auf ihren eigenen Code und die Einhaltung von Coding-Standards achten. Selbst wenn du technisch weißt, wie ein bestimmter Bug zu beheben ist, benötigst du ebenso Kontext zu den Coding-Standards und den Persönlichkeiten des Entwicklerteams – sowie Kenntnis darüber, welche Entwickler an welchen Codeabschnitten gearbeitet haben. Manche Bugs zu beheben ist also um mehrere Ecken komplizierter, selbst wenn du weißt, wie es geht, und die meisten Entwickler würden deinen Pull Request für den Fix vermutlich belächeln.

Dank KI ist es mir jedoch gelungen, nicht nur direkt zum Code beizutragen, indem ich direkt auf main pushe, sondern auch die sekundären kulturellen Faktoren zu berücksichtigen.

Wie du einen KI-Agenten aufbaust, der sicher zu deinem Code beiträgt

Mein erster Ansatz war, ein Markdown-Dokument für Coding-Standards zu erstellen, indem ich einen Agenten-Schwarm in Claude Code das gesamte Repository der letzten sechs Monate durchforsten ließ, um den Coding-Stil, die Claude.md-Datei sowie vor allem alle Kommentare zu GitHub-Diffs, Konfliktlösungen, Commits und Änderungen an PRs zu analysieren.

So entstand ein ziemlich solides Dokument mit Coding-Standards, das ich dann umwandelte, indem ich es in Claude Code in eine Sammlung von Fähigkeiten und Befehlen verwandelte, womit von mir generierter Code bei Bugfixes stets mit den bereits etablierten Standards im Codebase abgeglichen wurde. Anschließend erstellte ich einen weiteren Sub-Agenten, der über Hooks mit GitHub arbeitete und den ich auch manuell auslösen konnte, damit er den von mir geschriebenen Code sowie Kommentare oder Korrekturen prüfte und all dies als Ergänzung in das Coding-Standards-Dokument aufnahm.

Bereits nach wenigen PRs konnte der von mir generierte Code für einen gegebenen Fix sehr leicht in die Art von Code übersetzt werden, die wir im Codebase sehen wollen – und zwar durch ein einfaches Markdown-Dokument, das im Grunde ein sich ständig verbessernder und selbstlernender Coding-Style-Guide war, der durch mehrere Cronjobs und Automatisierungen mit Claude Code ausgelöst wurde.

Der Agent ist mittlerweile so ausgereift, dass ich direkt auf main mergen kann.

Wie kleine Produktteams ihre Agilität erhöhen können

Das ist ein gutes Beispiel dafür, wie ich über die traditionelle PM-Rolle hinausgehe. Aber dafür braucht es gute Prozesse.

Wir haben ein gut gepflegtes und getaggtes Backlog in Linear und halten verpflichtende Meetings am Montag-, Mittwoch- und Freitagmorgen ab. An Tagen ohne Sync-Meeting aktualisieren wir uns per Slack-Standup-Check-in. Sämtliche weitere Priorisierung und Diskussion laufen in Echtzeit über Slack ab.

Für größere Unternehmen mag das eventuell nicht die beste Lösung sein, aber du würdest staunen, wie gut das für diesen Anwendungsfall funktioniert und wie agil es uns hält. Früher habe ich Google Drive, Tabellen, Dokumente, Präsentationen und unzählige andere Apps verwendet. Jetzt kommen wir als kleines Team mit GSuite, Slack, Linear und GitHub aus.

Leichtgewichtige PM-Methoden sind in diesem sich ständig weiterentwickelnden KI/LLM-Bereich wichtig. Es kann jederzeit in der Woche passieren, dass Nutzerfeedback oder ein Release von potenziellen Wettbewerbern kommt, auf das wir schnell reagieren und neu priorisieren müssen.

Wie KI Produktteams dazu zwingt, Rituale neu zu überdenken

Was Rituale betrifft, ist die größte Veränderung, dass es mittlerweile wirklich ein kreisförmiges, nie endendes Ritual ist – statt stagnierender Dokumente, die man beständig erstellen und nachschlagen muss.

Der Scope beginnt als präzises Linear-Ticket mit variabler Detailtiefe; dann nutze ich KI, um es auf Unklarheiten, Sonderfälle und verschiedene Ablaufszenarien zu testen, und schärfe es nach, bis es im kleinstmöglichen Schritt verschiffbar ist.

Für uns als kleines, remote arbeitendes Team findet die Abstimmung meist asynchron statt – in einem kurzen Slack-Thread, der in einer klaren Entscheidung und nächsten Schritten mündet, unterstützt durch schlanke Standups via Geekbot. Es hat jedoch großen Wert, sich ein paar Mal pro Woche als Team in Meetings auszutauschen und die Stimmung zu stärken.

Beim Validieren bin ich geworden strenger, nicht lockerer. LLMs erzeugen leicht überzeugenden Unsinn, wenn man sie nicht korrekt nutzt; daher erhält jede Funktion oder App-Änderung einen kleinen Evaluationsrahmen – mit realistischen Eingaben, erwarteten Ergebnissen, kniffligen Fällen – den KI zwar entwerfen, aber den ich selbst kuratieren und testen werde.

Die Umsetzung beschränkt sich dann auf Linear + Claude Code + selbst gehostete Posthog Analytics. Shippen, beobachten, anpassen – und den Loop schnell halten, weil sich der Tech-Markt aktuell gefühlt stündlich verändert.

Warum ein minimalistischer, KI-zentrierter Toolstack am besten ist

Hier ist also mein grundlegender PM-Stack:

• GSuite
• Slack
• Der Geekbot Slack Bot (für Stand-ups)
• Linear
• VSCode
• CLI-basierte LLM (bei uns Claude Code)

Warum Linear? Es enthält nur das Wesentliche. Es ist leistungsstark genug, um nahezu allen Anforderungen eines Projektteams gerecht zu werden, aber einfach genug, um zugänglich zu sein. Es ist das absolute Gegenstück zu JIRA. Und am wichtigsten ist die einfache Integration in GitHub und Slack – also genau dort, wo Entwickler ohnehin arbeiten. Es ist einfach, schlank und fügt für Entwickler kaum zusätzlichen Aufwand hinzu, um Aufgaben anzulegen oder zu aktualisieren. Gleichzeitig ist es extrem erweiterbar; so kann man beispielsweise sein LLM im CLI automatisch versuchen lassen, einen Bug zu beheben, sobald er in einem Entwurf-PR gemeldet wird — noch bevor ein Mensch ihn überhaupt zu Gesicht bekommt.

Mehr braucht es nicht. Alles, was darüber hinaus anfällt, kann mit Open-Source-Tools im Terminal erledigt werden.

Coles Lieblings-KI-Tool für die persönliche Produktivität

Für die persönliche, nicht auf Teams bezogene Produktivität bin ich absolut begeistert von Raycast. Es ist die ultimative, superschnelle, vollständig anpassbare und ultraleichte App, die die schlechte „Spotlight“-App für Mac oder die „Windows“-Taste auf Windows ersetzt. Die Nutzung der Maus wird für die meisten Aktivitäten um 75% reduziert. Fast jede App kann mit bestehenden Integrationen angebunden oder durch eigene, benutzerdefinierte Integrationen erweitert werden — einfach Claude Code bitten, eine passende Extension zu erstellen!

Wenn ich den Text eines Bildes, das ich sehe, in meine Zwischenablage verschieben möchte, drücke ich die Raycast-Shortcut-Tasten, tippe „OCR“ und drücke Enter. Das löst das CleanshotX-OCR-Screenshot-Tool aus, und ich habe den Text eines beliebigen Bildes in weniger als fünf Sekunden. Genauso kann ich das Shortcut nutzen, „Ask spotify“ eingeben und dann einen Satz in natürlicher Sprache schreiben wie „gib mir gute High-Energy-Coding-Musik“. Der Text wird von einem LLM interpretiert, Musik-Tags und -Eigenschaften in der Spotify-API durchsucht, und sofort wird die gewünschte Playlist in Spotify gestartet.

Die Anwendungsfälle sind schier endlos. Einfach herunterladen, KI entweder über eigene API-Keys oder per Abo aktivieren und die populärsten Erweiterungen auf ihrer Webseite durchstöbern – dort findet sich garantiert etwas Nützliches. Ein absoluter Game-Changer.

Warum sich Produktmanagement und Engineering zunehmend überschneiden

Bald werden die meisten Feature-Entwickler gezwungen sein, wie Produktmanager zu denken und zu entscheiden. Gleichzeitig müssen Produktmanager genug über maschinelles Lernen, neuronale Netze, LLMs und verschiedene Architekturen verstehen, um so nahe wie möglich an die Tätigkeit eines Engineers mit LLMs heranzukommen, ohne tatsächlich einer zu sein. Diese Entwicklung spiegelt mutige Ansätze zur KI-Integration wider, die traditionelle Rollen grundlegend verändern.

Natürlich gibt es viele Ausnahmen und Bereiche, in denen dies nicht zutrifft. Im Allgemeinen jedoch wird sich das Venn-Diagramm aller bisherigen Rollen eines Unternehmens – von Vertrieb über Marketing und Produkt bis Engineering – immer weiter überschneiden, und es wird kaum noch Fertigkeiten geben, die ausschließlich einer bestimmten Rolle vorbehalten sind.

Wie man die unvermeidliche existenzielle Krise vermeidet, während KI die Produktarbeit verändert

Mein Tipp: Versucht, die unvermeidliche existenzielle Krise zu vermeiden, in die man angesichts dieser sich wandelnden Technologie leicht geraten könnte.

Konzentriert euch stattdessen auf jene Fähigkeiten, die euer Geist durch Erfahrung entwickelt hat. LLMs können Inhalte generieren, aber sie sind wirklich schlecht darin, guten Geschmack zu haben.

Antworten sind mittlerweile ein Massenprodukt. Die Fähigkeit, KI mit individuellen, erfahrungsspezifischen Fragen zu konfrontieren, ist heute eine Kompetenz. Darüber hinaus ist das eigentliche intellektuelle Arbeiten das Finden der richtigen Frage im eigenen Kopf.

Bleib auf dem Laufenden

Du kannst Cole auf X und seiner persönlichen Website folgen, während er weiterhin herausfordert, was im Bereich PM möglich ist. Außerdem: Schau auf Probably.dev vorbei!

Weitere Experteninterviews folgen demnächst auf The Digital Project Manager!