Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Ich habe auf LinkedIn einen einfachen Satz veröffentlicht: Die Position des Product Owner erschien mir schon vorher wie eine organisatorische Absurdität, und im Zeitalter der KI wird sie richtig schwer zu verteidigen.
66.000 Impressionen und rund vierzig Kommentare später sind zwei Dinge klar. Erstens: Ich habe einen Nerv getroffen. Zweitens: Die Hälfte der Widersprüche beruht auf einem Missverständnis, das ich sofort aus dem Weg räumen will.
Ich war nicht auf Polemik aus — Reichweite ist mir gleichgültig. Und vor allem: Ich hatte genau diese Position schon vor der KI. Die Erwähnung der KI hat die Reaktionen ausgelöst, aber sie ist nicht das Fundament meines Arguments. Sie ist der Beschleuniger.
Der ursprüngliche Post und der komplette Verlauf stehen hier. Dieser Artikel ist meine strukturierte Antwort an alle, die sich die Zeit genommen haben zu widersprechen.
Was ich nicht sage
Ich sage nicht, dass die KI die Product Owner ersetzen wird.
Man hat mir zu Recht geantwortet, dass eine KI keinen Markt versteht, keinen Bedarf antizipiert, keine Vision vor einem Sponsor verteidigt, kein NO GO hält und sechs Monate später keine Rechenschaft ablegt. Da stimme ich zu. Vollständig.
Ich sage auch nicht, dass Menschen mit „PO“ auf der Visitenkarte nichts taugen. Ich kenne ausgezeichnete. Ich kritisiere die Aufteilung, nicht die Leute, die darunter arbeiten.
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 entwickelt:
Kompromisse werden gemacht. Details werden angepasst. Grenzfälle tauchen auf. Entscheidungen werden während der Entwicklung getroffen. Technische Beschränkungen zwingen zu leichten Verhaltensänderungen. Austausche finden in einem Pull Request oder einer Merge Request statt. Abwägungen finden nicht immer ihren Weg zurück in die ursprüngliche Dokumentation.
[...] Die Spec ist nicht die Wahrheit des Produkts. Sie ist eine nützliche Annäherung zu einem bestimmten Zeitpunkt. Die Wahrheit ist das, was läuft.
Das ist nicht schlimm. Es ist sogar normal: Ein lebendes Produkt entsteht nicht wie ein starres Dokument.
Aber es hat eine Konsequenz, die wir nicht anschauen wollen. Wenn die Wahrheit des Produkts zwischen Absicht und Produktion entsteht, dann arbeitet jemand, der vor der Produktion stehen bleibt, nicht am Produkt. Er arbeitet an einer Absicht. Er sieht nie die Abwägungen, die tatsächlich bestimmen, was der Kunde erlebt.
Der Kunde sieht deine Discovery nicht. Er sieht dein Priorisierungs-Framework nicht und auch nicht deine schöne Roadmap. Er sieht, was in Produktion geht. Und die Qualität eines Produkts liegt in einer Ansammlung kleiner Details — und diese Details siehst du nur, wenn du bis zum Ende dabei bleibst.
Daher meine Überzeugung: Wer das Produkt denkt, muss auch derjenige sein, der es liefert und nach der Lieferung begleitet. Eine einzige Person. Vollständiges Ownership.
Die Absurdität ist nicht der Inhalt der Position, sondern was ihre Existenz verrät
Was die Position des PO für mich unhaltbar macht, ist also nicht, was ein PO täglich tut. Es ist die Tatsache, dass eine Organisation es für sinnvoll hielt, den „edlen“ Teil abzutrennen — das Produkt zu denken — von dem Teil, den man delegiert: das Backlog verfolgen, die Beziehung zu den Entwicklern halten, den Release im Auge behalten.
Das ist Taylorismus, angewandt auf das 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 Fließband. Diese Aufteilung ist verschwunden. Heute gibt es Entwickler, die ein Problem von Anfang bis Ende übernehmen: Architektur, Code, Sicherheit, Lieferung, Nachverfolgung. Es gibt sogar immer weniger Architekten, die vom Rest des Teams getrennt sind.
Niemand trauert den Analyst-Programmierern nach. Niemand behauptet, wir hätten bessere Software gebaut, als Denken und Ausführung in zwei verschiedenen Köpfen lebten.
Ich sehe keinen Grund, warum das Produkt dieser Bewegung entgehen sollte.
Ich halte mich an die Regel, die ich Entwicklern auferlege
Es gibt ein Argument, dem ich mich vor allen anderen stellen muss, weil es direkt auf mich zeigt.
In Qualität gehört denen, die liefern habe ich eine Regel festgehalten, die ich auf der Engineering-Seite für nicht verhandelbar halte:
Die gesündeste Regel ist einfach: Wer den Bug erzeugt, behebt ihn.
Nicht um zu bestrafen. [...] Sondern weil die Verantwortung für die Korrektur mit der Verantwortung für die Produktion verbunden bleiben muss.
Und weiter:
In den meisten Fällen muss ein Entwickler, der den Defekt erzeugt hat, ihn beheben. Auch wenn er schon an einem wichtigen Thema arbeitet. Auch wenn das die Planung stört. Auch wenn das die nächste Feature verlangsamt.
Qualität kostet Kapazität. Sie zu verstecken macht sie nicht kostenlos.
Ich wäre schlecht beraten, das von Entwicklern zu fordern und mich selbst davon auszunehmen.
Ein PM, der konzipiert und dann einem PO die Aufgabe übergibt, die Sache bis in die Produktion zu tragen, tut genau das, was ich dem Entwickler vorwerfe, der liefert und zum nächsten Thema weiterzieht. 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 wackelig war. Der Kreis schließt sich nicht.
Und genau dieser Kreis erzeugt Qualität.
Qualität lässt sich nicht nachträglich delegieren. Nicht auf der Code-Seite und nicht auf der Produktseite.
„Du beschreibst einen schlechten PO“
Das ist der häufigste Einwand, und er kam von mehreren verschiedenen Personen: Die Rolle eines PO besteht darin, den Bedarf zu verstehen, die Funktionen aus Kundensicht zu definieren, eine Vision zu tragen, zwischen widersprüchlichen Prioritäten abzuwägen, den Wert zu maximieren.
Meine Antwort bleibt gleich: Das nennt man Product Manager. Du hast gerade meinen Beruf beschrieben.
Wenn deine Definition von PO meine Definition von PM abdeckt, dann sind wir uns inhaltlich einig und streiten über ein Wort.
Das Problem ist, dass der Markt nicht danach einstellt. Man hat mir vorgeworfen, einen PO zu beschreiben, den es nicht gibt. Öffne die Stellenanzeigen: das Backlog füllen, die User Stories schreiben, zwischen Fachbereich und Devs vermitteln, die Zeremonien moderieren. Diesen PO gibt es überall. Er ist sogar die Mehrheit.
Und da gibt es einen Punkt, den niemand in den Kommentaren angesprochen hat.
Niemand baut einen Beruf auf einem Wegwerf-Artefakt
Das häufigste Argument zur Verteidigung der Rolle ist das Backlog: Der PO maximiert den Produktwert, indem er es pflegt, verfeinert und priorisiert.
Nur habe ich dieses Fundament schon woanders abgerissen, ohne die KI ein einziges Mal zu erwähnen. In Das Backlog ist kein Mülleimer:
Ein Backlog-Item dient bis zur Lieferung. Danach verliert es einen Großteil seines Werts.
Tickets desynchronisieren sich. Specs desynchronisieren sich. Abwägungen ändern sich während der Umsetzung. Das endgültige Verhalten in der Produktion weicht oft von dem ab, was anfangs geschrieben wurde.
[...] Das Backlog ist keine Quelle der Wahrheit. Es ist ein temporäres Koordinationsinstrument.
Und vor allem ist es nicht mehr der Ort, an dem man das Produkt denkt:
Werkzeuge wie Jira, Notion oder ihre Entsprechungen bleiben oft Karten-Werkzeuge. Verbesserte Textverarbeitungen. [...] Sie können nützlich sein, um Aktionen zu koordinieren. Aber sie sind sehr schwach darin, eine Produktreflexion aufzubauen.
[...] Das Ticket ist nicht mehr der Ort, wo man denkt. Es ist der Ort, wo man das Ergebnis eines bereits strukturierten Gedankens hineinschiebt.
Wenn das Backlog also weder das Gedächtnis des Produkts noch das Gehirn des Produkts noch ein dauerhafter Wert ist — wie baut man dann einen Beruf darauf, es zu pflegen?
Auf einem verbrauchbaren Artefakt kann man eine Funktion aufbauen. Keinen Beruf.
Beachte: Dieses Argument hat nichts mit KI zu tun. Es war schon 2020 wahr.
Der Name zählt, und zwar deshalb
Man hat mir entgegnet, PO sei eine Rolle in einem methodischen Rahmen, PM dagegen ein Beruf. Wichtig sei, was man tut, nicht wie man heißt.
Im Prinzip stimme ich zu. Ich habe Project Management gemacht, als ich noch nicht wusste, dass das einen Namen hat. Was man tut, zählt mehr als das Etikett.
Aber der Titel formt das Mandat.
In der Praxis haben POs weniger Ownership und weniger Autonomie. Als PM bist du Owner deines Scope, Punkt. Mehrere Leute haben es in den Kommentaren besser formuliert als ich: Der Titel PO diente oft dazu, die Produktverantwortung abzuschotten, ohne das Entscheidungsmandat zu geben.
Ein PO ohne Abwägungsmandat ist keine Rolle. Es ist eine unbequeme Position.
Und darin erkenne ich einen Mechanismus, den ich in Warum Organisationen weiche Entscheidungen bevorzugen schon beschrieben habe:
Eine klare Entscheidung macht die Verantwortung sichtbar. Sie setzt denjenigen, der abwägt, der Kritik aus. Sie zwingt dazu anzuerkennen, dass bestimmte Anliegen nicht berücksichtigt wurden.
Eine weiche Entscheidung verteilt diese Verantwortung. Sie verdünnt sie auf Teilnehmer, Meetings, Dokumente, vorsichtige Formulierungen, sukzessive Freigaben.
Die Produktverantwortung in zwei Teile zu schneiden, ist derselbe Reflex, angewandt auf das Organigramm. So hat man jemanden, der die Konsequenz trägt, ohne die Wahl gehabt zu haben, und jemanden, der die Wahl hatte, ohne die Konsequenz zu tragen.
Die Anordnung ist bequem. Sie 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 Aufteilung in Denker und Ausführende hatte eine wirtschaftliche Rechtfertigung. Die Arbeit des Übersetzens, Dokumentierens, Schreibens und Formatierens kostete viel Zeit. Teuer genug, um eine eigene Position zu schaffen, die diese Betriebsschicht absorbiert.
Lange war der PM eine Drehscheibe: Bedarfe sammeln, umformulieren, Dokumente produzieren, Tickets klären, Ordnung schaffen, koordinieren, priorisieren, nachverfolgen, erinnern, wieder dokumentieren. Ein Teil des Berufs bestand darin, die Reibung der Organisation auszugleichen. Wir haben am Ende eine Masse an Aufgaben als normal akzeptiert, die nicht der Kern des Berufs waren, sondern nur seine technische Infrastruktur.
Diese Kosten brechen ein.
Und wenn die wirtschaftliche Rechtfertigung einer Arbeitsteilung verschwindet, überlebt die Arbeitsteilung nicht lange.
Genau dort treffen sich mein ursprünglicher Widerspruch und die KI. Die KI schafft das Problem nicht: Sie nimmt die letzte praktische Ausrede weg, damit zu leben. Man kann nicht mehr sagen: „Ja, theoretisch sollte der PM bis in die Produktion begleiten, aber praktisch hat er keine Zeit.“
Heute noch nach einer Stellenbeschreibung einzustellen, die um die Weitergabe von Information herum gebaut ist, heißt also, einen längst überholten Ablauf zu optimieren.
Die Nuance zum Schreiben
Man hat mir geantwortet: „Das Schreiben war nie der Engpass des Berufs.“
Bei der Abwägung stimmt das. Entscheiden war nie ein Schreibproblem, und ich behaupte nichts anderes.
Aber im weiteren Sinne widerspreche ich. Ich bin der einzige PM für das ganze Unternehmen. Wenn ein Video in fünfzehn Sprachen mit Untertiteln produziert werden muss, Artikel in vier oder fünf Sprachen, die Posts, die Briefings zu Vorteilen und hervorzuhebenden Punkten — dann ist das ein wahnsinniger Aufwand. Die KI erlaubt mir Dinge, für die ich einfach keine Zeit hatte. Es war nicht der Engpass der Entscheidung. Aber es war sehr wohl eine Wand.
Ich sehe die KI als ausgezeichnete persönliche Assistenz. Sie nimmt mein Denken auf, verschlingt die Quellen, macht die mühsame Arbeit. Aber wer fein versteht, wer wählt, wer das Risiko eingeht und wer dafür einsteht, ist der PM. Nicht die KI.
Und eines wird sie nie tun: die Wette.
Wenn du ein Startup bist und die Frage lautet „wir gehen aufs Ganze oder wir sterben“, dann gehört diese Wahl den Menschen, die das Unternehmen gegründet haben. Eine KI kann die Option analysieren. Sie kann sie nicht verantworten.
Wo meine Kritiker mich weitergebracht haben
Drei Dinge nehme ich aus der Debatte mit.
Das Mandat zählt mehr als der Titel. Mehrere Leute haben das Thema dorthin verlagert, und sie haben recht. Ein PM, der im Operativen und im Krisenmanagement gefangen ist, ohne Spielraum für eine Produktstrategie, wird beschäftigt sein, ohne etwas Nützliches zu produzieren. Positionen umzubenennen löst nichts, wenn das Mandat nicht folgt. Mein Beharren auf dem Vokabular darf das nicht verdecken.
Man kann die Position neu denken, statt sie zu streichen. Ein Tech Lead hat mir sein Team beschrieben, auf regulierter Gesundheitssoftware mit einer Legacy-Codebase: Sie haben die Position 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 Übertragungsriemen, nicht die Menschen.
Die eigentliche Gefahr ist die Isolationsschicht. Das Problem ist nicht, dass ein PO existiert. Das Problem ist, wenn er zur Schicht wird, die Entwickler vom echten Bedarf abschneidet — unter dem Vorwand, Devs müssten das Fachliche nicht verstehen, sondern nur Specs ausführen. Das wird die KI noch unhaltbarer machen. Bei uns interviewen die Entwickler die Kunden seit mehreren Monaten direkt. Und vor wenigen Tagen habe ich meinen ersten Pull Request auf unserem Hauptprodukt eingereicht.
Zur Fachexpertise korrigiere ich noch eine verbreitete Annahme: Sie ist nicht Eigentum des PO. Ich habe sie bei CSMs gefunden, die aus der Praxis kamen, und bei Support-Leuten. Sie kann überall sitzen — und sie muss beim PM sitzen. In meinem Bereich verschlinge ich Bücher und Videos zur industriellen Instandhaltung. Ich schulde es mir, fachlich exzellent zu sein, sonst habe ich nichts abzuwägen.
Wo ich nicht nachgebe
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 sehr bequem, das Backlog, die Begleitung der Devs und die Releases loszuwerden. Der PM hat ein objektives Interesse daran, dass die Position PO existiert. Man behält den Teil, der sich im Meeting gut erzählt, und delegiert den Teil, der kostet.
Genau deshalb bin ich misstrauisch.
Denker und Ausführende zu trennen ist eine Absurdität. Nicht weil die KI kommt. Weil das Produkt das ist, was in Produktion läuft — und weil man die Verantwortung für das, was man entworfen hat, nicht delegiert.
Die KI macht dieses Argument nicht wahr.
Sie macht es unumgehbar.
Mehr dazu
Qualität gehört denen, die liefern Das Backlog ist kein Mülleimer: Es ist ein Werkzeug zum Handeln Die Produktfrage muss vom Quellcode ausgehen