Der Product Manager ist tot. Es lebe der Product Developer.

10 Min. Lesezeit

Spezialisierung war ein Workaround, keine Strategie

So funktionierte die alte Welt. Eine “Fachabteilung” hatte eine Idee. Jemand schrieb ein Dokument. Vielleicht entstanden Entwürfe in Figma. Das Dokument wanderte zum “technischen Team” mit der Ansage: baut das. Dann wartete man. Wochen später kam etwas zurück. Falsch, meistens. Also schrieb man ein längeres Dokument mit mehr Details. Das technische Team baute auch das. Ebenfalls falsch. Wiederholen, bis das Budget aufgebraucht ist oder alle aufgeben.

Dieser Ablauf hat ganze Berufsgruppen hervorgebracht. Product Manager, die “den Backlog verantworten.” Business-Analysten, die “Anforderungen erheben.” Fachexperten, die “die Domäne kennen.” UX-Designer, die “den Nutzer verstehen.” Alle fütterten Entwickler mit Anweisungen, als wären diese zu begriffsstutzig, um irgendetwas jenseits von Syntax zu verstehen.

Dieses Fließband war sinnvoll, als die Umsetzung von Absicht in funktionierende Software Monate Tipparbeit erforderte. Übersetzung war teuer. Man brauchte Spezialisten an jeder Übergabestelle, weil jede Übergabe Informationen verlor und jemand den Verlust auffangen musste.

KI hat die Übersetzungskosten beseitigt. Und damit die Begründung für die meisten dieser Übergaben.

Die Entwurfs-Übergabe ist vorbei

Das klassische Bild: Ein Product Manager verbringt drei Wochen mit Stakeholder-Gesprächen, destilliert Anforderungen, baut einen Jira-Backlog auf, erstellt Figma-Entwürfe, schreibt Akzeptanzkriterien. Dann wird ein “Refinement” angesetzt. Die Entwürfe werden dem Team präsentiert. Das Team stellt Fragen. Der PM geht zurück zu den Stakeholdern. Kommt nächsten Sprint wieder. Der Kreislauf wiederholt sich.

Der gesamte Wertbeitrag dieser Person lag darin, Übersetzer zwischen “Fachseite” und “Technik” zu sein. Diese Rolle existierte, weil Entwickler sich die Zeit nicht leisten konnten, die Fachlichkeit selbst zu verstehen. Jede Stunde, die ein Entwickler mit Nutzern sprach, war eine Stunde weniger Programmierarbeit. Und Programmieren war der Engpass.

Programmieren ist nicht mehr der Engpass.

Wenn ein Entwickler einem KI-Werkzeug ein System beschreiben kann und innerhalb von Stunden statt Wochen funktionierenden Code erhält, dreht sich die Wirtschaftlichkeit um. Der Engpass ist jetzt das Problemverständnis. Und der Product Manager war nie die Person, die das Problem am tiefsten verstanden hat. Die Nutzer haben es verstanden. Die Entwickler, sobald sie mit den Nutzern sprachen, haben es schnell genug verstanden.

Die Übersetzungsschicht wird zum Ballast.

Fachexperten ohne Verantwortung für das Ergebnis

Fachexperten hatten eine ähnliche Vereinbarung. Sie kannten die Geschäftsregeln, die regulatorischen Rahmenbedingungen, die Sonderfälle. Sie saßen in Meetings und erklärten Dinge. Entwickler machten sich Notizen. Das meiste an Nuancen ging verloren, weil es durch zwei oder drei Personen weitergereicht wurde, bevor es im Code ankam.

Der Fachexperte, der nie Code ausliefert, hat ein fundamentales Problem: keine Rückkopplungsschleife. Er beschreibt, was passieren soll, jemand anderes baut es, und bis die Lücke zwischen Absicht und Umsetzung sichtbar wird, sind sechs Wochen vergangen und niemand erinnert sich an das ursprüngliche Gespräch.

Ein Entwickler, der die Fachlichkeit versteht, hat dieses Problem nicht. Er hört die Geschäftsregel, codiert sie, testet sie, liefert sie aus. Am selben Tag. Die Rückkopplungsschleife dauert Stunden, nicht Monate.

