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

Und vor drei Tagen habe ich meine erste Pull Request für unser Hauptprodukt aufgemacht.

Diese beiden Sätze fassen besser als jede Analyse zusammen, was in Produktteams mit KI gerade passiert. Die Entwickler rücken näher an das Problem, an den Kunden, an das Produkt-Ownership. Die PM rücken näher an den Prototyp, an den Code und manchmal bis in die Produktion.

Man könnte darin zwei isolierte Anekdoten sehen. Ich halte es im Gegenteil für den Anfang einer tieferen Umkehrung. Die historischen Rollen von Product Management, Entwicklung und Design werden unschärfer. Die Grenzen verschieben sich. Aber anders als man vermuten könnte, heißt das weder, dass künftig jeder alles macht, noch dass die Verantwortung verschwindet.

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

Früher lautete die Beschränkung meist: „Wie viel können wir bauen?“

Künftig lautet sie eher: „Was müssen wir bauen? Warum? Für wen? In welcher Reihenfolge? Mit welchen Risiken?“

Diese Verschiebung lässt die Rollen verschwimmen.

Wenn die Entwickler mehr produzieren, wird der PM zum Engpass

Einer der Auslöser 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. Ein Entwickler, der ohnehin selbstständig arbeitete, kann bei manchen Aufgaben plötzlich drei-, vier- oder sechsmal schneller sein. Ein Team mit begrenzter Delivery-Fähigkeit kann auf einmal sehr viel mehr produzieren, das getestet, abgewogen, gegengelesen und priorisiert werden will.

Das Problem ist: Die Entscheidungsfähigkeit steigt nicht automatisch im selben Tempo mit.

Wenn weiterhin alles über den PM laufen muss, wird er schnell zum neuen Sättigungspunkt des Systems. Es geht dann nicht mehr bloß darum, Specs zu schreiben oder ein Backlog zu pflegen. Die Last verschiebt sich zur Priorisierung, zur Produktkohärenz, zur Prüfung des Kundensignals, zu Marktabwägungen, zur Wirkung beim Nutzer, zur Strategie und zum Umgang mit den Folgen.

Eine Organisation kann dann glauben, sie habe ihr Geschwindigkeitsproblem gelöst, weil die Entwickler mehr produzieren. Tatsächlich hat sie die Blockade nur verschoben.

Es gibt drei mögliche Antworten.

Die erste besteht darin, mehr PM einzustellen. Manchmal ist das nötig, aber es ist nicht immer die richtige Antwort. Bleibt das Modell dasselbe, 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-Unterlagen, erste Analysen, Übersetzungen, Zusammenfassungen, Demo-Videos, Screenshots, PR-Bausteine. Das schafft Zeit, löst die Grundfrage aber nicht.

Die dritte besteht darin, einen Teil des Produkt-Ownerships an die weiterzugeben, die bauen. Genau da fangen die Rollen wirklich an zu verschwimmen.

Den Code zu beschleunigen reicht nicht

Ein Fehler wäre, zu glauben, die KI verändere die Organisation allein deshalb, weil sie die Entwicklung beschleunigt.

Lokale Geschwindigkeit erzeugt nicht automatisch Wert. Sie kann sogar mehr Unordnung erzeugen, wenn sich der gesamte Workflow nicht ändert. Ein Team kann mehr Code, mehr Prototypen, mehr Dokumente und mehr Tickets produzieren — und dabei schlechtere Entscheidungen treffen.

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

Setzt man KI-Agenten auf einen unveränderten Prozess, riskiert man nur, die Engpässe zu verschieben. Der Code wird schneller, dann blockiert das Produkt. Das Produkt wird schneller, dann blockiert das Design. Das Design wird schneller, dann blockiert die technische Prüfung. Die Prüfung wird schneller, dann kommen Go-to-Market oder Support nicht mehr hinterher.

Die Frage lautet also nicht nur: „Wie machen wir die Entwickler schneller?“

