PM, Entwickler und KI: Die Rollen verschwimmen, die Verantwortlichkeiten bleiben

Seit mehreren Monaten interviewen Entwickler die Kunden, ohne über den Product Manager zu gehen.

Und vor drei Tagen habe ich meinen ersten Pull Request auf unser Hauptprodukt gepusht.

Diese beiden Sätze zusammenfassen besser als jede Analyse, was in den Produktteams mit KI gerade passiert. Entwickler steigen zum Problem, zum Kunden und zum Produkt-Ownership auf. PMs steigen zum Prototyp, zum Code und manchmal zur Produktion ab.

Man könnte darin zwei isolierte Anekdoten sehen. Ich glaube im Gegenteil, dass das der Beginn einer tieferen Umkehrung ist. Die historischen Rollen des Product Managements, der Entwicklung und des Designs werden weniger klar. Die Grenzen bewegen sich. Aber entgegen dem, was man denken könnte, bedeutet das nicht, dass alle alles tun werden, noch dass die Verantwortlichkeiten verschwinden werden.

Das eigentliche Thema ist nicht, dass KI Teams „produktiver" macht. Das eigentliche Thema ist, dass sie die Produktionsfähigkeit stark steigert. Und wenn die Produktionsfähigkeit steigt, verschiebt sich der Engpass.

Vorher war die Einschränkung oft: „Wie viel können wir bauen?"

Morgen wird sie mehr: „Was sollen wir bauen? Warum? Für wen? In welcher Reihenfolge? Mit welchen Risiken?"

Diese Verschiebung ist es, die die Rollen verschwimmt.

Wenn Entwickler mehr produzieren, wird der PM zum Engpass

Einer der Auslöser des Themas ist ziemlich einfach: Mit KI können Entwickler schneller produzieren.

Nicht nur ein paar Zeilen schneller schreiben. Mehr Optionen, mehr Varianten, mehr Prototypen, mehr kleine Werkzeuge, mehr Initiativen produzieren. Ein Entwickler, der bereits autonom war, kann sich plötzlich in der Lage sehen, bei bestimmten Aufgaben drei-, vier- oder sechsmal schneller voranzukommen. Ein Team, das eine begrenzte Lieferkapazität hatte, kann plötzlich viel mehr Dinge generieren, die getestet, abgewogen, überprüft und priorisiert werden müssen.

Das Problem ist, dass die Entscheidungsfähigkeit nicht automatisch im gleichen Rhythmus zunimmt.

Wenn weiterhin alles über den PM laufen muss, wird dieser schnell zum neuen Sättigungspunkt des Systems. Es geht nicht mehr nur darum, Specs zu schreiben oder ein Backlog zu verfolgen. Die Last verschiebt sich zur Priorisierung, zur Produktkohärenz, zur Validierung des Kundensignals, zur Marktabwägung, zum Nutzereinfluss, zur Strategie und zum Management der Konsequenzen.

Eine Organisation kann dann glauben, ihr Geschwindigkeitsproblem gelöst zu haben, weil Entwickler mehr produzieren. In Wirklichkeit hat sie die Blockade nur verschoben.

Es gibt drei mögliche Antworten.

Die erste besteht darin, mehr PMs einzustellen. Das ist manchmal notwendig, aber nicht immer die richtige Antwort. Wenn das Modell gleich bleibt, fügt man nur eine weitere Abwägungsschicht hinzu.

Die zweite besteht darin, einen Teil der operativen PM-Arbeit zu automatisieren: Dokumentation, Release-Notes, Launch-Unterstützungen, erste Analysen, Übersetzungen, Zusammenfassungen, Demo-Videos, Screenshots, PR-Elemente. Das spart Zeit, reicht aber nicht aus, die Grundfrage zu lösen.

Die dritte besteht darin, einen Teil des Produkt-Ownerships an die Konstrukteure umzuverteilen. Dort beginnen die Rollen wirklich zu verschwimmen.

Den Code beschleunigen reicht nicht

Ein Fehler wäre zu glauben, dass KI die Organisation nur verändert, weil sie die Entwicklung beschleunigt.

