Ich habe auf LinkedIn einen einfachen Satz veröffentlicht: Die Stelle des Product Owners kam mir schon vorher wie eine organisatorische Absurdität vor, und im Zeitalter der KI wird sie ausgesprochen schwer zu verteidigen.

66.000 Impressionen und rund vierzig Kommentare später stelle ich zwei Dinge fest. Erstens: Ich habe einen Nerv getroffen. Zweitens: Die Hälfte der Widersprüche dreht sich um ein Missverständnis, das ich sofort aus dem Weg räumen will.

Ich war nicht auf Polemik aus — die Zahl der Views ist mir egal. Und vor allem: Ich hatte genau diese Position schon vor der KI. Die Erwähnung der KI hat die Reaktionen kristallisiert, aber sie ist nicht die Grundlage meines Arguments. Sie ist sein Beschleuniger.

Der ursprüngliche Post und der gesamte Austausch stehen hier. Dieser Artikel ist meine ausgearbeitete Antwort an alle, die sich die Zeit genommen haben, mir zu widersprechen.

Was ich nicht sage

Ich sage nicht, dass die KI die Product Owner ersetzen wird.

Man hat mir zu Recht entgegnet, dass eine KI keinen Markt versteht, keinen Bedarf antizipiert, keine Vision vor einem Sponsor verteidigt, kein NO GO durchhält und sechs Monate später keine Rechenschaft ablegt. Da stimme ich zu. Voll und ganz.

Ich sage auch nicht, dass Leute mit „PO“ auf der Visitenkarte zu nichts taugen. Ich kenne hervorragende. Ich kritisiere die Aufspaltung, nicht die Menschen, die sie aushalten müssen.

Was ich sage: Das Produkt ist das, was in Produktion läuft

Eine Spezifikation beschreibt eine Absicht. Ein PRD beschreibt ein Ziel, erwartete Regeln, Szenarien. Ein Mockup beschreibt eine gewünschte Oberfläche.

Aber zwischen dieser Absicht und der Produktion passiert immer etwas. Diesen Punkt habe ich in Die Produktfrage muss vom Quellcode ausgehen ausgeführt:

Es werden Kompromisse geschlossen. Details werden nachjustiert. Randfälle tauchen auf. Während der Entwicklung fallen Entscheidungen. Technische Zwänge erzwingen kleine Änderungen am Verhalten. In einem Pull Request oder Merge Request wird diskutiert. Nicht jede Abwägung findet den Weg zurück in die ursprüngliche Dokumentation.

[...] Die Spec ist nicht die Wahrheit des Produkts. Sie ist eine zu einem bestimmten Zeitpunkt nützliche Annäherung. Die Wahrheit ist das, was läuft.

Das ist nicht schlimm. Es ist sogar normal: Ein lebendiges Produkt entsteht nicht wie ein eingefrorenes Dokument.

Aber daraus folgt etwas, das man sich ungern ansieht. Wenn die Wahrheit des Produkts zwischen der Absicht und der Produktion entsteht, dann arbeitet die Person, die vor der Produktion stehen bleibt, nicht am Produkt. Sie arbeitet an einer Absicht. Sie sieht nie die Abwägungen, die in Wirklichkeit bestimmen, was der Kunde erleben wird.

Der Kunde sieht deine Discovery nicht. Er sieht weder dein Priorisierungs-Framework noch deine schöne Roadmap. Er sieht, was in Produktion geht. Und die Qualität eines Produkts steckt in einer Ansammlung kleiner Details — und diese Details siehst du nur, wenn du bis zum Ende dranbleibst.

Daher meine Überzeugung: Wer das Produkt denkt, muss es auch ausliefern und nach der Auslieferung begleiten. Ein und dieselbe Person. Vollständiges Ownership.

Die Absurdität ist nicht der Inhalt der Stelle, sondern das, was ihre Existenz verrät

Was die Stelle des PO in meinen Augen unhaltbar macht, ist also nicht, was ein PO im Alltag tut. Es ist die Tatsache, dass eine Organisation es für sinnvoll hielt, zu trennen: den „edlen“ Teil — das Produkt denken — von dem Teil, den man delegiert: das Backlog verfolgen, die Beziehung zu den Entwicklern halten, die Produktivsetzung überwachen.

Das ist Taylorismus am Produkt.

Und diesen Film haben wir schon gesehen.

Es gab eine Zeit mit Analysten auf der einen und Programmierern auf der anderen Seite. Die einen dachten, die anderen produzierten Code am laufenden Meter. Diese Aufspaltung ist verschwunden. Heute gibt es Entwickler, die ein Problem von Anfang bis Ende übernehmen: Architektur, Code, Sicherheit, Auslieferung, Nachverfolgung. Es gibt sogar immer weniger Architekten, die vom Rest des Teams getrennt sind.

