State of AI im Produktmanagement
Wie kommt eine Produktgruppe von fünf Wahrheiten zu einer? Fast alle PMs chatten mit ihrer AI, kaum jemand arbeitet mit einem System. Und wer weiter ist, sitzt allein vor seiner eigenen. Warum das kein Tool-Problem ist, und wie Produktleute daraus einen Vorsprung für ihre ganze Firma machen.
Heute hatte ich zwei Gespräche, die nicht unterschiedlicher in ihrer Art und gleicher im Ergebnis sein konnten. Das eine mit einer PM, die gerade in einer neuen Firma anfängt und dort erstmal einen Überblick bekommen muss. Das andere mit einem Berater-Kollegen, der seit Monaten Teams in die Arbeit mit AI bringt. Beide Gespräche waren ziemlich informell und unsortiert. Aber hinterher hat’s mich wie der Blitz getroffen: Beide haben das absolut selbe Bild beschrieben, eben nur aus den unterschiedlichsten Perspektiven. Und sie beschrieben, was ich gerade auch in meinen drei laufenden Kursen (intern und offen) und meiner anderen Produktarbeit sehe.
Fast kein PM arbeitet bis jetzt mit einem System in Claude Code oder Codex. Fast alle chatten, oft richtig gut: Dokumente rein, Kontext dazu, sauber formulierte Fragen. Alles cool. Nur ahnt deshalb auch kaum jemand, wie weit man kommen kann. Nicht mal die, die glauben, sie wären schon weit.
Und die meisten, die weiter sind: Jeder sitzt vor seiner eigenen AI, jeder mit seinem eigenen Kontext. Weil das Umfeld noch nicht weiter ist.
Fünf PMs, fünf AIs, fünf Wahrheiten
Fünf PMs fragen fünf AIs, jede mit anderem Kontext gefüttert, und bekommen fünf Antworten auf dieselbe Frage. Der Kollege erzählte von einem Team, das sich nicht mal einig war, ob es ein B2B- oder ein B2B2C-Produkt baut. Jetzt promptet jeder mit seiner Version der Wahrheit, und raus kommen Dokumente, PRDs und Analysen, die nicht zusammenpassen. Und keiner weiß mehr so genau: Hat der Kollege das gedacht, oder hat es seine AI nach drei Fragen ausgespuckt?
Nichts davon ist neu. Das gemeinsame Bild hat vorher auch gefehlt. Frag in einer beliebigen Firma fünf PMs, was ihr Produkt ist, und du bekommst fünf Antworten, manchmal sieben. Ich werde regelmäßig geholt, weil „unsere PMs keine gemeinsame Roadmap hinkriegen“. Dann sitzen alle in einem Raum, und der erste Satz ist: „Wir waren seit zwei Jahren nicht mehr zusammen in einem Raum.“ Dann kommen die Glaubenskriege, Feature-Roadmap ja oder nein, outcome-based, blablabla. Und irgendwann stellt sich raus, dass nicht mal das Top-Management eine gemeinsame Idee davon hat, was das Produkt leisten soll. Natürlich kriegen die keine Roadmap hin.
AI ist jetzt aber der Booster: Sie macht alles viel sichtbarer, wie ein Brennglas, und die Folgen werden größer. Gleichzeitig ist die Lösung jetzt technisch einfach, menschlich bleibt sie oft schwer. Engineering baut gerade Software Factories, die dreißig Features und vierzig Varianten am Tag ausspucken können. Super. Nur ist das vollkommen egal, wenn davor, also bei uns, das komplette Chaos herrscht. Die Factory baut dann eben schneller das Falsche. Oder fünfmal das jeweils Falsche.
Die gute Nachricht: Es war noch nie so billig, das zu beheben. Technisch ist das alles trivial und für jeden zugänglich. Schwierig wird es an anderer Stelle, in der Kultur und in der Zusammenarbeit. Und genau da sitzen Produktleute an der richtigen Stelle.
Zuerst klarmachen, was dein Job ist
Klingt unromantisch, entlastet aber enorm. Ich halte seit fünfzehn Jahren den Talk „Gestalten statt Verwalten“. Und trotzdem: Was Firmen von einem PM fast immer wollen, ist ein sehr guter Orchestrierer. Jemand, der den Unterschied zwischen Projekt und Produkt verstanden hat, Design, Engineering, Fachbereich, Research und Stakeholder zusammenhält und dafür sorgt, dass der eigene Teil des Produkts läuft. Die Leute um dich herum wollen informiert werden, wenn etwas schiefgeht, wenn es Fragen gibt, wenn etwas unklar ist. Der Rest soll rollen.
Mein Lackmustest dafür: Wie viele PMs haben ein Budget? Ich hatte als Produktmanager fast nie eins, auch bei eBay nicht. Ich war verantwortlich für den Erfolg des Produkts, was auch immer das heißen mag, praktisch waren es drei KPIs. Und ich kenne genug PMs, die Business Cases rechnen sollen, ohne die Kosten zu kennen oder zu verantworten oder irgendeinen Hebel darauf zu haben.
Das ist nicht schlimm. Es macht nur klar, wer du in der Firma bist. Viele von uns übernehmen aus bestem Wissen und Gewissen, im Heldenmodus, Pflichten, die sie gar nicht verantwortlich erfüllen können.
Randnotiz: Bevor ich mit irgendwem Halbjahresziele bespreche, würde ich erstmal klären:
- Worauf habe ich einen echten Hebel? Auf Kosten? Auf Design? Auf Engineering?
- Auf welche Leute habe ich Zugriff, und was darf ich von ihnen verlangen?
- Was kann ich also verantworten, und worüber kann ich nur berichten?
- Was kann ich selbst schlecht, und wer gleicht das aus? (Ich zum Beispiel bin eine Niete in Design. Ich kann Designentscheidungen mit Designern gut durchsprechen, aber ich brauche jemanden, der das wirklich kann, und das sage ich auch so.)
Symptom, mit dem alle kämpfen: „Mein Chef gibt mir keine Strategie!“ Ja, aber hast du eine, für die Leute, die mit dir arbeiten? Habt ihr als Peers eine, im Rahmen dessen, was vorgegeben wird? Helft ihr bei der Klärung der strategischen Fragen? Oder wartet ihr?
Warum gehört das in einen Text über AI? Weil genau diese Orchestrierungsarbeit das ist, wobei AI am meisten hilft. Dokumentieren, koordinieren, kommunizieren, den Überblick behalten. Wer aufhört, den Helden zu spielen, hat plötzlich das perfekte Einsatzgebiet für die Tools. Prototypen bauen lassen ist cool. Das hier ist noch cooler.
Das eigene Zimmer: Ordner statt Chatverlauf
Der erste Schritt ist technisch banal, und trotzdem ist er für fast alle in meinen Kursen der eigentliche Durchbruch: raus aus dem Chat, rein in Claude Code (oder Codex) und dort ein System aufbauen, das wächst.
Im Kern: Kontext in Dateien ablegen, die du für jede Aufgabe gezielt heranziehen kannst. Wer ist die Firma? Was ist die Strategie? Was ist mein Produkt, was meine Verantwortung, was sind meine KPIs? Das ist deine Source of Truth fürs Produkt, und die pflegst und hütest du wie deinen Augapfel. Darunter Ordner pro Produkt, pro Projekt, pro Aspekt deiner Arbeit. Allgemeines Wissen liegt weiter oben, Spezielles weiter unten. Deine Ordnerstruktur ist am Ende deine Session-Struktur: Wenn ich über einen bestimmten Kunden rede, starte ich die Session in dessen Ordner und rede nur über den.
Warum das so viel ausmacht, erkläre ich immer mit dem Handbuch. Ich kann dir bei einem Problem sagen: Hier ist das Handbuch, lies es durch. Oder: Dein Problem steht in Kapitel 5, Absatz 4. Im zweiten Fall bist du schneller und machst weniger Fehler. Einem Modell geht es genauso. Je fokussierter die Session und je gezielter der Kontext, desto spezifischer die Antworten und desto seltener die Plattitüden. Wenn du in einem Chat über dein Laufen, deine Gesundheit und dein Produkt gleichzeitig redest, weiß das Modell irgendwann selbst nicht mehr, worum es eigentlich geht. Und die Ergebnisse werden beliebig.
Die zweite Hälfte des Systems sind Skills, kleine Bausteine, die du immer wieder aufrufst. Mein Bild dafür: Claude ist ein ziemlich schlauer Werkstudent, der neben dir sitzt. Er weiß viel, aber er kann nicht so beurteilen wie du. Also frage ich mich bei allem, was mich nervt und oft vorkommt: Könnte ich das einem schlauen Werkstudenten übergeben, und würde ich mich gut dabei fühlen? Wenn ja, lasse ich einen Skill dafür bauen. Die Dokumentation in deinen Ordnern ist genau das, was du einem Werkstudenten auch in die Hand drücken würdest: Hier, das musst du wissen, da drüben liegen die Interviews von heute, komm nachher wieder, dann trinken wir einen Kaffee.
Und jetzt der wichtigste Trick: Bau das nicht selbst. Lass es bauen. Ich diktiere Claude, was ich will („Bau mir ein System, das Interviews so und so analysiert“), und Claude schreibt die Dateien. Wenn mir am Ergebnis etwas fehlt, gehe ich nicht in die Skripte, sondern sage es Claude, und das passt seine eigenen Skripte an. Ich habe so ein System mal live vor rund siebzig Leuten gebaut, in einer halben Stunde. Nicht, weil ich das so gut kann. Ich hatte es vorher genau einmal gemacht. Ich habe mich einfach getraut, und es hat geklappt. Wenn ich das Leuten zeige, denken sie entweder, ich bin sloppy, oder es ist ein Trick („der hat das hundert mal geübt“). Beides ist Quatsch. Das ist, wie es am besten funktioniert. SCHREIB.NICHT.SELBER.CLAUDE.MACHT.DAS
Klarheit nach draußen, im festen Rhythmus
Was im Alltag von PMs am meisten untergeht, ist klare Kommunikation. Wir stecken so tief im täglichen Gedöns und in der Besessenheit, etwas Gutes hinzukriegen, dass die Leute um uns herum oft nicht wissen, was eigentlich los ist.
Meine Lösung ist ein total klassisches Werkzeug: ein Stakeholder-Diagramm. Macht, Einfluss, Interesse, den ganzen Kram. Dann gruppiere ich die Leute und lege fest, wer was in welchem Rhythmus bekommt: wöchentlich, alle zwei Wochen, monatlich. Bei allem Größeren gibt es zusätzlich einen offenen wöchentlichen Termin, zu dem jeder kommen kann, der sich interessiert. Kurzer Stand, offene Fragen, Unklarheiten, Risiken. Wer nicht kommt, hat Pech gehabt. In dem Moment, in dem ich dieses Ventil anbiete, habe ich meine Pflicht erledigt. Das ist die beste Cover-your-ass-Aktion der Welt, und gleichzeitig mehr als das: Das System zwingt mich, meine eigene Klarheit jede Woche herzustellen.
Mit AI kostet das fast nichts mehr. Alle Nachrichten entstehen aus der einen Source of Truth, zugeschnitten pro Stakeholdergruppe: Der eine will in fünf Minuten die Top-down-Lage, der andere die Details. Ich würde sogar „generiert“ drüberschreiben, weil die Wahrheit dahinter ja meine ist. Vorher würde ich nur prüfen, ob generierte Texte in der Firma als Slop gelten. Dann bleibt es halbautomatisch: Die Maschine macht den Entwurf, du bringst ihn in deine Sprache.
Wer hilft mir, die Stakeholder-Struktur zu verstehen und dann auch zu bedienen? Claude Skills. Ich bessere nach – natürlich.
Dazu gehört, die eigene Wirkung nachweisen zu können. Die Metriken leitest du aus deinen Aufgaben ab: die Lead-KPI, die du verantwortest, deinen Anteil an der Lead Time von der Idee bis zum Kunden, Stakeholderzufriedenheit, Qualität. Heute baue ich mir dafür ein Dashboard, das ich jeden Tag sehe. Warum das so wichtig ist, habe ich in einer Situation bei einem alten Arbeitgeber gelernt. Wir saßen jede Woche mit dem CFO zusammen, alle Zahlen auf dem Tisch. Eines Tages kam er zu mir und sagte: „Markus, ich glaube, deine Abteilung arbeitet nicht effizient.“ Ich hatte alles parat: Stakeholderzufriedenheit hoch, Lead Time runter, Kundenzufriedenheit hoch, Qualität hoch, ein Outsourcing-Dienstleister abgewickelt, und trotzdem zehn Leute weniger. Was genau ist ineffizient? Das Gespräch war nach fünf Minuten beendet. Positiv beendet. Aber nur, weil ich alles hatte. Je volatiler die Umgebung, desto stabiler meine Vorbereitung.
Das eigentliche Problem, das AI hier löst, kennen viele gute PMs: Sie lassen schwere Dinge leicht aussehen, stellen ihr Team nach vorne und machen die komplexen Sachen still im Hintergrund. Das finde ich elegant, und Firmen honorieren es fast nie. Wer seine Arbeit nicht sichtbar macht, dem wird sie auch mal von jemand anderem abgenommen. Ein Kommunikationssystem mit festem Rhythmus und echten Zahlen macht deine Arbeit sichtbar, ohne dass du dich aufplustern musst.
Der Entwurf heute statt des PRDs in einem Monat
Ein Beispiel aus meinen Kursen, bei dem viele erstmal den Kopf schütteln. Zehn Kundeninterviews. Ein Skill analysiert jedes Interview einzeln: Wer ist die Person, was sind ihre Probleme, wie dringend, welche Bedürfnisse stecken hinter den Aussagen, welche Stimmung? Und für jede Aussage das Zitat, aus dem sie abgeleitet ist, damit du nicht auf Halluzinationen reinfällst. Dann liest ein zweiter Schritt über alle zehn und schreibt die Synthese: Welche Themen kommen in wie vielen Interviews vor? Und ein dritter Skill macht daraus einen PRD, nach einer Vorlage, die ich einmal beschrieben habe: Problem, Gelegenheit, Ziele, was wir ausdrücklich nicht machen, Kernabläufe, Rollout.
Jeder, der Interviews gelernt hat, sagt: Das kann nicht funktionieren. Und dann liest man den PRD und denkt: Mist, so doof ist der gar nicht. Ist er perfekt? Nein. Vielleicht zu 90, 95 Prozent. Aber welcher PM arbeitet im echten Leben so gründlich, mit Zitaten und Belegen? Und wenn, dann dauert es einen Monat. Den Entwurf hast du in zwanzig Minuten. Du kannst ihn doof finden. Dann streitet ihr heute über einen konkreten Entwurf statt in einem Monat über einen schlechteren. Die Reibung kommt früher, und sie wird besser.
Eine Leitplanke gehört dazu, und der Kollege hat sie schön auf den Punkt gebracht: Schick niemandem AI-Antworten statt deiner Meinung. Wenn du um Feedback gebeten wirst und nur fünf generische Analysepunkte zurückschickst, die der andere mit seiner AI längst selbst hatte, ist das schlechter als ein klares „Ich habe gerade keine Zeit dafür“. Und wenn zehn Leute dieselbe AI fragen, ob Option A, B oder C besser ist, und alle „A“ antworten, dann hat niemand eine Meinung abgegeben. Es wurde nur abgehakt.
Das Wohnzimmer: ein Regal für alle
Spätestens am Ende eines Kurses sagen mir die Leute alle dasselbe: „Super, jetzt kann ich das. Aber mein Umfeld kann es nicht.“ Sie merken nach ein paar Wochen Arbeit mit AI, dass sie einen gemeinsamen Kontext bräuchten. Das ist eine mega Erkenntnis – genau die, die ich erzeugen will – und gleichzeitig ziemlich erschütternd, weil es zeigt, dass sie diesen gemeinsamen Kontext ohne AI auch nie hatten.
Der Kollege und ich benutzen dafür unabhängig voneinander dasselbe Bild. Das Team wohnt zusammen in einer Wohnung. Jeder hat sein Zimmer und kann darin machen, was er will. Im Wohnzimmer steht ein gemeinsames Bücherregal. Und das braucht Regeln: Wer darf (automatisiert) etwas hineinschreiben? Was braucht zwei oder vier Augen? Was muss das ganze Team gemeinsam entscheiden? Wer darf von außen Bücher hineinstellen, zum Beispiel die neue Strategie? Was ist unser Produkt, was sind die Unterprodukte, was ist meine Aufgabe darin, was ist die Aufgabe der Produktgruppe?
Technisch ist das trivial. Git sind drei Befehle, und die kann Claude für dich. Wenn der CEO seine neue Strategie als 200-Folien-Deck verteilt, lässt du sie in Markdown übersetzen und legst sie ins gemeinsame Regal. Für Teams außerhalb der Produktentwicklung tut es auch ein gut organisierter geteilter Ordner. Das technische Problem war nie das Problem. Das Problem ist, einzusehen, dass man es machen muss.
Entwickler machen uns das seit Jahrzehnten vor. Die streiten sich von morgens bis abends wie die Kesselflicker darüber, welche APIs sie benutzen, welche Linter über den Code laufen, was der Standard ist. Ein gemeinsamer Kontext ist für sie selbstverständlich. Bei PMs heißt es eher: Ich mach mein Ding. Genauso bei den Kanälen: Jeder (na gut, na gut) Entwickler sagt „zwischen 9 und 12 kommst du nicht zu mir“. PMs lassen sich von jedem Stakeholder jederzeit überfallen, dabei wäre ein einfaches Formular für Feature-Wünsche plus Termin-Link schnell gebaut, AI supported und erst-ausgewertet. Eingangskanal, Ausgangskanal, fertig. Wieder: technisch trivial, inhaltlich hilfreich und erleuchtend.
Wie beim Engineering, wo die Aufgabe inzwischen ist, die Maschine zu bauen, die den Code produziert, heißt unsere Aufgabe jetzt: gemeinsam die Produktmaschine bauen. Produkt wird erst gut, wenn wir es zusammen gestalten. Neu ist, dass wir auch das Werkzeug zusammen gestalten, das uns dabei hilft. Die Diskussionen darüber sind der schwierige Teil, nicht die Technik.
Zwei Dinge helfen dabei enorm. Erstens: das ganze Team mitnehmen, nicht nur eine Person schulen. Wer allein aus einem Training zurückkommt, muss das intern verkaufen, obwohl er selbst gerade erst Anfänger ist. Zweitens: Show and Tell. Die, die schon weiter sind, glänzen plötzlich und behalten ihren Vorsprung gern für sich. Genau das falsche Verhalten. Zeigt euch gegenseitig, wer was wie mit AI macht, gerade weil bei den meisten ganz normalen Kolleginnen und Kollegen die Unsicherheit groß ist.
Liebe Führungskräfte, ich höre das ständig, und es ist nett gemeint. Es soll Vertrauen, gute Delegation ausdrücken. Im echten Leben lässt es aber einfach die Leute alleine und ist wirklich sloppy Führung: „Meine Leute sind schlau, die lernen das nebenbei.“ Kann sein, dass die Besten das tun. Aber die Besten teilen es selten, und sie lernen nicht unbedingt das, was deine Abteilung braucht. Es hat noch nie eine Abteilung ihr Niveau gehoben, weil einzelne Leute in ihrer Freizeit YouTube-Videos geschaut haben. Das musst du steuern. Es ist DEINE Aufgabe. Mach es. Kümmer dich. Die Aufgabe von Mitarbeitern ist nicht, aktiv Prozesse zu ändern und das zu überblicken. Sie können helfen, Input geben. Und wenn gerade das ganze Budget in Tokens und Lizenzen fließt und für Befähigung nichts übrig ist, lohnt sich die Frage, was eigentlich alle mit den Tokens machen. (Die „15 Agenten“, von denen man dann hört, sind nach meiner Erfahrung meistens 13 Custom GPTs. Und Agenten, die in Slack-Kanälen mitlesen, ertrinken im Rauschen.) Zum Trost: FOMO ist erlaubt. Wenn selbst Andrej Karpathy, OpenAI-Mitgründer, letzten Dezember schreibt, er habe sich als Programmierer noch nie so abgehängt gefühlt, dürfen wir das auch. Für normale Wissensarbeit reicht übrigens fast immer ein mittleres Modell. Du musst nicht jedem Release hinterherrennen.
Warum die Reihenfolge zählt
Die einzelnen Skills sind das Leichte, fast trivial. Einen Skill für eine richtig gute Interviewanalyse diktierst du in zehn Minuten. Schwer ist zu verstehen, wie AI mit deiner Arbeit zusammenhängt und wie die Teile ineinandergreifen.
Die Rollenklärung legt fest, was überhaupt in deine Source of Truth gehört. Wer kein Budget verantwortet, schreibt dort keinen Business Case hinein, sondern die KPIs, die er tatsächlich bewegt. Die Source of Truth speist deine Kommunikation. Ohne sie generierst du nur schönere Statusmails aus fünf verschiedenen Wahrheiten. Der Kommunikationsrhythmus macht früher oder später sichtbar, dass die Mails der Kollegen deinen widersprechen, und genau dann braucht ihr das gemeinsame Regal. Und erst das Regal sorgt dafür, dass die Produktgruppe als Ganzes schneller wird und nicht nur jeder für sich ein bisschen effizienter.
Dafür gibt es gar nicht so viele Regeln. Aber man muss es regeln.
Was am Ende rauskommt: Zeit fürs Gestalten
Mir ist gerade eine PM-Stelle begegnet, die genau so gebaut ist. Erst ein laufendes Produkt übernehmen und so schlank bekommen, dass es mit deutlich weniger Aufwand läuft. Mit der frei gewordenen Zeit dann herausfinden, welche neuen Ideen im Unternehmen wirklich ein Produkt werden sollten. Erst das eigene Zimmer aufräumen, die Orchestrierung mit AI so leicht wie möglich machen, und dann Kapazität für das Neue haben.
Das ist für mich die ermutigende Pointe. Das Gestalten, von dem viele von uns träumen und das im Alltag so selten gefragt ist, kommt auf diesem Weg durch die Hintertür zurück. Verdient, nicht beansprucht. Weil jemand die Verwaltung so gut in den Griff bekommen hat, dass Zeit übrig bleibt.
Und selbst wenn es nicht ganz so weit kommt: Die Arbeit, die Firmen tatsächlich von uns wollen, wird mit AI leichter und macht deutlich mehr Spaß. Also all in, genau dafür.
P.S. Wie das alles ineinandergreift, für dich als PM und für euch als Produktorganisation, ist der Kern meines Kurses „AI Augmented Product Management“. Die nächste Kohorte startet am 12. Oktober: ueberproduct.de/seminar/ai-augmented-product-management