Lokale Geschwindigkeit schafft nicht automatisch Wert. Sie kann sogar mehr Unordnung schaffen, wenn der vollständige Workflow sich nicht verändert. Ein Team kann mehr Code, mehr Prototypen, mehr Dokumente und mehr Tickets generieren und dabei schlechtere Entscheidungen treffen.

Der vollständige Fluss muss neu gedacht werden: Idee, Discovery, Spezifikation, Prototyping, Entwicklung, Tests, Sicherheit, Launch, Kommunikation, Support und Lernen.

Wenn man auf einem unveränderten Prozess KI-Agenten hinzufügt, riskiert man nur, die Engpässe zu verschieben. Der Code beschleunigt, dann blockiert das Produkt. Das Produkt beschleunigt, dann blockiert das Design. Das Design beschleunigt, dann blockiert die technische Validierung. Die Validierung beschleunigt, dann folgt der Go-to-Market oder der Support nicht mehr.

Das Thema ist also nicht nur: „Wie macht man Entwickler schneller?"

Das Thema ist: „Wie macht man das gesamte System in der Lage, diese Geschwindigkeit zu absorbieren, ohne an Qualität, Kohärenz und Verantwortung zu verlieren?"

Genau deshalb sind die neuen Rollen nicht nur „PM, der kodiert" oder „Entwickler, der Produktarbeit macht". Ein Teil der neuen Bedürfnisse betrifft die Orchestrierung von Workflows, die Bewertung von KI-Ausgaben, das Produktgedächtnis, die Qualität der Entscheidungen, die Lesbarkeit der Repos und die Fähigkeit, Agenten einen zuverlässigen Kontext zu geben.

Was KI im Product Management banaliert

Lange unterschieden sich manche PMs durch ziemlich unterschiedliche Sensibilitäten oder Kompetenzen.

Manche waren sehr gut im Schreiben. Andere in Daten. Andere in Benchmarking, Produktmarketing, Discovery, Erfahrungsdesign oder Delivery-Koordination. Diese Unterschiede verschwinden nicht vollständig. Aber ein Teil ihres Differenzierungswerts sinkt.

Mit KI werden viele Fähigkeiten zugänglicher:

• eine korrekte Spec schreiben;
• eine erste Datenanalyse produzieren;
• ein Benchmark machen;
• eine Release-Note schreiben;
• eine akzeptable Maquette machen;
• Interviews zusammenfassen;
• eine erste Version eines Parcours produzieren;
• einen Bedarf in einen Prototyp umwandeln.

Diese Kompetenzen werden nicht nutzlos. Ein PM muss immer noch eine Spec beurteilen, eine Analyse hinterfragen, eine Maquette lesen, eine Interview-Zusammenfassung verstehen oder einen Prototyp bewerten können. Aber die erste Produktion dieser Artefakte wird weniger selten.

Vorher konnte ein PM stark differenziert sein, weil er schnell eine gute Spec, ein klares Benchmark, eine nutzbare Zusammenfassung oder eine erste Maquette produzieren konnte. Morgen wird das eher das Mindestniveau sein.

Das macht PMs verwundbar, die vor allem durch ihre intermediäre Ausführungsfähigkeit stark waren. Jene, die koordinierten, schrieben, verwalteten, verfolgten, umformulierten und korrekte Artefakte produzierten, ohne ein starkes Produkturteil zu tragen, riskieren, einen Teil ihres Werts zu verlieren.

Der Produktberuf verschwindet nicht. Aber sein Mindestniveau steigt.

Was schwer bleibt: das Produkturteil

Wenn Produzieren einfacher wird, wird die Wahl des Zu-Produzierenden kritischer.

Dort behält der PM-Beruf seinen Wert. Nicht in der Fähigkeit, mehr Artefakte zu generieren, sondern in der Fähigkeit zu wählen, abzuwägen und zu übernehmen.

Was schwer bleibt:

• das richtige Problem wählen;
• einen Markt verstehen;
• das echte Signal hinter Kundenanfragen lesen;
• zwischen Kurzfristigkeit und Strategie abwägen;
• Nein sagen;
• eine kohärente Vision halten;
• Ausrichtung schaffen;
• die Produkt-, Geschäfts-, technischen und menschlichen Konsequenzen einer Entscheidung übernehmen.

Der augmentierte strategische PM ähnelt immer mehr einer Form von kleinem CPO. Er ist weniger in der Delivery-Verwaltung, weniger in der mechanischen Produktion von Ergebnissen, und mehr in den Abwägungen, wo keine Option perfekt ist.

Die Rolle wird besonders wichtig, wenn es keine gute Lösung gibt. Nur zwei oder drei schlechte Optionen, mit unterschiedlichen Kosten, unterschiedlichen Risiken, unterschiedlichen politischen Effekten, unterschiedlichen Kundenauswirkungen. In diesen Momenten kann KI helfen zu analysieren. Sie kann nicht übernehmen.

Der augmentierte PM ist also nicht einfach ein PM, der schneller geht. Er ist ein PM, der besser urteilen muss.

Die Differenzierung verschiebt sich zum Kundensignal

Wenn alle schneller bauen können, reicht schnelles Bauen nicht mehr als Vorteil aus.

Die rohe Codeproduktion wird teilweise zu einem Allgemeingut. Nicht Software. Nicht Engineering. Nicht Architektur, Sicherheit oder Wartbarkeit. Aber die Fähigkeit, schnell eine erste Version zu produzieren, wird weniger selten.

Die echte Differenzierung verschiebt sich dann zu dem, was Konkurrenten nicht einfach generieren können:

• die Qualität des Kundensignals;
• proprietäre Daten;
• Fachkompetenz;
• Distribution;
• Vertrauen;
• operative Einschränkungen;
• angehäufte Erkenntnisse;
• die Fähigkeit, korrekt zu interpretieren, was Kunden wirklich verlangen.

Ein schneller Prototyp hat nur Wert, wenn er ein echtes Signal testet. Sonst beschleunigt er nur eine schlechte Richtung.

Die strategische Frage wird also: Auf welchem eigenen Vorteil baut man auf?

Ein durch KI augmentiertes Team kann viele Dinge produzieren. Aber wenn es seinen Markt nicht besser liest, seine Nutzer nicht besser versteht, wenn es ein starkes Signal nicht von gut formuliertem Rauschen unterscheiden kann, wird es nur schneller mittelmäßige Dinge produzieren.

Das ist ein weiterer Grund, warum der PM nicht verschwindet. Die Rolle verschiebt sich zur Lesequalität der Realität.

Entwickler steigen zum Produkt auf

Entwickler waren nie einfache Ausführende.

Eine vollständige Spezifikation ist eine Fiktion. Auch eine gute Spec beschreibt nie alle erwarteten Verhaltensweisen eines Produkts. Es gibt immer stille Zonen: Randfälle, Fehlermeldungen, implizite Verhaltensweisen, Sicherheitsregeln, Ablaufzeiten, unsichtbare Prioritäten, Mikrointeraktionen, Fallback-Entscheidungen.

In diesen Zonen treffen Entwickler bereits Produktentscheidungen.

KI macht diese Realität sichtbarer. Wenn ein Agent einen Teil des Codes schreibt, muss der Mensch das erwartete Verhalten explizieren, die Edge Cases abwägen, die Akzeptanzkriterien definieren, das Ergebnis überprüfen. Die Mikroentscheidungen, die still in der Implementierung absorbiert wurden, werden sichtbarer und damit wichtiger zu rahmen.

Das ist einer der Gründe, warum Entwickler zum Produkt aufsteigen. Sie sprechen mehr mit Kunden, verstehen Probleme besser, tragen mehr Ownership für ihre Funktionen, treffen explizitere lokale Entscheidungen.

Aber es gibt eine wichtige Nuance: Ein Entwickler wird nicht zum Product Engineer, nur weil er einen Code-Agenten verwendet oder schneller liefert.