Niemand trauert den Analyst-Programmierern nach. Niemand vertritt die Ansicht, dass bessere Software entstand, als Denken und Ausführen in zwei verschiedenen Köpfen wohnten.

Ich sehe keinen Grund, warum sich das Produkt dieser Bewegung entziehen sollte.

Ich verlange von mir die Regel, die ich den Entwicklern auferlege

Es gibt ein Argument, dem ich mich vor allen anderen stellen muss, weil es mich direkt betrifft.

In Die Qualität gehört denen, die ausliefern habe ich eine Regel formuliert, die ich auf der Entwicklungsseite für nicht verhandelbar halte:

Die gesündeste Regel ist einfach: Wer den Bug erzeugt, behebt ihn.

Nicht, weil bestraft werden müsste. Nicht, weil jemand gedemütigt werden müsste. Sondern weil die Verantwortung für die Korrektur an die Verantwortung für die Produktion gebunden bleiben muss.

Und weiter:

In den meisten Fällen gilt: Wer den Fehler erzeugt hat, muss ihn beheben. Auch wenn er schon an einem wichtigen Thema sitzt. Auch wenn es die Planung durcheinanderbringt. Auch wenn es das nächste Feature verlangsamt.

Qualität verbraucht Kapazität. Sie zu verstecken macht sie nicht kostenlos.

Es stünde mir schlecht an, das von Entwicklern zu fordern und mich selbst davon auszunehmen.

Ein PM, der konzipiert und dann einem PO überlässt, die Sache bis in die Produktion zu tragen, tut genau das, was ich dem Entwickler vorwerfe, der ausliefert und zum nächsten Thema übergeht. Er externalisiert die Kosten dessen, was er produziert hat. Er sieht nie, wo sein Verständnis unzureichend war, wo die Formulierung mehrdeutig war, wo die Abwägung wacklig war. Die Schleife schließt sich nicht.

Und es ist genau diese Schleife, die Qualität erzeugt.

Qualität lässt sich nicht nachträglich delegieren. Weder auf der Code- noch auf der Produktseite.

„Du beschreibst einen schlechten PO“

Das ist der häufigste Einwand, und er kam von mehreren verschiedenen Leuten: Die Rolle eines PO besteht darin, den Bedarf zu verstehen, die Funktionalitäten aus Kundensicht zu definieren, eine Vision zu tragen, zwischen widersprüchlichen Prioritäten abzuwägen, den Wert zu maximieren.

Meine Antwort bleibt dieselbe: Das nennt man einen Product Manager. Du hast mir gerade meinen Beruf beschrieben.

Wenn deine Definition des PO meine Definition des PM abdeckt, dann sind wir uns in der Sache einig und streiten über ein Wort.

Das Problem ist: Das ist nicht das, was der Markt einstellt. Man hat mir vorgeworfen, einen PO zu beschreiben, den es nicht gibt. Sieh dir die Stellenausschreibungen an: das Backlog füllen, User Stories schreiben, die Schnittstelle zwischen Fachbereich und Devs bilden, die Zeremonien moderieren. Diesen PO gibt es überall. Er stellt sogar die Mehrheit.

Und an dieser Stelle gibt es einen Punkt, den in den Kommentaren niemand aufgegriffen hat.

Auf einem Wegwerf-Artefakt lässt sich kein Beruf gründen

Das am häufigsten vorgebrachte Argument zur Verteidigung der Rolle ist das Backlog: Der PO maximiere den Wert des Produkts, indem er das Backlog pflegt, verfeinert und priorisiert.

Nur habe ich diese Grundlage anderswo schon eingerissen, ohne die KI ein einziges Mal zu erwähnen. In Das Backlog ist keine Müllhalde:

Ein Backlog-Item dient bis zur Auslieferung. Danach verliert es einen großen Teil seines Werts.

Tickets laufen auseinander. Specs laufen auseinander. Abwägungen ändern sich während der Umsetzung. Das finale Verhalten in Produktion weicht oft von dem ab, was anfangs geschrieben wurde.

[...] Das Backlog ist keine Quelle der Wahrheit. Es ist ein temporäres Hilfsmittel zur Koordination.

Und vor allem ist es nicht mehr der Ort, an dem das Produkt gedacht wird:

Werkzeuge wie Jira, Notion oder ihre Äquivalente bleiben oft Karteikarten-Werkzeuge. Bessere Textverarbeitungen. [...] Sie können nützlich sein, um das Handeln zu koordinieren. Aber sie taugen sehr wenig, um eine Produktüberlegung aufzubauen.

