Produktmanager, die nur Dokumente schreiben können, haben keine Zukunft. Künstliche Intelligenz-Programmieragenten beenden die Ära der "Übersetzer".

Das Göttliche Übersetzungsbüro ist ein Übersetzungsteam unter dem Dach von 36Kr. Es setzt sich für die Bereiche Technologie, Geschäft, Karriere und Lebensstil ein und stellt vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vor.

Herausgeberhinweis: Der übersetzende Produktmanager ist tot. Wenn die Implementierungskosten durch KI ausgeglichen werden, werden tiefgreifende Problemdefinition und einzigartiger Produktgeschmack zur einzigen Karrierebrücke. Dieser Artikel ist eine Übersetzung.

Letzte Woche schrieb ich darüber, wie ich mit KI-Agenten arbeite. Ich hätte nicht gedacht, dass dieser Artikel ein noch größeres Thema auslösen würde - die Veränderungen, die das Produktmanager-Rolle selbst durchmacht.

Zum Beispiel wie die "Kontextkuration" zu einer Fähigkeit geworden ist, von der niemand spricht, aber die alle effizienten Menschen beherrschen. Oder wie ich mit AI Studio und Claude Code in nur wenigen Stunden lose Ideen in einen lauffähigen Prototypen umwandeln konnte.

Ich habe auf X veröffentlicht, meinen Computer zugemacht und am nächsten Morgen aufgewacht, um Tausende von Benachrichtigungen zu finden.

In nur wenigen Stunden war der Artikel wie wild verbreitet. Viele von Ihnen konnten sich identifizieren, teilten Ihre eigenen Geschichten und trugen so zur Diskussion bei.

In der Vergangenheit war die Arbeit eines Produktmanagers im Wesentlichen eine "Übersetzung".

Du sprichst mit den Kunden, fasst ihre Probleme zusammen, schreibst Spezifikationen und übergibst sie dann an die Ingenieure. Du bist die Brücke zwischen "Benutzerbedürfnissen" und "tatsächlichem Produkt". Und der Wert eines PM zeigt sich genau in dieser Übersetzungsebene.

Jetzt wird diese Ebene zusammengedrückt.

Wenn ein Agent ein klar definiertes Problem aufnehmen und lauffähigen Code generieren kann, verschiebt sich der Schwerpunkt der Arbeit des Produktmanagers. Du übersetzt nicht mehr für die Ingenieure, sondern musst die Absicht so klar ausarbeiten, dass der Agent direkt darauf reagieren kann.

Spezifikationen werden zum Produkt selbst.

Ich habe diese Veränderung bei mir selbst und bei mehreren Dutzend Produktmanagern beobachtet. Früher musste ein Produktmanager ein ausführliches Dokument schreiben, es weitergeben, auf Fragen warten, Klarstellungen geben, auf die Entwicklung warten, eine Prüfung durchführen, Feedback geben und dann iterieren. Der gesamte Zyklus dauerte Wochen. Jetzt müssen sie nur noch eine klare Problemstellung mit Einschränkungen schreiben, sie an den Agenten übergeben und können innerhalb einer Stunde den laufenden Code prüfen.

Die Zeitspanne zwischen "Ich weiß, was zu tun ist" und "Das Ding ist fertig" ist verschwunden. Aber die Arbeit, "zu bestimmen, was zu tun ist", wird nicht einfacher, sondern wichtiger.

Du musst nicht selbst Code schreiben, aber du musst genau wissen, was du willst, so genau, dass der Agent es direkt entwickeln kann. Spezifikationen und Prototypen verschmelzen zu einem. Du musst nur die Anforderungen beschreiben, beobachten, wie es entsteht, Abweichungen korrigieren und dann iterieren. Die Engstelle liegt nicht mehr auf der Implementierungsebene.

Außerdem wird das Tempo der Produktveröffentlichungen nur immer schneller werden.

Ich habe ungefähr drei bis vier Monate bei Google gearbeitet, und es hat sich angefühlt, als hätten wir in dieser Zeit mehr Produkte veröffentlicht als in den letzten Jahren an KI-Fortschritten. Nur in diesem Zeitfenster haben wir Gemini 3 Pro und Flash, die Multimodal Live API, Nano Banana Pro, den Deep Research Agent, die Google Interactions API, die Java/Go/TypeScript-Versionen des ADK und vieles mehr eingeführt.

Dank KI-Programmieragenten arbeiten KI-Unternehmen aller Größen mit dieser Geschwindigkeit voran. Die früheren Zyklen, die die Produktentwicklung bestimmten - von der Quartalsplanung, der monatlichen Sprint bis zur wöchentlichen Veröffentlichung - werden zu einem Zustand zusammengepresst, der eher einer "kontinuierlichen Bereitstellung von Ideen" entspricht.