Wenn er keinen Zugang zu Kunden, Daten, Geschäftskontext und Abwägungen hat, riskiert er nur, zum Agenten-Operator zu werden. Mehr Verantwortlichkeiten, mehr Druck, aber nicht unbedingt mehr Produkteinfluss.

Der echte Product Engineer ist nicht nur ein schneller Entwickler. Er ist jemand, der einen Teil des Produkturteils so nah wie möglich an der Konstruktion trägt.

PMs steigen zur Konstruktion ab

Die umgekehrte Bewegung existiert auch.

Mit KI kann ein PM eine Idee viel schneller materialisieren als zuvor. Eine Maquette, ein Prototyp, ein internes Werkzeug, ein Dashboard, eine Übersetzung, eine Interface-Änderung, manchmal sogar ein gerahmter Pull Request.

Das verändert die Natur der Arbeit.

Vorher musste man oft eine lange Sequenz durchlaufen: den Bedarf formulieren, die Spec schreiben, eine Maquette machen, eine Schätzung anfordern, auf ein Zeitfenster warten, entwickeln lassen, testen, anpassen. Heute kann man bei bestimmten Themen viel schneller von der Intuition zu einem manipulierbaren Artefakt übergehen.

Und manchmal geht es nicht einmal mehr nur um Prototyping. Bei einfachen oder gut gerahmten Fällen kann man etwas fast Echtes kodieren: ein Dashboard, einen Nur-Lese-Bildschirm, eine Interface-Verbesserung, eine interne Automatisierung, eine Übersetzung, ein Release-Support.

Das bedeutet nicht, dass der PM zum klassischen Entwickler wird. Es bedeutet, dass er in Konstruktionszonen eingreifen kann, die zuvor außerhalb seines Bereichs lagen.

Hier muss man mehrere Niveaus unterscheiden.

Der PM oder PO als Prototypist verwandelt eine fachliche Absicht schnell in einen Prototyp oder POC.

Der Product Builder geht weiter: Er baut greifbare Artefakte, interne Werkzeuge, Dashboards, erste Versionen, gerahmte Beiträge.

Der Product Engineer geht noch weiter: Er kann Produkt-Verantwortung bis zum Produktionsliverable tragen. Und diese Rolle kann aus zwei Trajektorien kommen. Ein Entwickler, der zum Produkt aufsteigt. Oder ein Product-Profil, das technisch genug ist, um zur Produktion abzusteigen.

Das Kriterium ist also nicht der Beruf der Herkunft. Das Kriterium ist das Niveau der Handlungsfähigkeit.

Bleibt die Person auf dem Niveau der Maquette? Produziert sie einen Prototyp? Öffnet sie einen Pull Request? Trägt sie ein produktisierbares Liverable? Versteht sie die Risiken genug, um das, was sie produziert, korrekt validieren zu lassen?

Das ist das Kontinuum, das neu ist.

Die Rollen verschwimmen, die Verantwortlichkeiten bleiben

Das Risiko wäre zu schlussfolgern, dass, da die Rollen verschwimmen, die Verantwortlichkeiten sich auflösen.

Ich denke genau das Gegenteil.

Je mehr die Rollen verschwimmen, desto mehr muss man die Verantwortlichkeiten klären.

Eine Produktentscheidung bleibt eine Produktentscheidung. Sie gehört zum Produkt: Vision, Positionierung, Kohärenz, Abwägungen, große Prinzipien, Marktlektüre, Kundensignal.

Eine technische Entscheidung bleibt eine technische Entscheidung. Sie gehört zur Technik: Sicherheit, Performance, Skalierbarkeit, Architektur, Wartbarkeit, Plattformqualität.

Eine Erfahrungsentscheidung bleibt eine Erfahrungsentscheidung. Sie gehört zum Design oder Front: Design-System, Nutzungskohärenz, Barrierefreiheit, UX-Anspruchsniveau.

Die Organisation, die funktioniert, ist nicht jene, wo alle alles in ihrem Winkel machen. Es ist jene, wo jeder über seinen ursprünglichen Bereich hinaus eingreifen kann, weil Garanten Standards, Leitplanken und Grenzen setzen.