[...] Das Ticket ist nicht mehr der Ort, an dem gedacht wird. Es ist der Ort, an den man das Ergebnis eines bereits strukturierten Denkens schiebt.

Wenn das Backlog also weder das Gedächtnis des Produkts noch sein Gehirn noch ein dauerhafter Vermögenswert ist — wie soll man dann einen Beruf darauf gründen, es zu pflegen?

Auf einem verbrauchbaren Artefakt lässt sich eine Funktion gründen. Kein Beruf.

Und dieses Argument hat mit der KI nichts zu tun. Es galt schon 2020.

Der Name zählt, und hier ist der Grund

Man hat mir entgegengehalten, PO sei eine Rolle in einem methodischen Rahmen, während PM ein Beruf sei. Und dass es darauf ankomme, was man tut, nicht wie man heißt.

Im Prinzip stimme ich zu. Ich habe eine Zeit lang Projektmanagement gemacht, ohne zu wissen, dass es dafür einen Namen gibt. Was man tut, zählt mehr als das Etikett.

Aber der Titel formt das Mandat.

Faktisch haben POs weniger Ownership und weniger Autonomie. Als PM bist du Owner deines Scopes, Punkt. Mehrere Leute haben es in den Kommentaren besser formuliert als ich: Der Titel PO hat oft dazu gedient, die Produktverantwortung abzuschotten, ohne das Mandat zum Entscheiden mitzugeben.

Ein PO ohne Mandat zum Abwägen ist keine Rolle. Das ist eine unbequeme Lage.

Und darin erkenne ich einen Mechanismus wieder, den ich in Warum Organisationen weiche Entscheidungen bevorzugen schon beschrieben habe:

Eine klare Entscheidung macht Verantwortung sichtbar. Sie exponiert diejenige oder denjenigen, die oder der abwägt. Sie bietet der Kritik eine Angriffsfläche. Sie zwingt dazu, dazu zu stehen, dass bestimmte Wünsche nicht berücksichtigt wurden.

Eine weiche Entscheidung verteilt diese Verantwortung. Sie verwässert sie zwischen den Beteiligten, den Meetings, den Dokumenten, den vorsichtigen Formulierungen, den aufeinanderfolgenden Freigaben.

Die Produktverantwortung in zwei Teile zu zerlegen ist derselbe Reflex, angewandt auf das Organigramm. Er erlaubt es, jemanden zu haben, der die Konsequenz trägt, ohne die Wahl gehabt zu haben, und jemanden, der die Wahl hatte, ohne die Konsequenz zu tragen.

Das Verfahren ist bequem. Es ist auch der Grund, warum niemand mehr wirklich für irgendetwas verantwortlich ist.

Wo die KI wirklich ins Spiel kommt

Mein Argument zur KI lautet nicht „sie wird die POs ersetzen“. Es ist mechanischer als das.

Die Aufspaltung in Denkende und Ausführende hatte eine wirtschaftliche Rechtfertigung. Das Übersetzen, Dokumentieren, Schreiben und Aufbereiten kostete viel Zeit. Teuer genug, dass man eine eigene Stelle schuf, um diese Betriebsschicht aufzufangen.

Lange Zeit war der PM eine Drehscheibe: Bedarfe aufnehmen, umformulieren, Dokumente produzieren, Tickets klären, aufräumen, koordinieren, priorisieren, nachhalten, nachhaken, wieder dokumentieren. Ein Teil des Berufs bestand darin, die Reibungen der Organisation auszugleichen. Am Ende haben wir eine Masse an Aufgaben als normal hingenommen, die nicht der Kern des Berufs waren, sondern nur seine technische Infrastruktur.

Diese Kosten brechen weg.

Und wenn die wirtschaftliche Rechtfertigung einer Arbeitsteilung verschwindet, überlebt die Arbeitsteilung nicht lange.

Genau hier treffen sich mein ursprünglicher Widerspruch und die KI. Die KI schafft das Problem nicht: Sie nimmt uns die letzte praktische Ausrede, damit zu leben. Man kann nicht mehr sagen: „Ja, theoretisch müsste der PM bis in die Produktion dranbleiben, aber konkret hat er keine Zeit dafür.“

Wer heute noch auf Basis einer Stellenausschreibung einstellt, die um die Weitergabe von Informationen herum gebaut ist, optimiert also einen Kreislauf, der längst überholt ist.

Die Nuance beim Schreiben