Wenn die Schwelle für die Umsetzung so schnell sinkt, verschiebt sich die Engstelle stromaufwärts. Die knappen Ressourcen sind nicht mehr die Fähigkeit zur Softwareentwicklung, sondern die Fähigkeit zu beurteilen, was wirklich wertvoll ist.

Das neue Skillset von Produktmanagern

Problemformulierung: Die besten Produktmanager, die ich kenne, waren immer gut darin, aber früher war es nur eine von vielen Fähigkeiten. Jetzt ist es die "Kern"-Fähigkeit. Kannst du ein vages Kundenproblem so klar formulieren, dass ein oder mehrere Agenten darauf reagieren können? Kannst du die wirklich wichtigen Einschränkungen identifizieren? Kannst du klar ausdrücken, was der Erfolgskriterium ist?

Spezifikationen sind nicht mehr ein Dokument, sondern ein klar umrissenes, gut definiertes Problem.

Kontextkuration: Dies ist eine Fähigkeit, von der niemand spricht, aber die jeder Produktmanager, der gut mit Agenten zusammenarbeitet, beherrscht. Die Qualität der Ausgabe eines Agenten ist direkt proportional zur Qualität des ihm gegebenen Kontexts.

Als ich anfänglich mit Agenten arbeitete, gab ich vage Anweisungen: "Mach mir ein Kundenfeedback-Dashboard". Das, was ich erhielt, funktionierte technisch, aber traf überhaupt nicht den Kern. Denn es kannte unsere Benutzer nicht, unsere Einschränkungen nicht und unsere Definition eines "guten Produkts" nicht.

Jetzt pflege ich ein "Kontextdokument", das ich vor jedem Projekt an den Agenten gebe. Im Laufe der Zeit habe ich herausgefunden, was in diesen Dokumenten wirklich wichtig ist:

• Konkrete, reale Benutzer. Keine fiktiven Benutzerprofile, sondern reale Details: Wer sie sind, worum es ihnen geht, was sie dazu bringt, aufzugeben, was ihre Aufmerksamkeit fesselt.

• Beschreibe das Problem in den Worten der Benutzer. Zitiere direkt Gesprächsnotizen, Tickets oder Verkaufsdaten. Verwende ihre Sprache, nicht deine zusammengefasste Sprache. Dies hilft dem Agenten, sich an die realen Probleme zu binden, nicht an abstrakte Probleme.

• Definiere, was "gut" ist. Biete Beispiele von Produkten, die das Team als gut entworfen ansieht. Deine früheren Arbeiten, die Produkte deiner Konkurrenten oder verwandte Produkte. Zeige sie direkt, statt sie nur zu beschreiben.

• Was wurde versucht und warum ist es fehlgeschlagen? Die organisatorischen Erfahrungen, die normalerweise in den Köpfen der Menschen liegen. Die Optionen, die du bereits abgelehnt hast und die Gründe dafür.

• Formuliere die Einschränkungen für die Lösung. Nicht alle Einschränkungen, sondern nur diejenigen, die wirklich die endgültige Form des Produkts verändern.

• Wie kann man feststellen, ob es funktioniert? Konkrete, nicht vage Maße. Einige Indikatoren, die du wirklich messen oder beobachten kannst.

Jetzt, wenn ich den Agenten einen Prototypen erstellen lasse, fängt er nicht mehr von Null an. Er weiß, für wen wir entwickeln, was die Benutzer wirklich gesagt haben, was das Kriterium für ein gutes Produkt ist und welche Wege bereits gesperrt sind. Weil die eingegebenen Informationen so konkret sind, passt die Ausgabe perfekt.

Einschätzungsfähigkeit und Geschmack: Geschmack wurde immer unterschätzt. Aber wenn Agenten schnell und in großer Menge produzieren können, wird Geschmack zur wichtigsten Fähigkeit. Löst dies wirklich das Problem? Behandelt es die wichtigen Randfälle? Ist dies die Version, die wir veröffentlichen sollten, oder ist es nur eine lauffähige Version?

Dies ist schwieriger als es klingt. Agenten werden sehr zuversichtlich Dinge generieren, die richtig aussehen, aber in Wirklichkeit daneben liegen. Du musst durch ständliche Übung diesen Geschmack entwickeln.

Es gibt keinen Kurzweg: Du musst selbst anfangen, evaluieren und spüren, was der Unterschied zwischen "veröffentlichungsreif" und "technisch machbar" ist.

Der Wandel im Denkmodell

So denke ich jetzt:

Altes Modell: PM denkt über das zu machende aus → schreibt Dokumente → Ingenieure entwickeln → PM prüft → Iteration

Neues Modell: PM denkt über das zu machende aus → PM arbeitet mit Agenten zusammen → PM evaluiert → schnelle Iteration → (nach Zufriedenheit) Übergabe an Ingenieure für die Produktion

