Vom Developer zum Product Owner: die notwendige Verwandlung im KI-Zeitalter

Foto von Tara Winstead: https://www.pexels.com/it-it/foto/arte-testa-pensando-consapevolezza-8378726/

Vor ein paar Tagen hat ein Kollege aus meinem Team, der Claude Code nutzt, ein Feature implementiert, das mir damals, als ich seine Arbeit machte, mehr als einen halben Tag gekostet hätte. Er hat es in vierzig Minuten erledigt, in Qualität und Sicherheit. Und während ich darüber nachdachte, dachte ich nicht an die Stärke des Werkzeugs. Ich dachte daran, wie sehr mein beruflicher Weg, dieser Übergang von Developer zu Product-Ownership- und Leadership-Rollen in den letzten Jahren, sich vorausschauender erweist, als ich gedacht hatte.

Ich habe es nicht aus Weitsicht gemacht, das sei klar. Ich habe es gemacht, weil mir das ganztägige Codeschreiben irgendwann nicht mehr gab, was ich suchte. Ich wollte das Warum der Dinge verstehen, nicht nur das Wie. Ich wollte im Raum sein, wenn entschieden wurde, was zu bauen ist, nicht nur Tickets zur Umsetzung erhalten. Eine intuitive, teils egoistische Wahl. Aber im Rückblick hat sie mich an einen interessanten Punkt gestellt, von dem aus man beobachten kann, was gerade passiert.

Der Wert wandert vom Wie zum Was

Der Wendepunkt, an dem wir stehen, geht nicht um KI, die „Programmierern den Job stiehlt“, wie reißerische Schlagzeilen sagen. Es geht um etwas Subtileres: der Wert verschiebt sich. Er wandert vom Wie zum Was und Warum. Und ich sehe es täglich, in Gesprächen mit anderen Fachleuten und Managern, die ich kenne, in den Hiring-Entscheidungen, die schon anders sind, in der Art, wie Teams nun strukturiert werden müssen.

Unternehmen fragen nicht mehr „wie viele Developer kann ich einstellen“. Sie fragen „wie maximieren wir die Produktivität mit kleineren Teams und besseren Werkzeugen“. Ein radikaler Perspektivwechsel. In meiner Rolle denke ich immer öfter darüber nach, wie sich KI-Agenten in bestehende Workflows integrieren lassen, statt darüber, wie man das Team skaliert. Das hat enorme Implikationen für jene, die heute Code als Hauptaktivität schreiben.

Die autonomen KI-Agenten, die wir täglich nutzen, sind keine glorifizierten Autovervollständigungen. Sie tun Dinge, die vor zwei Jahren nach Science-Fiction klangen: sie nehmen ein schlecht definiertes Problem, zerlegen es, suchen Kontext im Codebase, implementieren, testen, iterieren. Wir beaufsichtigen sie, klar. Wir korrigieren sie, oft. Aber die Menge an Arbeit, die sie mit der richtigen Anleitung leisten, ist beeindruckend. Und das verändert alles.

Was ich heute in Teams suche

Bei Auswahl von Kandidaten oder Bewertung der Teamleistung müssen wir die Fragen radikal ändern. Mich interessiert nicht mehr, wie schnell jemand Code schreibt. Mich interessiert, wie gut jemand das Problem versteht, das wir lösen. Ob er die richtigen Fragen vor Beginn stellt, ob er Edge Cases antizipiert, ob er seine Entscheidungen in Begriffen erklären kann, die für das Geschäft Sinn ergeben. Das sind die Dinge, die KI noch nicht gut kann.

Ich kenne Profis, die Copilot oder Claude Code ablehnen, weil sie „lieber alles selbst schreiben“. Ich verstehe sie, wirklich. Ich komme von dort, ich kenne dieses Gefühl totaler Kontrolle, diese Erfüllung, den Code aus den Fingern wachsen zu sehen. Aber von dort, wo ich jetzt bin, sehe ich auch das Risiko. Es ist ein bisschen wie bei den Setzern, die Desktop Publishing ablehnten, weil sie das Blei liebten. Romantisch, sicher. Wirtschaftlich tragfähig, weniger.

Der Übergang vom Developer zum Product Owner — oder zu Rollen, in denen man das Was definiert, statt das Wie umzusetzen — heißt nicht, mit Technik aufzuhören. Im Gegenteil: in meiner Erfahrung verlangt er mehr technische Kompetenz, nicht weniger. Aber eine andere: man muss wissen, was möglich, teuer, riskant ist, ohne es selbst zu implementieren. Man muss KI und Agenten leiten wie ein Dirigent das Orchester: man spielt nicht jedes Instrument, aber man muss wissen, wie jedes Instrument klingen sollte.

Die Developer, die diesen Übergang am besten meistern, haben Eigenschaften, die ich an mir wiedererkenne. Nicht unbedingt die technisch brillantesten. Es sind die, die immer viele Fragen stellten, die das Warum hinter jedem Feature verstehen wollten, die sich an vagen Spezifikationen rieben. Die, die immer schon ans Produkt dachten, auch als ihr offizieller Job nur Coden war. Wenn Sie sich darin wiedererkennen, haben Sie wahrscheinlich die Hälfte der Arbeit schon getan.