Ein PM kann einen Pull Request pushen. Aber er wird überprüft, akzeptiert, korrigiert oder abgelehnt.

Wenn er zehnmal hintereinander abgelehnt wird, sagt das etwas. Vielleicht hat der PM noch nicht das Niveau für diese Art von Beitrag. Vielleicht ist das Thema zu riskant. Vielleicht hat das technische Team noch keine Direktiven, Werkzeuge oder Leitplanken eingerichtet, die es anderen Profilen ermöglichen, sicher beizutragen.

Der Pull Request oder Merge Request wird dann zu einem Governance-Mechanismus. Nicht nur zu einem technischen Werkzeug.

Alles hängt vom Kompetenz-Risiko-Verhältnis ab

Die richtige Frage ist nicht: „Kann ein PM in die Produktion pushen?"

Die richtige Frage ist: „In welchem Bereich, mit welcher Kompetenz, welchem Risiko und welchen Leitplanken?"

Man braucht eine einfache Abstufung.

Geringes Risiko: Übersetzungen, Inhalte, Dashboards, Nur-Lese-Bildschirme, nicht-kritische interne Werkzeuge.

Mittleres Risiko: kleine Schreibaktionen, interne Workflows, gerahmte Interface-Änderungen.

Hohes Risiko: Zahlung, Rechte, Sicherheit, sensible Daten, kritische Fachlogik, reguliertes Produkt, Architektur.

Selbst in einem regulierten Produkt hat nicht alles dasselbe Risikoniveau. Ein Dashboard oder ein Konsultationsbildschirm kann relativ sicher sein, wenn die Regeln klar und die technische Validierung vorhanden sind. Umgekehrt kann ein scheinbar einfaches Produkt eine sehr sensible Zone enthalten, wenn es Daten, Rechte oder eine irreversible fachliche Entscheidung berührt.

Die Analogie mit einem Junior-Entwickler ist nützlich. Man gibt jemandem nicht am ersten Tag die Schlüssel des Produktmotors. Man beginnt mit einfachen Bereichen, dann erweitert man schrittweise.

Der augmentierte PM kann derselben Logik folgen: Übersetzungen, Lesen, Dashboards, kleine Schreibvorgänge, dann eventuell kritischere Beiträge, wenn Kompetenz, Kontext und Leitplanken folgen.

Der Riss zwischen PM-Profilen

Alle PMs werden nicht im gleichen Tempo Builder oder Product Engineers werden können.

Kurzfristig haben PMs mit technischem Hintergrund einen Vorteil. Sie können ein Repo lesen, einen Fehler verstehen, mit einem Code-Agenten kommunizieren, interpretieren, was generiert wurde, bestimmte Absurditäten erkennen, ein technisches Review am richtigen Punkt anfordern.

Ein PM ohne diese Kultur kann natürlich lernen. Aber er riskiert, auf die Maquette oder den oberflächlichen Prototyp beschränkt zu bleiben, solange er nicht genug versteht, was die KI produziert.

KI ist noch zu wenig zuverlässig, als dass man völlig ignorieren könnte, was unter der Haube passiert. Wenn man die produzierten Fehler nicht zumindest ansatzweise versteht, wird es schwierig, über die zuverlässige Maquette hinaus zu kommen.

Das bedeutet nicht, dass nicht-technische Profile verurteilt sind. Mittelfristig oder langfristig kann sogar das Gegenteil eintreten. Wenn Agenten viel zuverlässiger werden, könnten Profile aus der Psychologie, den Geisteswissenschaften, der Philosophie, dem Design, der Forschung oder dem Business Vorteile erlangen dank ihrer Fähigkeit, eine menschliche, soziale oder fachliche Realität fein auszudrücken.

Aber im aktuellen Zustand der Werkzeuge existiert der Riss.

PMs, die keine Builder werden wollen, werden wahrscheinlich sehr stark in anderen Dimensionen aufsteigen müssen: Strategie, Markt, Discovery, Einfluss, menschliches Verständnis, Ausdrucksqualität, Fähigkeit, Nein zu sagen und ein Team auszurichten.

Die neuen Berufe sind nicht immer Berufe