Produktmanager in der KI-Zeit übergeben nicht nur mehr Anforderungen. Sie führen die erste Iteration der "Atmosphärenprogrammierung" selbst durch und erhalten echte Feedback auf lauffähiger Software, anstatt auf Folien oder Figma-Prototypen herumzupokken. Die Rolle der Ingenieure ändert sich ebenfalls. Sie sind nicht mehr die Übersetzer deiner Absichten, sondern werden zu Partnern, die helfen, das Produkt besser zu machen und produktionsreif zu machen.

Dies verändert deine Beziehung zum Produkt. Du beschreibst nicht mehr die Anforderungen und hoffst darauf, dass sie richtig umgesetzt werden. Du formst es direkt und in Echtzeit.

Habe ein Iterationsdenken. Erlaube, dass die erste Version falsch ist. Versuche nicht, es im Voraus im Kopf perfekt zu planen. Gib dem Agenten reichhaltige Hintergrundinformationen, lass ihn einen Entwurf machen. Schau dir die Ausgabe an, reagiere und iteriere. Du lernst mehr aus "Hier stimmt etwas nicht, weil ..." als wenn du versuchst, jeden Randfall im Voraus zu berücksichtigen.

Ich lasse den Agenten oft zwei oder drei völlig verschiedene Lösungen gleichzeitig ausprobieren, nur um zu spüren, welche am besten passt. Früher war dies sehr kostspielig, jetzt ist es nur ein Matter von einigen parallelen Agenten am Dienstag Nachmittag.

Sei länger mit Unklarheit einverstanden. Früher war es die Instinkt des PM, vage Ideen so schnell wie möglich in Dokumente umzuwandeln. Jetzt ist es die Instinkt, in der Unklarheit zu forschen. Sperre dich nicht zu früh auf eine Lösung fest. Lass den Agenten dir helfen, den möglichen Lösungshorizont zu verstehen, bevor du eine Entscheidung treffst.

Wie man anfängt

Wenn du ein Produktmanager bist, der diese Arbeitsweise noch nicht ausprobiert hat, kannst du hier anfangen:

Wähle ein kleines Problem aus, das du wirklich hast. Kein fiktives Problem, sondern etwas, das dich gerade stört. Zum Beispiel einen Bericht, der manuell zusammengefasst werden muss, einen umständlichen Arbeitsablauf oder einen Prototypen, den du gerne hättest.

Spendiere 30 Minuten, um ein Kontextdokument zu schreiben, bevor du Anweisungen eingibst. Sieh dir die vollständige Liste im Abschnitt "Kontextkuration" oben an.

Leite den Agenten auf dieses Problem hin und beobachte, was passiert. Erwarte nicht das Perfekte, nimm es als Ausgangspunkt. Gib Feedback, leite es und iteriere ständig.

Tue dies zehnmal. Für verschiedene Probleme, unterschiedliche Komplexitäten. Du wirst allmählich ein Gefühl dafür entwickeln, welche Methoden funktionieren, welche Hintergrundinformationen wichtig sind und wie du die Ausgabe evaluieren sollst. Dieses Gefühl ist die neue Fähigkeit des Produktmanagers.

Die Produktmanager, die sich hervorheben werden, sind diejenigen, die das Problem so gut verstehen, dass die Lösung für sie und die Agenten, die sie verwenden, offensichtlich ist.

Ich wechsle zwischen AI Studio, Cursor, Antigravity und Claude Code je nach Aufgabe. Die Werkzeuge selbst sind nicht wichtig. Wichtig ist, die Gewohnheit zu entwickeln, täglich mit Agenten zusammenzuarbeiten und diese "Muskelgedächtnis" zu trainieren.

Abschließend ein Wort an alle...

Wenn deine Arbeit hauptsächlich darin besteht, Kundenanforderungen in Dokumente für Ingenieure zu übersetzen, ist das nur ein Arbeitsablauf. Und Arbeitsabläufe werden schließlich automatisiert.

Wenn deine Arbeit darin besteht, "das Problem so tiefgehend zu verstehen, dass die richtige Lösung von selbst auftritt", dann wirst du wertvoller sein als je zuvor. KI-Agenten werden diese tiefe Einsicht in ein produktionsreifes Produkt umsetzen, und zwar viel schneller als jedes Team zuvor.

Jeder Produktmanager sollte sich fragen: Was bleibt übrig, wenn die "Übersetzungsebene" verschwindet?

Für die besten Produktmanager ist die Antwort: Alles, was wirklich wichtig ist.

Problemverständnis, Empathie, Urteilsvermögen, Geschmack. Dies war immer ein Teil der Arbeit eines Produktmanagers. Und jetzt wird es zur gesamten Arbeit!

Übersetzer: boxi.