Sie lautet: „Wie machen wir das gesamte System fähig, diese Geschwindigkeit aufzunehmen, ohne an Qualität, Kohärenz und Verantwortung zu verlieren?“

Deshalb erschöpfen sich die neuen Rollen nicht in „PM, der programmiert“ oder „Entwickler, der Produkt macht“. Ein Teil des neuen Bedarfs betrifft die Orchestrierung von Workflows, die Bewertung von KI-Outputs, das Produktgedächtnis, die Qualität der Entscheidungen, die Lesbarkeit der Repos und die Fähigkeit, Agenten einen verlässlichen Kontext zu geben.

Was die KI im Product Management zur Selbstverständlichkeit macht

Lange Zeit haben sich manche PM über ziemlich unterschiedliche Stärken und Neigungen abgehoben.

Manche waren sehr gut im Schreiben. Andere in Data. Andere im Benchmark, im Produktmarketing, in der Discovery, im Experience Design oder in der Delivery-Koordination. Diese Unterschiede verschwinden nicht vollständig. Aber ein Teil ihres unterscheidenden Werts sinkt.

Mit KI werden viele Fähigkeiten leichter zugänglich:

• eine korrekte Spec schreiben;
• eine erste Datenanalyse erstellen;
• einen Benchmark machen;
• eine Release Note verfassen;
• ein brauchbares Mockup bauen;
• Interviews zusammenfassen;
• eine erste Fassung einer User Journey erzeugen;
• einen Bedarf in einen Prototyp verwandeln.

Diese Fähigkeiten werden nicht nutzlos. Ein PM muss weiterhin eine Spec beurteilen, eine Analyse hinterfragen, ein Mockup lesen, eine Interview-Zusammenfassung verstehen oder einen Prototyp einschätzen können. Aber diese Artefakte erstmals herzustellen, wird weniger selten.

Früher konnte sich ein PM stark abheben, weil er schnell eine gute Spec, einen klaren Benchmark, eine verwertbare Zusammenfassung oder ein erstes Mockup produzieren konnte. Künftig ist das eher das Mindestniveau.

Das macht jene PM verwundbar, deren Stärke vor allem in der mittleren Ausführung lag. Wer koordiniert, geschrieben, verwaltet, nachgehalten, umformuliert und ordentliche Artefakte produziert hat, ohne ein starkes Produkturteil zu tragen, verliert womöglich einen Teil seines Werts.

Der Produktberuf verschwindet nicht. Aber sein Mindestniveau steigt.

Was schwer bleibt: die Urteilskraft am Produkt

Wenn Produzieren leichter wird, wird die Wahl dessen, was man produziert, kritischer.

Genau darin behält der PM-Beruf seinen Wert. Nicht in der Fähigkeit, mehr Artefakte zu erzeugen, sondern in der Fähigkeit, zu wählen, abzuwägen und dafür einzustehen.

Was schwer bleibt:

• das richtige Problem wählen;
• einen Markt verstehen;
• das echte Signal hinter den Kundenwünschen lesen;
• zwischen kurzer Frist und Strategie abwägen;
• Nein sagen;
• eine kohärente Vision durchhalten;
• Ausrichtung herstellen;
• für die produktbezogenen, wirtschaftlichen, technischen und menschlichen Folgen einer Entscheidung einstehen.

Der strategisch erweiterte PM ähnelt immer mehr einer Art kleinem CPO. Weniger Verwaltung des Delivery, weniger mechanische Produktion von Deliverables, dafür mehr Abwägungen, in denen keine Option perfekt ist.

Besonders wichtig wird die Rolle dort, wo es keine gute Lösung gibt. Nur zwei oder drei schlechte Optionen, mit unterschiedlichen Kosten, unterschiedlichen Risiken, unterschiedlichen politischen Wirkungen, unterschiedlichen Folgen für den Kunden. In solchen Momenten kann die KI beim Analysieren helfen. Einstehen kann sie nicht.

