Warum Product Owner mehr bauen sollten

Noch vor wenigen Jahren war der Einstieg in die Softwareentwicklung eine hohe Hürde. Heute sieht das anders aus.

KI-gestützte Entwicklungswerkzeuge haben den Abstand zwischen einer Idee und einem funktionierenden Prototyp drastisch verkürzt. Was früher Wochen dauern konnte, lässt sich heute oft an einem Nachmittag umsetzen. Kleine Webanwendungen, Automatisierungen, interne Tools oder erste Prototypen entstehen mittlerweile in erstaunlich kurzer Zeit.

Dabei geht es weniger um einzelne Werkzeuge als um die grundsätzliche Entwicklung. Ob Cursor, Claude Code, GitHub Copilot oder andere Lösungen – sie alle machen eines möglich: Ideen selbst auszuprobieren, ohne sofort ein komplettes Entwicklungsteam zu benötigen.

Für mich ist genau das der entscheidende Unterschied. Ich kann eine Idee innerhalb weniger Stunden testen, sie echten Nutzern zeigen und herausfinden, ob sie überhaupt einen Mehrwert bietet. Viele Ideen scheitern bereits an diesem Punkt – und genau dort sollten sie auch scheitern. Je früher eine schlechte Idee erkannt wird, desto günstiger ist sie.

Natürlich ist ein Prototyp noch lange kein fertiges Produkt. Zwischen einer Anwendung auf dem eigenen Laptop und einer Software, auf die sich tausende Nutzer verlassen, liegen Themen wie Skalierung, Sicherheit, Monitoring, Deployment oder Datenschutz. Genau diese Unterschiede machen professionelle Softwareentwicklung so anspruchsvoll. Für den eigentlichen Lerneffekt spielt das allerdings keine Rolle.

Ich würde mich auch heute nicht als Entwickler bezeichnen. Wahrscheinlich könnte ich eine komplexe Anwendung nicht alleine von der ersten Codezeile bis in die Produktion bringen.

Trotzdem habe ich durch meine eigenen kleinen Projekte mehr über Software gelernt als durch jedes Buch oder jeden Onlinekurs.

Erst wenn man selbst APIs verbindet, Datenbanken aufsetzt, Authentifizierung integriert oder ein Deployment zum ersten Mal scheitern sieht, versteht man, wie viele kleine Entscheidungen hinter einer scheinbar einfachen Anwendung stecken.

Man lernt Technologie nicht ausschließlich durch Dokumentation. Man lernt sie vor allem dadurch, dass Dinge kaputtgehen.

Eine fehlerhafte Konfiguration, ein API-Token, der nicht funktioniert, eine Anwendung, die lokal perfekt läuft und in der Cloud plötzlich nicht mehr startet – genau diese Momente sorgen dafür, dass technisches Verständnis entsteht.

Der größte Mehrwert liegt für mich allerdings nicht im Programmieren selbst.

Er liegt in den Gesprächen mit Entwicklern.

Wer selbst schon einmal Software gebaut hat, versteht deutlich besser, warum manche Änderungen überraschend aufwendig sind und andere trotz ihres großen Umfangs vergleichsweise wenig Aufwand verursachen. Man entwickelt ein Gefühl dafür, welche Risiken hinter einer Anforderung stecken, welche technischen Abhängigkeiten berücksichtigt werden müssen und warum manche Entscheidungen deutlich komplexer sind, als sie auf den ersten Blick wirken.

Dadurch verändern sich auch Priorisierungen und Diskussionen.

Ich kann realistischere Erwartungen an Stakeholder kommunizieren, bessere Rückfragen stellen und technische Risiken früher erkennen. Gleichzeitig wächst der Respekt für die Arbeit eines Entwicklungsteams. Vieles von dem, was gute Entwickler leisten, ist von außen kaum sichtbar. Erst wenn man selbst versucht hat, Software zu bauen, erkennt man, wie viel Planung, Erfahrung und sorgfältiges Engineering hinter einer scheinbar kleinen Funktion steckt.

Dabei geht es ausdrücklich nicht darum, Entwickler zu ersetzen.

Im Gegenteil.

Je besser ich ihre Arbeit verstehe, desto besser kann ich sie unterstützen. Ein Product Owner mit technischem Verständnis wird nicht zum besseren Entwickler. Er wird zum besseren Partner für Entwickler.

Technisch zu sein bedeutet heute aus meiner Sicht nicht, jeden Algorithmus erklären oder komplexe Datenstrukturen auswendig beherrschen zu können.

Es bedeutet, technische Entscheidungen einordnen zu können.

Welche Auswirkungen hat eine bestimmte Architektur? Warum dauert Lösung A deutlich länger als Lösung B? Welche Risiken entstehen durch eine scheinbar kleine Änderung? Welche Rückfragen sollte ich stellen, bevor eine Entscheidung getroffen wird?

Diese Form der Urteilskraft wird für Product Owner immer wichtiger.

Noch vor wenigen Jahren war technisches Verständnis nur schwer aufzubauen, wenn man nicht selbst entwickelt hat. Heute ist der Einstieg so einfach wie nie zuvor. Jeder kann kleine Anwendungen bauen, Automatisierungen entwickeln oder Prototypen erstellen und dabei Schritt für Schritt ein besseres Verständnis für Software gewinnen.

Business-Verständnis bleibt eine Kernkompetenz im Produktmanagement. Den Markt zu verstehen, Nutzerprobleme zu erkennen und Prioritäten richtig zu setzen wird auch in Zukunft entscheidend sein.

Ich glaube jedoch, dass ein weiterer Faktor immer wichtiger wird: Technologie nicht nur aus Präsentationen oder Architekturdiagrammen zu kennen, sondern sie selbst erlebt zu haben.

Wer regelmäßig selbst baut, trifft aus meiner Erfahrung bessere Produktentscheidungen. Nicht weil er der bessere Entwickler ist, sondern weil er technische Zusammenhänge realistischer einschätzen kann.

Genau deshalb glaube ich, dass Product Owner heute mehr denn je selbst Software bauen sollten – nicht, um Entwickler zu werden, sondern um bessere Product Owner zu sein.