Man spricht oft von „neuen Berufen". Der Begriff ist nützlich, kann aber irreführend sein.

Nicht alle diese Rollen werden unbedingt stabilisierte HR-Titel. Manche werden zu Stellen. Andere werden als in das Team verteilte Kompetenzen bleiben. Andere wiederum werden von Product Ops, Design, Engineering oder QA absorbiert.

Der wichtige Punkt ist nicht der Titel. Es ist die Verantwortlichkeit.

Wer urteilt?

Wer baut?

Wer garantiert?

Wer bewertet?

Wer pflegt das Gedächtnis?

Wer orchestriert die Workflows?

KI macht Verantwortlichkeiten sichtbar, die manchmal implizit oder sekundär waren: die Bewertung probabilistischer Ausgaben, die durch Agenten nutzbare Dokumentation, das Produktgedächtnis, die Workflow-Orchestrierung, die Kontextqualität, die Lesbarkeit des Repos, die Klarheit der Akzeptanzkriterien.

Diese Bedürfnisse sind nicht peripher. Sie werden zentral, sobald ein Team mit Agenten arbeitet.

Der PM verschwindet nicht, das Mindestniveau steigt

Product Management verschwindet nicht.

Aber der Beruf wird weniger tolerant gegenüber Profilen, die vor allem von Koordination, Schreiben, Verfolgung und Produktion intermediärer Artefakte lebten.

Morgen wird es weniger Platz für den administrativen PM geben.

Es wird mehr Platz für zwei Arten von Profilen geben.

Auf der einen Seite jene, die genug bauen können, um das Produktlernen zu beschleunigen: prototypieren, materialisieren, testen, beitragen, manchmal bis zu einem echten Liverable pushen.

Auf der anderen Seite jene, die gut genug urteilen können, um ein Team auszurichten, das viel schneller bauen kann als zuvor: den Markt verstehen, das Signal lesen, abwägen, Nein sagen, eine Vision halten, Kohärenz schützen und Konsequenzen übernehmen.

Zwischen diesen beiden Polen werden viele Kombinationen existieren. Aber das Mindestniveau wird steigen.

KI beseitigt Product Management nicht. Sie zwingt den Beruf, das zu werden, was er immer hätte sein sollen: eine Verantwortlichkeit für Schöpfung, Urteil und Wirkung.

Anhang: Katalog der zukünftigen Produktrollen

Dieser Anhang versucht nicht, die zukünftigen LinkedIn-Titel vorherzusagen. Er beschreibt eher die Verantwortungszonen, die mit KI sichtbar werden.

Augmentierter strategischer PM

PM, der einen Teil der intermediären Ausführung automatisiert, um sich auf Vision, Abwägungen, Produktkohärenz und Kundensignal-Lektüre zu konzentrieren.

Sein Wert liegt darin, die richtigen Probleme zu wählen, zu entscheiden, wenn keine Option perfekt ist, die Positionierung zu schützen und die Ausrichtung zwischen Markt, Strategie, Nutzern und Ausführung zu pflegen.

Sein Risiko liegt darin, mit einem einfach produktiveren PM verwechselt zu werden, oder zum neuen Engpass zu werden, wenn weiterhin alle Entscheidungen zu ihm hochsteigen.

PM oder PO als Prototypist

Produktprofil, das schnell eine fachliche Absicht in einen Prototyp, POC, ein internes Werkzeug oder einen ersten testbaren Parcours mit Hilfe von KI verwandeln kann.

Sein Wert liegt darin, die Ambiguität zwischen Fachbereich, Produkt und Tech zu reduzieren.

Sein Risiko liegt darin, auf der Maquette zu bleiben oder die Entwickler zu früh bei Themen zu umgehen, die eine echte technische Reflexion erfordern.

Product Builder

Produktprofil, das direkt eine Idee in ein testbares Artefakt, einen funktionalen Prototyp, ein internes Werkzeug oder einen gerahmten Beitrag verwandeln kann.

Sein Wert liegt darin, die Zeit zwischen Intuition und Demonstration zu reduzieren.