Der erweiterte PM ist also nicht einfach ein PM, der schneller ist. Es ist ein PM, der besser urteilen muss.

Die Differenzierung wandert zum Kundensignal

Wenn alle schneller bauen können, ist schnell bauen kein ausreichender Vorteil mehr.

Die reine Codeproduktion wird zum Teil zur Commodity. Nicht die Software. Nicht das Engineering. Nicht Architektur, Sicherheit oder Wartbarkeit. Aber die Fähigkeit, rasch eine erste Fassung zu produzieren, wird weniger selten.

Die echte Differenzierung wandert damit zu dem, was Wettbewerber nicht einfach generieren können:

• die Qualität des Kundensignals;
• eigene Daten;
• Fachwissen;
• Distribution;
• Vertrauen;
• operative Randbedingungen;
• angesammelte Lernerfahrungen;
• die Fähigkeit, richtig zu deuten, was Kunden wirklich verlangen.

Ein schneller Prototyp ist nur dann etwas wert, wenn er ein echtes Signal prüft. Sonst beschleunigt er bloß eine falsche Richtung.

Die strategische Frage lautet also: Auf welchem eigenen Vorteil bauen wir auf?

Ein KI-gestütztes Team kann eine Menge produzieren. Aber wenn es seinen Markt nicht besser liest, seine Nutzer nicht besser versteht, ein starkes Signal nicht von gut formuliertem Rauschen unterscheiden kann, produziert es nur schneller Mittelmäßiges.

Das ist ein weiterer Grund, warum der PM nicht verschwindet. Die Rolle verschiebt sich zur Qualität, mit der die Wirklichkeit gelesen wird.

Die Entwickler rücken näher ans Produkt

Entwickler waren nie bloße Ausführende.

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

In diesen Zonen treffen Entwickler längst Produktentscheidungen.

Die KI macht diese Realität sichtbarer. Schreibt ein Agent einen Teil des Codes, muss der Mensch das erwartete Verhalten ausformulieren, die Edge Cases abwägen, die Akzeptanzkriterien festlegen, das Ergebnis prüfen. Die Mikroentscheidungen, die früher stillschweigend in der Implementierung aufgingen, werden sichtbarer — und damit wichtiger einzugrenzen.

Das ist einer der Gründe, warum Entwickler näher ans Produkt rücken. Sie sprechen mehr mit Kunden, verstehen die Probleme besser, tragen mehr Ownership für ihre Features, treffen lokale Entscheidungen deutlicher.

Aber es gibt eine wichtige Nuance: Ein Entwickler wird nicht zum Product Engineer, bloß weil er einen Coding-Agenten nutzt oder schneller ausliefert.

Ohne Zugang zu Kunden, Daten, Geschäftskontext und Abwägungen droht ihm nur, zum Bediener von Coding-Agenten zu werden. Mehr Verantwortung, mehr Druck, aber nicht unbedingt mehr Produktmacht.

Der echte Product Engineer ist nicht bloß ein schneller Entwickler. Es ist jemand, der einen Teil der Urteilskraft am Produkt ganz nah an den Bau trägt.

Die PM rücken näher an den Bau

Die Gegenbewegung gibt es auch.

Mit KI kann ein PM eine Idee sehr viel schneller greifbar machen als früher. Ein Mockup, einen Prototyp, ein internes Werkzeug, ein Dashboard, eine Übersetzung, eine Änderung an der Oberfläche, manchmal sogar eine eingegrenzte PR.

Das verändert die Natur der Arbeit.

Früher musste man oft eine lange Abfolge durchlaufen: den Bedarf formulieren, die Spec schreiben, ein Mockup bauen, eine Schätzung anfragen, auf einen Slot warten, entwickeln lassen, testen, nachjustieren. Heute kommt man bei manchen Themen viel schneller von der Intuition zu etwas, das man in die Hand nehmen kann.