Man hat mir geantwortet: „Das Schreiben war nie der Engpass des Berufs.“

Für das Abwägen stimmt das. Entscheiden war nie ein Problem des Schreibens, und ich werde nicht das Gegenteil behaupten.

Aber im weiteren Sinne bin ich nicht einverstanden. Ich bin der einzige PM für das gesamte Unternehmen. Wenn ein Video in fünfzehn Sprachen mit Untertiteln entstehen muss, Artikel in vier oder fünf Sprachen, die Posts, die Briefings zu den Vorteilen und den hervorzuhebenden Punkten — dann ist das eine wahnwitzige Arbeit. Die KI erlaubt mir Dinge, für die ich schlicht keine Zeit hatte. Das war nicht der Engpass der Entscheidung. Aber es war sehr wohl eine Wand.

Ich sehe die KI als hervorragenden Privatsekretär. Sie nimmt meine Überlegung auf, sie verschlingt die Quellen, sie erledigt die mühsame Arbeit. Aber diejenige Person, die im Detail versteht, die auswählt, die das Risiko eingeht und dafür einsteht, ist der PM. Nicht die KI.

Und eines wird sie nie tun: die Wette eingehen.

Wenn du ein Startup bist und die Frage lautet „gehen wir voll rein oder sterben wir“, dann gehört diese Wahl den Leuten, die das Unternehmen gegründet haben. Eine KI kann die Option analysieren. Verantworten kann sie sie nicht.

Wo mich meine Kritiker weitergebracht haben

Drei Dinge nehme ich aus der Debatte mit.

Das Mandat zählt mehr als der Titel. Mehrere Leute haben das Thema dorthin zurückgeholt, und sie haben recht. Ein PM, der im Operativen und im Krisenmanagement eingesperrt ist, ohne Spielraum, eine Produktstrategie zu definieren, wird beschäftigt sein, ohne etwas Nützliches hervorzubringen. Stellen umzubenennen löst nichts, wenn das Mandat nicht mitkommt. Mein Beharren auf dem Vokabular darf das nicht verdecken.

Man kann die Stelle neu denken, statt sie abzuschaffen. Ein Tech Lead hat mir sein Team beschrieben, an einer regulierten Gesundheitssoftware mit einer Legacy-Codebase: Sie haben die Stelle nicht gestrichen, sie haben sie neu definiert. Der Entwickler trägt einen Teil der Produktvision, der PO konzipiert. Die Menschen bleiben, die Rolle ändert sich. Das ist wahrscheinlich treffender als meine ursprüngliche Formulierung, und es gehört gesagt: Unhaltbar wird der Transmissionsriemen, nicht die Menschen.

Die eigentliche Gefahr ist die Isolationsschicht. Das Problem ist nicht, dass es einen PO gibt. Es ist, wenn er zu der Schicht wird, die die Entwickler vom echten Bedarf abschneidet — unter dem Vorwand, die Devs müssten den Fachbereich nicht verstehen, sondern nur Specs ausführen. Das wird die KI noch unhaltbarer machen. Bei uns interviewen die Entwickler seit mehreren Monaten die Kunden direkt. Und vor ein paar Tagen habe ich meinen ersten Pull Request auf unser Hauptprodukt gepusht.

Zum Fachwissen korrigiere ich schließlich eine verbreitete Annahme: Es gehört nicht dem PO. Ich habe es bei CSM gefunden, die aus der Praxis kamen, bei Leuten aus dem Support. Es kann überall sein — und es muss beim PM sein. In meinem Bereich verschlinge ich Bücher und Videos zur industriellen Instandhaltung. Ich bin es mir schuldig, im Fachbereich exzellent zu sein, sonst habe ich nichts abzuwägen.

Wo ich mich nicht bewege

Man hat mir gesagt, der PO, den ich beschreibe, sei wahrscheinlich der, der ich selbst war. Möglich.

Und ich füge etwas hinzu, das unangenehmer zuzugeben ist: Es ist ausgesprochen bequem, das Backlog, das Nachhalten bei den Devs und die Produktivsetzungen loszuwerden. Der PM hat ein objektives Interesse daran, dass es die Stelle des PO gibt. Man behält den Teil, der sich im Meeting gut erzählen lässt, und delegiert den, der etwas kostet.

Genau deshalb misstraue ich ihm.

Die Denkenden von den Ausführenden zu trennen ist eine Absurdität. Nicht weil die KI kommt. Sondern weil das Produkt das ist, was in Produktion läuft — und weil man die Verantwortung für das, was man konzipiert hat, nicht delegiert.

Die KI macht dieses Argument nicht wahr.

Sie macht es unumgehbar.