“Aber Entwickler können doch keine komplexen Geschäftsdomänen verstehen!” Das höre ich von Leuten, die es noch nie ausprobiert haben. Ein fähiger Software-Entwickler, der zwei Wochen in eine Fachdomäne eintaucht, versteht sie gut genug, um die Software zu bauen. Nicht gut genug, um das Geschäft zu führen. Aber gut genug, um die Software zu bauen. Das ist die Messlatte. Und KI beschleunigt das Eintauchen, weil der Entwickler in Echtzeit Fragen stellen, Szenarien modellieren und Lösungen prototypisieren kann, statt Termine zu koordinieren.

Vertikale Integration gewinnt

Das alte Modell war horizontale Spezialisierung. Eine Person kennt die Nutzer. Eine andere Person kennt die Fachlichkeit. Eine weitere gestaltet die Oberfläche. Noch eine schreibt das Backend. Und eine weitere kümmert sich um die Infrastruktur. Fünf Personen, fünf Übergaben, fünf Gelegenheiten für Informationsverlust.

Das neue Modell ist vertikale Integration. Eine Person (oder ein eingespieltes Paar), die das Nutzerproblem versteht, die Lösung entwirft, das System baut, testet, ausliefert und in Produktion überwacht. Nicht weil sie übermenschlich ist. Sondern weil KI die Teile übernimmt, die früher aus mechanischen Gründen eigene Spezialisten erforderten. Weil Software-Entwicklung Gestaltung ist, nicht Fließbandarbeit.

SpaceX hat das bei Raketen verstanden. Wer vertikal integriert, eliminiert Übergabeverzögerungen und Informationsverlust. Die Person, die die Entwurfsentscheidung trifft, ist dieselbe Person, die die Konsequenzen sieht.

Das ist der T-förmige Software Product Developer. Tiefe Expertise in Systementwurf und Entwicklungsdisziplin. Breites Wissen, um mit Nutzern zu sprechen, regulatorische Rahmenbedingungen zu verstehen, Oberflächen zu gestalten, Infrastruktur zu betreuen. KI füllt die Lücken. Man muss sich nicht Kubernetes-Konfigurationen merken. Man muss verstehen, warum die Auslieferungsstrategie wichtig ist, und KI die Konfiguration schreiben lassen.

Was verschwindet

Konkret.

Der Product Manager, der Arbeitsaufträge schreibt. Wenn Ihr Beitrag darin besteht, Stakeholder-Wünsche in Jira-Aufgaben zu übersetzen, erledigt KI das schneller und mit weniger Informationsverlust. Der Entwickler spricht direkt mit dem Stakeholder, skizziert die Lösung mit KI-Unterstützung und liefert aus. Die Mittlerrolle ist überflüssig.

Der Business-Analyst, der Anforderungen dokumentiert. Anforderungsdokumente waren immer ein schlechter Ersatz für Gespräche. Jetzt findet das Gespräch in Echtzeit statt, zwischen der Person mit dem Problem und der Person, die die Lösung ausliefert. Das Dokument muss nie existieren.

Der UX-Designer, der Entwürfe übergibt. Ein Entwickler mit KI kann in Minuten eine Oberfläche prototypisieren, sie Nutzern zeigen, in Echtzeit iterieren. Die “Design-Übergabe” war eine Zeremonie für eine Welt, in der ein Prototyp teuer war. Das ist er nicht mehr.

Der Fachexperte, der nur berät. Fachliches Wissen ohne Umsetzungsverantwortung ist Beratung. Der Product Developer eignet sich genug Fachwissen an, um das Richtige zu bauen, und validiert mit den tatsächlichen Fachnutzern.

Der Scrum Master, der moderiert. Wenn ein Team aus zwei oder drei Product Developern täglich ausliefert, gibt es nichts zu moderieren. Kein Sprint Planning, weil es keine Sprints gibt. Keine Retrospektiven, weil Rückmeldungen kontinuierlich fließen. Keine Standups, weil das Team klein genug ist, um einfach miteinander zu reden. Wie der Lebenszyklus von Management-Rahmenwerken zeigt, waren diese Rollen Produkte der Rahmenwerk-Industrie. Kleine Teams, die ohne Zeremonien ausliefern, waren großen, prozessbeladenen Abteilungen schon immer überlegen.

Was überlebt

Nicht der Product Manager. Die Tätigkeiten.

Mit Nutzern sprechen, Marktdynamiken verstehen, beurteilen ob Software echte Probleme löst. Das verschwindet nicht. Es wird zu dem, was jeder Entwickler im Team tut. Es gibt niemanden mehr, der das Produkt “verwaltet”, weil es nichts zu verwalten gibt. Es gibt Entscheidungen zu treffen, und die Menschen, die sie treffen, sind dieselben, die den Code schreiben.