Und manchmal geht es nicht einmal mehr nur ums Prototypen. In einfachen oder gut eingegrenzten Fällen lässt sich etwas fast Echtes bauen: ein Dashboard, ein Nur-Lese-Screen, eine Verbesserung an der Oberfläche, eine interne Automatisierung, eine Übersetzung, eine Release-Unterlage.

Das heißt nicht, dass der PM zum Entwickler im klassischen Sinn wird. Es heißt, dass er in Baubereichen tätig werden kann, die früher außerhalb seines Zuständigkeitsbereichs lagen.

Hier sind mehrere Niveaus zu unterscheiden.

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

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

Der Product Engineer geht noch weiter: Er kann Produktverantwortung bis zum Deliverable in Produktion tragen. Und diese Rolle kann aus zwei Richtungen kommen. Ein Entwickler, der näher ans Produkt rückt. Oder ein hinreichend technisches Produktprofil, das näher an die Produktion rückt.

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

Bleibt die Person auf Höhe des Mockups? Produziert sie einen Prototyp? Macht sie eine PR auf? Trägt sie ein produktionsfähiges Deliverable? Versteht sie die Risiken gut genug, um das, was sie produziert, richtig prüfen zu lassen?

Neu ist dieses Kontinuum.

Die Rollen verschwimmen, die Verantwortung bleibt

Das Risiko wäre, daraus zu schließen, dass sich die Verantwortung auflöst, weil die Rollen verschwimmen.

Ich denke genau das Gegenteil.

Je mehr die Rollen verschwimmen, desto klarer muss die Verantwortung geregelt sein.

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

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

Eine Experience-Entscheidung bleibt eine Experience-Entscheidung. Sie gehört zum Design oder zum Frontend: Design System, Konsistenz im Gebrauch, Barrierefreiheit, UX-Anspruch.

Die Organisation, die funktioniert, ist nicht die, in der jeder alles für sich allein macht. Es ist die, in der jeder über sein ursprüngliches Feld hinaus tätig werden kann, weil Verantwortliche die Standards, die Leitplanken und die Grenzen setzen.

Ein PM kann eine PR aufmachen. Aber sie wird gegengelesen, angenommen, korrigiert oder abgelehnt.

Wird sie zehnmal hintereinander abgelehnt, sagt das etwas. Vielleicht hat der PM für diese Art von Beitrag noch nicht das Niveau. Vielleicht ist das Thema zu riskant. Vielleicht hat das Technikteam auch noch nicht die Richtlinien, Werkzeuge oder Leitplanken geschaffen, die anderen Profilen einen sicheren Beitrag erlauben.

Die PR oder MR wird damit zu einem Mechanismus der Governance. Nicht bloß zu einem technischen Werkzeug.

Alles hängt vom Paar Kompetenz / Risiko ab

Die richtige Frage lautet nicht: „Darf ein PM in die Produktion deployen?“

Die richtige Frage lautet: „In welchem Zuständigkeitsbereich, mit welcher Kompetenz, welchem Risiko und welchen Leitplanken?“

Es braucht eine einfache Abstufung.

Geringes Risiko: Übersetzungen, Inhalte, Dashboards, Nur-Lese-Screens, unkritische interne Werkzeuge.

Mittleres Risiko: kleine schreibende Aktionen, interne Workflows, eingegrenzte Änderungen an der Oberfläche.

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

Selbst in einem regulierten Produkt hat nicht alles dasselbe Risikoniveau. Ein Dashboard oder ein Ansichtsscreen kann relativ sicher sein, wenn die Regeln klar sind und die technische Prüfung stattfindet. Umgekehrt kann ein scheinbar einfaches Produkt eine sehr heikle Zone enthalten, sobald es Daten, Berechtigungen oder eine unumkehrbare fachliche Entscheidung berührt.

Der Vergleich mit einem Junior-Entwickler hilft. Man gibt niemandem am ersten Tag die Schlüssel zum Herzstück des Produkts. Man fängt mit einfachen Bereichen an und erweitert dann schrittweise.