Sein Risiko liegt darin, einen Prototyp, der funktioniert, mit einem wartbaren Produkt zu verwechseln.

Product Engineer

Profil, das Produkt-Verantwortung bis zum Produktionsliverable tragen kann: Nutzerverständnis, Lösungswahl, Konstruktion, Lieferung, Messung und Wirkung.

Er kann aus einem Entwicklerhintergrund oder einem ausreichend technischen Produkthintergrund kommen.

Sein Wert liegt darin, einen Teil des Produkturteils so nah wie möglich an der Konstruktion umzuverteilen und die Lücke zwischen Idee, Prototyp und Produktion zu reduzieren.

Sein Risiko ist doppelt: zu glauben, dass ein Entwickler ohne echten Zugang zu Kunden, Daten, Geschäftskontext und Abwägungen zum Product Engineer wird; oder zu glauben, dass ein PM ohne Fähigkeit, ein Produktionsliverable zu verstehen, validieren zu lassen und zu warten, zum Product Engineer werden kann.

Product Systems Designer

Rolle, die die durch KI gespeisten Produktsysteme entwirft: Feedback, Discovery, Spec-Generierung, Insight-Routing, lebendige Dokumentation und Release-Workflows.

Sein Wert liegt darin, die Mechanismen zu verbessern, die es dem Team ermöglichen, kontinuierlich bessere Entscheidungen zu treffen.

Sein Risiko liegt darin, zu einer zu abstrakten Funktion zu werden, wenn sie nicht mit den echten Workflows des Teams verbunden ist.

AI Product Evaluator

Rolle, die die KI-Ausgaben im Produkt bewertet: Qualität, Halluzinationen, Fehler-UX, Robustheit, fachliche Tests und Kohärenz mit der Produktabsicht.

Sein Wert liegt darin, die Qualität eines probabilistischen Produkts testbar zu machen.

Sein Risiko liegt darin, auf klassische QA reduziert zu werden, während die Bewertung auch die Produktabsicht, das Vertrauen und die Akzeptabilität betrifft.

Product Knowledge Curator

Rolle, die das Produktgedächtnis in einer Form pflegt, die von Menschen und Agenten nutzbar ist.

Sein Wert liegt darin, vergangene Entscheidungen, Kundensignal, Einschränkungen, Abwägungen und Dokumentation wirklich handlungsfähig zu machen.

Sein Risiko liegt darin, eine schwere Dokumentation statt eines lebendigen Gedächtnisses zu produzieren.

Agentisches Product Ops

Product Ops spezialisiert auf die Orchestrierung der Werkzeuge, Automatisierungen und Agenten, die die Produktarbeit unterstützen.

Sein Wert liegt darin, die KI-Workflows zu pflegen, die Product Management durchdringen: Feedback, Briefs, Discovery, Release-Notes, Dokumentation, Wirkungsmessung.

Sein Risiko liegt darin, Rauschen zu automatisieren, wenn die Qualitätskriterien und das Ownership nicht klar sind.

Drei Rollenfamilien

Man kann diese Rollen in drei Familien lesen.

Urteilsrollen: Augmentierter strategischer PM.

Konstruktionsrollen: PM oder PO als Prototypist, Product Builder, Product Engineer.

Systemrollen: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Agentisches Product Ops.

Der Titel ist weniger wichtig als die Verantwortlichkeit. In durch KI augmentierten Teams wird die zentrale Frage weniger „Was ist deine Rolle?" sein als „Was bist du in der Lage zu urteilen, zu bauen, zu garantieren, zu bewerten oder zu pflegen?"

Mehr dazu

Vier Tage Vibe Coding in der Haut eines eingerosteten PMs In 8 Tagen habe ich verstanden, dass sich der Beruf des Product Managers von Grund auf verändern wird KI sollte nicht nur dazu dienen, zehnmal mehr zu produzieren. Sie sollte uns auch zwingen, zehnmal besser zu verstehen, was wir produzieren. Im Software-Bereich wird der Vorteil nicht mehr die Technologie sein. Es wird das Verstehen des Kontexts sein.