Eric Ries hat das vor fünfzehn Jahren mit Lean Startup richtig erkannt. Bauen-Messen-Lernen. Etwas Kleines ausliefern. Beobachten, was Nutzer tatsächlich tun. Anpassen. Nochmal ausliefern. Das Problem war nie die Idee. Das Problem war, dass “Bauen” sechs Monate dauerte und einen 40-Personen-Staffellauf vom PM über den BA zum Designer zum Entwickler zur QA zum Betrieb erforderte. Also kam “Messen” zu spät und “Lernen” verschwand unter dem Backlog des nächsten Sprints.

KI hat “Bauen” auf Stunden reduziert. Jetzt läuft Bauen-Messen-Lernen täglich. Ein Product Developer liefert morgens ein Feature aus, beobachtet nachmittags die Nutzungsdaten und entscheidet abends, ob er iteriert, erweitert oder verwirft. Kein Roadmap-Gremium. Kein vierteljährliches Priorisierungstheater. Nur eine enge Schleife zwischen Code und Realität.

Der fachliche Experte, der sich neben einen Entwickler setzen und in Echtzeit Fragen beantworten kann, während dieser baut? Unverzichtbar. Aber eingebettet, nicht in einer eigenen Abteilung. Keine Dokumente schreiben. Stattdessen Arbeitsabläufe vorführen, Sonderfälle erklären, Verhalten validieren. Der Entwickler setzt das Gelernte sofort um.

Was ist mit Designern? Theoretisch ist jemand wertvoll, der am selben Tag prototypisieren, mit Nutzern testen und iterieren kann. In der Praxis schaffen die meisten Designer diesen Sprung nicht. Sie weigern sich, CSS zu lernen. Sie klammern sich an Figma und übergeben pixelgenaue Entwürfe von Dingen, die im Browser nicht funktionieren. Sie behandeln das Web wie eine Leinwand statt als Medium mit eigenen Regeln. Diese Sturheit ist eine karrierebeendende Entscheidung. Ein Product Developer mit brauchbarem Gespür für Ästhetik, einem Gefühl für Nutzerfreundlichkeit und KI, die in Sekunden Layout-Varianten erzeugt, liefert bessere Ergebnisse als ein Designer, der Bilder zeichnet und über die Wand wirft. Gutes UX-Gespür ist keine seltene Begabung. Es ist eine Fähigkeit, die neugierige Entwickler schnell erlernen, besonders wenn KI das visuelle Experimentieren übernimmt.

Der gemeinsame Nenner: Wer überlebt, arbeitet innerhalb des Produktentwicklungszyklus, nicht daneben. Und “Produktmanagement” löst sich von einer Rolle in eine gemeinsame Disziplin auf. Jeder Entwickler im Team spricht mit Nutzern. Jeder Entwickler liest Produktionsmetriken. Jeder Entwickler trifft Produktentscheidungen. Das ist kein Chaos. Das ist Bauen-Messen-Lernen ohne den Mittelsmann.

Der T-förmige Product Developer

Dieses Profil ersetzt fünf getrennte Rollen.

Tiefe Fähigkeiten: Systemarchitektur. Teststrategie. Auslieferung und Beobachtbarkeit. Grundlagen der Sicherheit. Die Fähigkeit, Code zu lesen, über Fehlermodi nachzudenken und zu überprüfen, ob die KI-Ergebnisse tatsächlich funktionieren. Nicht verhandelbar. Das Ende des Programmierens bedeutete nicht das Ende der Entwicklung. Es bedeutete das Ende der Tipparbeit. Und nennen wir es beim richtigen Namen: Entwicklung, nicht Ingenieurwesen. Ingenieure wenden etablierte Regeln an. Ein Bauingenieur folgt Baunormen. Ein Software-Entwickler erschafft etwas, das vorher nicht existiert hat, trifft Entscheidungen unter Unsicherheit und übernimmt Verantwortung für Ergebnisse, die niemand aus einer Spezifikation vorhersagen kann. Das ist Entwicklung. Das Wort ist wichtig.

Breite Fähigkeiten: Fachliches Verständnis. Nutzerempathie. Grundlegendes Gespür für Gestaltung. Kommunikation mit Stakeholdern. Regulatorisches Bewusstsein wo relevant. Verständnis des Geschäftsmodells. Man braucht keinen MBA. Man braucht genug Geschäftsverständnis, um zu wissen, ob das, was man baut, relevant ist.