Der erweiterte PM kann derselben Logik folgen: Übersetzungen, Nur-Lese-Zugriffe, Dashboards, kleine Schreibvorgänge, dann eventuell kritischere Beiträge, wenn Kompetenz, Kontext und Leitplanken mithalten.

Der Bruch zwischen den PM-Profilen

Nicht alle PM werden im selben Tempo Builder oder Product Engineer werden können.

Kurzfristig sind PM mit technischem Hintergrund im Vorteil. Sie können ein Repo lesen, einen Fehler verstehen, mit einem Coding-Agenten sprechen, das Generierte deuten, manche Absurditäten erkennen, an der richtigen Stelle eine technische Review anfragen.

Ein PM ohne diese Kultur kann das natürlich lernen. Aber er bleibt womöglich auf das Mockup oder den oberflächlichen Prototyp beschränkt, solange er nicht genug versteht, was die KI produziert.

Die KI ist noch zu wenig verlässlich, um völlig zu ignorieren, was unter der Haube passiert. Wer die produzierten Fehler nicht ein Stück weit versteht, kommt kaum über das belastbare Mockup hinaus.

Das heißt nicht, dass nicht-technische Profile verloren sind. Mittel- oder langfristig kann sogar das Gegenteil eintreten. Werden die Agenten deutlich verlässlicher, könnten Profile aus Psychologie, Literatur, Philosophie, Design, Forschung oder Business im Vorteil sein, weil sie eine menschliche, soziale oder fachliche Wirklichkeit fein ausdrücken können.

Aber im aktuellen Zustand der Werkzeuge gibt es diesen Bruch.

PM, die keine Builder werden wollen, müssen auf anderen Dimensionen wohl sehr stark zulegen: Strategie, Markt, Discovery, Einfluss, Menschenverständnis, Ausdrucksqualität, die 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 in die Irre führen.

Nicht alle diese Rollen werden zwangsläufig zu festen HR-Titeln. Manche werden zu Stellen. Andere bleiben Kompetenzen, die im Team verteilt sind. Wieder andere werden von Product Ops, Design, Engineering oder QA aufgenommen.

Entscheidend ist nicht der Titel. Entscheidend ist die Verantwortung.

Wer urteilt?

Wer baut?

Wer steht ein?

Wer bewertet?

Wer pflegt das Gedächtnis?

Wer orchestriert die Workflows?

Die KI macht Verantwortlichkeiten sichtbar, die bislang manchmal implizit oder zweitrangig waren: die Bewertung probabilistischer Outputs, eine von Agenten verwertbare Dokumentation, das Produktgedächtnis, die Orchestrierung der Workflows, die Qualität des Kontexts, die Lesbarkeit des Repos, die Klarheit der Akzeptanzkriterien.

Diese Bedarfe sind nicht randständig. 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 nachsichtig gegenüber Profilen, die vor allem von Koordination, Schreibarbeit, Nachverfolgung und der Produktion von Zwischenartefakten gelebt haben.

Künftig 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 Lernen am Produkt zu beschleunigen: Prototypen bauen, greifbar machen, testen, beitragen, manchmal bis zu einem echten Deliverable gehen.

Auf der anderen jene, die gut genug urteilen können, um ein Team auszurichten, das viel schneller bauen kann als früher: den Markt verstehen, das Signal lesen, abwägen, Nein sagen, eine Vision durchhalten, die Kohärenz schützen und für die Folgen einstehen.

Zwischen diesen beiden Polen wird es viele Mischformen geben. Aber das Mindestniveau wird steigen.

Die KI schafft Product Management nicht ab. Sie zwingt den Beruf, wieder das zu werden, was er immer hätte sein sollen: eine Verantwortung für Gestaltung, Urteil und Wirkung.

Anhang: Katalog der künftigen Produktrollen

Dieser Anhang will keine künftigen LinkedIn-Titel voraussagen. Er beschreibt eher die Verantwortungszonen, die mit der KI sichtbar werden.

Strategisch erweiterter PM