Dann ist da die Frage der Beziehungs-Skills, und ich gebe zu, dieser Übergang war auch für mich hart. Jahrelang habe ich Meetings mit Business-Stakeholdern gemieden, sah sie als Unterbrechungen der „echten Arbeit“. Heute sind sie meine Arbeit. Technische Sprache in Begriffe übersetzen, die ein CFO versteht, Prioritäten mit einem Marketing-/Vertriebsteam verhandeln, das alles für gestern will, einer Geschäftsführerin erklären, warum dieses „einfache“ Feature drei Monate braucht: das sind Skills, die keine KI noch beherrscht und vielleicht nie beherrschen wird. Und genau sie machen mich heute wertvoll.

Spezifizieren ist das neue Handwerk

Etwas, das ich im Feld gelernt habe: die Qualität der Anforderungen, die du der KI gibst, bestimmt die Qualität des Outputs. Klingt offensichtlich, aber die Implikationen sind tief. Wenn ich präzise, kontextualisierte Spezifikationen mit den richtigen Beschränkungen und Freiheiten schreibe, bekomme ich Code, der funktioniert. Wenn ich vage, unvollständig, widersprüchlich bin, bekomme ich Müll. Das heißt: die kritische Kompetenz ist nicht mehr „coden können“, sondern „spezifizieren können“. Und gut spezifizieren verlangt tiefes Verständnis sowohl der technischen Domäne als auch des Geschäfts.

Ich habe schon kleine Teams, höchstens fünf Personen, gesehen, die Output liefern wie Teams von zwölf — einfach, weil jemand da war, der Aufgaben richtig definieren konnte. Ich rede nicht von formaler Doku, UML-Diagrammen oder hundertseitigen Spezifikationen. Ich rede von dieser Fähigkeit zu artikulieren, was wirklich gebraucht wird, vor Beginn die richtigen Fragen zu stellen, Probleme vorwegzunehmen. Eine erlernbare Skill, die aber einen Mindset-Wechsel verlangt.

Der Sprung verlangt Demut und Mut

Trotzdem will ich kein zu rosiges Bild zeichnen. Mein Übergang war nicht linear, und ich sehe Kollegen, die enorm kämpfen. Es verlangt Demut: zu akzeptieren, dass etwas, was du gut konntest, an relativem Wert verliert, und dass du in andere Kompetenzen investieren musst. Es verlangt Mut: aus der Komfortzone des Codes zu treten, wo Dinge deterministisch und kontrollierbar sind, in die mehrdeutige Welt der Produktentscheidungen, mit immer unvollständigen Informationen und Stakeholdern mit gegensätzlichen Agenden.

Es gibt auch eine ethische Dimension, die mich beunruhigt und fasziniert. KI zur Beschleunigung der Entwicklung zu nutzen, ist nicht neutral. Modelle haben Bias, es gibt Folgen für Codequalität, Sicherheit, Wartbarkeit. Man muss auch ein wenig paranoid sein, wissen, wann die KI etwas Falsches tut, auch wenn es technisch funktioniert. Eine neue Verantwortung, die Bewusstsein und Intentionalität verlangt. Man kann nicht alles delegieren und hoffen, dass es klappt.

Die Wette, die jetzt zu machen ist

Was ich aus meiner Position sehe: technische Leadership-Rollen, Product Management, Tech Strategy werden immer stärker nachgefragt und immer schwerer zu besetzen. Wer aus dem Code kommt, hat einen riesigen Wettbewerbsvorteil gegenüber jemandem, der aus dem reinen Business kommt: er versteht, was möglich, teuer, riskant ist. Aber er muss den Sprung wagen. Er muss aufhören, sich mit den Codezeilen zu identifizieren, die er schreibt, und beginnen, sich mit den Problemen zu identifizieren, die er löst.

Der falsche Mythos, den ich von Developern am häufigsten höre: „ich habe keine Zeit, all das zu lernen“. Aber die Zeit, die du sparst, indem du KI Code schreiben lässt — wohin geht sie? Wenn du sie reinvestierst, um deine Coding-Skills weiter zu verfeinern, optimierst du etwas, das zur Commodity wird. Wenn du sie reinvestierst, um wie ein Product Owner denken zu lernen, baust du deine zukünftige Relevanz.

Die Frage, die ich mir vor Jahren stellte, als ich diesen Übergang begann, war „was will ich in fünf Jahren tun?“. Die Antwort war nicht „noch schneller Code schreiben“. Sie war „mehr Wirkung haben, Geschäft besser verstehen, im Raum sein, in dem entschieden wird“. Diese Frage ist heute noch dringender für jene am Anfang des Wegs.

Die Zukunft gehört jenen, die wissen, was zu bauen ist — nicht nur jenen, die wissen, wie man baut. Ich habe diese Wette vor einigen Jahren gemacht, ohne zu wissen, wie relevant sie werden würde. Wer mich heute liest, hat den Vorteil, sie bewusster machen zu können. Aber er muss sie machen.