KI-erweiterte Fähigkeiten: Infrastrukturkonfiguration. Oberflächen-Prototyping. Datenanalyse. Dokumentation. Erzeugung von Standardcode. Testgerüste. Alles, was früher einen Spezialisten erforderte, weil es mechanisch komplex war, nicht konzeptionell komplex.

Menschen entscheiden, was gebaut wird, wie es strukturiert wird, ob es funktioniert. KI produziert den Code, die Tests, die Dokumentation, die Konfiguration. Urteilsvermögen bleibt beim Menschen. Volumen geht an die Maschine.

Warum Organisationen sich dagegen wehren

Weil es Mitarbeiterzahlen, Budgets und Einflussbereiche bedroht.

Ein Leiter Produktmanagement mit 15 Product Managern wird nicht freiwillig vorschlagen, dass 12 dieser Rollen in Entwicklungsteams aufgehen könnten. Ein Leiter Business-Analyse mit 8 Analysten wird nicht die Auflösung der Abteilung empfehlen. Eine Leitung UX-Design mit 20 Gestaltern wird nicht zugeben, dass 15 davon Arbeit erledigen, die KI zusammen mit einem Product Developer besser bewältigt.

Organisationen optimieren auf Effizienz durch Spezialisierung. Das ist das Fabrikmodell. Es funktioniert, wenn der Engpass der Produktionsdurchsatz ist. Es versagt, wenn der Engpass Verständnis und Entscheidungsfähigkeit ist.

Produktentwicklung im Zeitalter der KI erfordert kleine Teams, die schnell handeln und gut entscheiden. Jede Person im Raum sollte in der Lage sein auszuliefern. Wenn jemandes Aufgabe nur darin besteht zu beschreiben, was gebaut werden soll, ohne die Fähigkeit, es selbst zu bauen, dann ist diese Person ein Engpass, kein Treiber.

Die unbequeme Wahrheit

Das ist keine Prognose. Das passiert bereits in jedem Unternehmen, in dem Entwickler GitHub Copilot, Claude Code oder vergleichbare Werkzeuge ernsthaft einsetzen.

Ein Entwickler, der KI gut nutzt, kann Arbeit aufnehmen, die vorher drei oder vier unterstützende Rollen erforderte. Nicht weil diese Rollen im alten Modell überflüssig waren. Sie waren notwendig. Übersetzung war tatsächlich schwierig. Übergaben waren tatsächlich teuer. Spezialisierung war tatsächlich effizient, als Tipparbeit der Engpass war. Und nein, KI ersetzt nicht den Entwickler. Das versuchen wir seit 1969 in jedem Jahrzehnt. Es scheitert jedes Mal.

Aber der Engpass hat sich verschoben. KI wurde zum Denkpartner, nicht nur zum Tipp-Assistenten. Der Entwickler, der sie gut nutzt, programmiert nicht einfach schneller. Er versteht schneller. Er prototypisiert schneller. Er validiert schneller. Er liefert schneller aus.

Die Frage ist nicht, ob dieser Wandel stattfindet. Die Frage ist, ob Ihre Organisation sich anpasst oder von einem Drei-Personen-Team überholt wird, das in einer Woche mehr Wert schafft als Ihre 40-köpfige Abteilung in einem Quartal.

Der Weg dahin

Hören Sie auf, für Übergaberollen einzustellen. Stellen Sie für Integrationsrollen ein.

Fragen Sie nicht mehr “Wer schreibt die Anforderungen?” Fragen Sie “Wer versteht das Problem gut genug, um die Lösung auszuliefern?”

Trennen Sie nicht mehr “Fachseite” und “Technik.” Der Product Developer ist beides.

Investieren Sie in Entwickler, die neugierig auf Fachdomänen sind, nicht nur auf Technologie. Investieren Sie in fachliche Experten, die bereit sind, mit Entwicklern zusammenzuarbeiten, statt Dokumente zu schreiben. Investieren Sie in Gestalter, die mit Code prototypisieren, nicht nur mit Figma.

Beenden Sie die Fließbandarbeit. Bauen Sie integrierte Teams. Liefern Sie täglich aus. Messen Sie Ergebnisse. Alles andere ist Ballast.

Der Product Manager ist tot. Es lebe der Product Developer.