PM, der einen Teil der mittleren Ausführung automatisiert, um sich auf Vision, Abwägungen, Produktkohärenz und das Lesen des Kundensignals 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 halten.

Sein Risiko ist, mit einem bloß produktiveren PM verwechselt zu werden — oder zum neuen Engpass zu werden, wenn weiterhin jede Entscheidung bei ihm landet.

PM oder PO als Prototypist

Produktprofil, das mithilfe der KI eine fachliche Absicht rasch in einen Prototyp, POC, ein internes Werkzeug oder eine erste testbare User Journey verwandeln kann.

Sein Wert liegt darin, die Mehrdeutigkeit zwischen Fachbereich, Produkt und Technik zu verringern.

Sein Risiko ist, auf Höhe des Mockups stehen zu bleiben oder die Entwickler zu früh zu umgehen, bei Themen, die eine echte technische Überlegung verlangen.

Product Builder

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

Sein Wert liegt darin, die Zeit zwischen Intuition und Demonstration zu verkürzen.

Sein Risiko ist, einen funktionierenden Prototyp mit einem wartbaren Produkt zu verwechseln.

Product Engineer

Profil, das Produktverantwortung bis zum Deliverable in Produktion tragen kann: Nutzerverständnis, Lösungswahl, Bau, Auslieferung, Messung und Wirkung.

Es kann aus einem Entwickler-Hintergrund kommen oder aus einem hinreichend technischen Produkt-Hintergrund.

Sein Wert liegt darin, einen Teil der Urteilskraft am Produkt ganz nah an den Bau zu verlagern und den Abstand zwischen Idee, Prototyp und Produktion zu verkleinern.

Sein Risiko ist doppelt: zu glauben, ein Entwickler werde zum Product Engineer ohne echten Zugang zu Kunden, Daten, Geschäftskontext und Abwägungen; oder zu glauben, ein PM könne Product Engineer werden, ohne ein Deliverable in Produktion verstehen, prüfen lassen und pflegen zu können.

Product Systems Designer

Rolle, die die KI-gestützten Produktsysteme entwirft: Feedback, Discovery, Erzeugung von Specs, Routing von Insights, lebende Dokumentation und Release-Workflows.

Ihr Wert liegt darin, die Mechanismen zu verbessern, mit denen das Team laufend bessere Entscheidungen trifft.

Ihr Risiko ist, zu einer zu abstrakten Funktion zu werden, wenn sie nicht an die realen Workflows des Teams angebunden ist.

AI Product Evaluator

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

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

Ihr Risiko ist, auf klassisches QA reduziert zu werden, obwohl die Bewertung auch die Produktabsicht, das Vertrauen und die Akzeptanz betrifft.

Product Knowledge Curator

Rolle, die das Produktgedächtnis in einer Form pflegt, die für Menschen wie für Agenten verwertbar ist.

Ihr Wert liegt darin, vergangene Entscheidungen, das Kundensignal, die Randbedingungen, die Abwägungen und die Dokumentation wirklich handhabbar zu machen.

Ihr Risiko ist, eine schwerfällige Dokumentation zu produzieren statt eines lebenden Gedächtnisses.

Agentische Product Ops

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

Ihr Wert liegt darin, die KI-Workflows zu pflegen, die quer durch das Product Management laufen: Feedback, Briefs, Discovery, Release Notes, Dokumentation, Wirkungsmessung.

Ihr Risiko ist, Rauschen zu automatisieren, wenn die Qualitätskriterien und das Ownership nicht klar sind.

Drei Familien von Rollen

Man kann diese Rollen in drei Familien lesen.

Die Urteilsrollen: strategisch erweiterter PM.

Die Baurollen: PM oder PO als Prototypist, Product Builder, Product Engineer.

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

Der Titel zählt weniger als die Verantwortung. In KI-gestützten Teams wird die zentrale Frage weniger „Was ist deine Rolle?“ lauten als „Was kannst du beurteilen, bauen, garantieren, bewerten oder pflegen?“