Was ein guter Product Owner technisch verstehen sollte und was nicht
Von Lars Decker
Was ein guter Product Owner technisch verstehen sollte und was nicht
Product Owner müssen nicht coden. Aber sie müssen technische Zusammenhänge so gut verstehen, dass sie bessere Entscheidungen treffen können.
Gerade in Teams mit komplexeren Produkten taucht diese Frage immer wieder auf:
Wie technisch muss ein Product Owner eigentlich sein?
Die kurze Antwort ist: Ein guter Product Owner muss nicht programmieren können. Aber er sollte genug technisches Verständnis mitbringen, um mit Entwicklern sinnvoll sprechen, Risiken einordnen und Auswirkungen von Entscheidungen abschätzen zu können.
Ich halte dabei wenig von zwei Extremen.
Das eine Extrem ist der PO, der sich aus allem Technischen komplett heraushält und bei Architektur, Performance oder Integrationen nur mit den Schultern zuckt. Das andere Extrem ist der PO, der jedes Datenbankdetail, jedes Framework-Pattern und jede Implementierungsentscheidung mitsteuern will.
Beides ist ungesund.
Ein Product Owner muss nicht der bessere Entwickler sein. Aber er muss verstehen, wo Technik Produktarbeit direkt beeinflusst.
Das eigentliche Ziel: bessere Entscheidungen, nicht mehr Fachbegriffe
Technisches Verständnis ist für einen Product Owner kein Selbstzweck. Es geht nicht darum, in Refinements besonders kompetent zu klingen oder in Meetings mit Begriffen wie Eventual Consistency, Edge Caching oder CQRS um sich zu werfen.
Es geht darum, bessere Fragen zu stellen.
Zum Beispiel:
- Ist ein Wunsch wirklich klein oder nur oberflächlich klein?
- Welche Nebenwirkungen hat ein Feature auf bestehende Abläufe?
- Wo lauern technische Risiken, die für Stakeholder unsichtbar sind?
- Ist ein Problem fachlich oder technisch kompliziert?
- Welche Kompromisse sind bewusst vertretbar und welche rächen sich später?
Genau dafür braucht ein PO technische Orientierung. Nicht auf Senior-Engineer-Niveau, aber klar über PowerPoint-Niveau.
Diese technischen Dinge sollte ein guter Product Owner verstehen
1. Wie das Produkt grob aufgebaut ist
Ein Product Owner muss nicht jedes Systemdiagramm auswendig kennen. Aber er sollte das Grundmodell des Produkts verstehen.
Also zum Beispiel:
- Welche zentralen Systeme gibt es?
- Wo liegen die wichtigsten Schnittstellen?
- Welche externen Abhängigkeiten existieren?
- Welche Bereiche sind besonders kritisch für Stabilität, Sicherheit oder Umsatz?
Wer das nicht versteht, kann Aufwand und Risiko kaum sinnvoll einordnen.
Ein Beispiel: Wenn eine kleine Änderung im Checkout nicht nur das Frontend betrifft, sondern auch Payment, E-Mail-Versand, ERP-Anbindung und Reporting, dann ist das keine kleine Änderung mehr. Zumindest nicht in der Realität.
Ein guter PO erkennt solche Zusammenhänge früh genug, um Planung, Erwartungsmanagement und Priorisierung darauf anzupassen.
2. Die Sprache von Aufwand, Risiko und Unsicherheit
Viele Missverständnisse zwischen Fachseite und Entwicklung entstehen nicht, weil jemand unfähig ist, sondern weil Begriffe unterschiedlich verstanden werden.
Wenn ein Entwickler sagt: "Das ist technisch riskant." dann meint er oft nicht: "Ich habe keine Lust darauf."
Er meint eher:
- Wir kennen noch nicht alle Seiteneffekte.
- Die Änderung greift tief in bestehende Strukturen ein.
- Es gibt Annahmen, die erst validiert werden müssen.
- Fehler würden an einer kritischen Stelle teuer werden.
Ein guter Product Owner sollte solche Aussagen einordnen können. Nicht blind übernehmen, aber ernst nehmen.
Technisches Verständnis hilft hier, Unsicherheit nicht mit Widerstand zu verwechseln.
3. Qualität ist nicht nur "läuft auf meinem Rechner"
Viele Produktentscheidungen kippen genau an diesem Punkt. Ein Feature funktioniert im Demo-Szenario und wirkt damit "fertig". Im echten Betrieb zeigt sich dann:
- es ist langsam,
- es ist fehleranfällig,
- es ist schwer wartbar,
- es skaliert nicht,
- oder es erzeugt operativen Support-Aufwand.
Ein guter PO sollte deshalb verstehen, dass Qualität mehrere Dimensionen hat:
- Funktionalität
- Performance
- Stabilität
- Wartbarkeit
- Sicherheit
- Beobachtbarkeit
Man muss diese Dinge nicht selbst technisch umsetzen können. Aber man sollte verstehen, dass sie Produktwert direkt beeinflussen.
Denn am Ende merkt der Nutzer nicht, ob das Team "sauber gearbeitet" hat. Er merkt nur, ob das Produkt zuverlässig funktioniert.
4. Technische Schulden und ihre Geschäftsauswirkungen
Das ist aus meiner Sicht einer der wichtigsten Punkte überhaupt.
Technische Schulden sind für viele Stakeholder unsichtbar, bis sie plötzlich sehr sichtbar werden. Dann dauern Features länger, Bugs häufen sich, Releases werden nervös und jedes neue Vorhaben fühlt sich schwerer an als das vorherige.
Ein guter Product Owner muss nicht jede Code-Altlast im Detail kennen. Aber er sollte verstehen:
- Wo technische Schulden die Lieferfähigkeit bremsen
- Wo Risiken steigen
- Wo Geschwindigkeit nur scheinbar hoch ist
- Wo man bewusst investieren muss, obwohl der Nutzen nicht sofort auf einer Folie glänzt
Genau hier beginnt produktive Zusammenarbeit zwischen PO und Entwicklung. Nicht bei der Frage, ob eine Klasse schön geschrieben ist, sondern bei der Frage, welche technischen Zustände mittelfristig Geschäftswirkung entfalten.
5. APIs, Integrationen und Abhängigkeiten
Sobald ein Produkt nicht isoliert lebt, werden Abhängigkeiten zum Alltag. Und genau dann wird technisches Grundverständnis für Product Owner sehr wertvoll.
Man sollte nicht jedes API-Format kennen. Aber man sollte verstehen:
- dass externe Systeme Ausfälle verursachen können,
- dass Integrationen selten "mal eben" sind,
- dass Datenflüsse fachliche Auswirkungen haben,
- und dass Änderungen an Schnittstellen oft mehr nach sich ziehen als im Ticket sichtbar ist.
Wer Integrationen nur als Verbindung zwischen zwei Kästen betrachtet, unterschätzt fast immer die Komplexität.
6. Was Messbarkeit technisch bedeutet
Viele POs wollen datengetrieben arbeiten, aber behandeln Tracking und Messbarkeit trotzdem wie einen Nebengedanken.
Dabei ist die technische Seite davon entscheidend:
- Welche Events erfassen wir überhaupt?
- Wie eindeutig sind sie definiert?
- Wo fehlen Kontextdaten?
- Was ist sauber messbar und was nur gefühlt?
- Welche Entscheidungen treffen wir später auf Basis dieser Daten?
Ein guter Product Owner muss kein Analytics-Setup selbst bauen. Aber er sollte verstehen, dass gute Produktentscheidungen oft daran hängen, ob Ereignisse sauber erfasst, benannt und interpretiert werden.
Wenn Messbarkeit erst am Ende dazukommt, wird sie fast immer schlechter.
7. KI verschiebt die technische Flughöhe für Product Owner
Mit KI verschiebt sich diese Frage gerade noch einmal deutlich.
Früher konnte ein Product Owner technische Themen in manchen Kontexten stärker an das Entwicklungsteam delegieren, solange fachliche Priorisierung, Stakeholder-Management und Delivery halbwegs sauber liefen. Mit KI funktioniert das deutlich schlechter.
Der Grund ist simpel: KI ist nicht nur ein weiteres Feature-Thema. Sie verändert, wie Produkte gebaut werden, wie Anforderungen beschrieben werden, wie schnell Prototypen entstehen und wie Risiken bewertet werden müssen.
Ein Product Owner muss deshalb heute zusätzlich verstehen:
- wo KI im Produkt echten Nutzen stiftet und wo sie nur nach Innovation aussieht,
- welche Qualität ein KI-Ergebnis überhaupt haben muss, um im Alltag brauchbar zu sein,
- warum Wahrscheinlichkeiten, Fehlerraten und unklare Antworten produktrelevant sind,
- welche Datenbasis und welchen Kontext ein KI-System braucht,
- und warum Datenschutz, Nachvollziehbarkeit und menschliche Kontrolle plötzlich viel wichtiger werden.
Gerade hier reicht oberflächliches Technikverständnis nicht mehr. Denn bei KI ist die Versuchung groß, alles als magische Blackbox zu behandeln.
Dann entstehen schnell typische Fehlannahmen:
- "Das bauen wir einfach mit KI."
- "Das kann man später noch präziser machen."
- "Wenn der Prototyp funktioniert, ist das Produktproblem gelöst."
In der Realität ist es meist komplizierter. KI kann enorm beschleunigen, aber sie macht Produktentscheidungen nicht einfacher. Sie macht sie oft nur schneller sichtbar.
Für Product Owner heißt das: Man muss nicht selbst Modelle bauen oder Prompts auf Engineering-Niveau schreiben. Aber man sollte deutlich besser verstehen, wo KI zuverlässig unterstützt, wo sie Unsicherheit erhöht und welche Folgen das für Produktqualität, Support, Prozesse und Nutzervertrauen hat.
Diese Dinge muss ein Product Owner eher nicht können
Genauso wichtig ist die andere Seite. Denn viele POs setzen sich selbst unnötig unter Druck, weil sie glauben, technisch nur dann ernst genommen zu werden, wenn sie tief genug in die Umsetzung einsteigen.
Das ist meistens ein Denkfehler.
Ein guter Product Owner muss in der Regel nicht:
- produktiv programmieren können,
- Code Reviews führen,
- Architekturentscheidungen federführend treffen,
- Framework-Diskussionen technisch entscheiden,
- Datenbankschemata entwerfen,
- Deployment-Pipelines bauen,
- oder Bugs selbst debuggen.
Natürlich schadet es nicht, wenn man aus der Entwicklung kommt. Aber die Aufgabe des Product Owners ist eine andere.
Er soll nicht die Implementierung besitzen. Er soll dafür sorgen, dass die richtigen Probleme gelöst werden, dass Entscheidungen verständlich werden und dass Business, Nutzer und Technik nicht gegeneinander arbeiten.
Sobald ein PO beginnt, technische Lösungen im Detail vorzuschreiben, wird es oft unerquicklich. Dann verschwimmt Verantwortung. Und am Ende hat man das Schlechteste aus beiden Welten: Mikromanagement ohne echte technische Ownership.
Woran man mangelndes technisches Verständnis bei POs erkennt
Die Symptome sind oft erstaunlich ähnlich.
- Alles wirkt auf dem Papier gleich einfach.
- Technische Risiken werden erst spät sichtbar.
- Entwickler wirken "ständig pessimistisch", obwohl sie eigentlich nur auf Nebenwirkungen hinweisen.
- Stakeholder bekommen zu frühe Zusagen.
- Qualitätsthemen werden erst dann wichtig, wenn es bereits brennt.
- Komplexität wird mit schlechter Schätzung verwechselt.
Das Problem ist dabei selten fehlende Intelligenz. Oft fehlt einfach ein belastbares Grundmodell dafür, wie Software in der Realität entsteht und betrieben wird.
Und genau dieses Grundmodell ist für POs extrem wertvoll.
Wie tief sollte ein PO also wirklich gehen
Meine pragmatische Antwort wäre:
Tief genug, um Zusammenhänge zu verstehen. Nicht so tief, dass du die Rolle des Entwicklungsteams übernimmst.
Ein PO sollte in technischen Gesprächen nicht passiv sein. Aber auch nicht so auftreten, als müsse er jede Lösung fachlich absegnen.
Hilfreiche Fragen sind zum Beispiel:
- Was macht diese Änderung kompliziert?
- Wo ist die größte Unsicherheit?
- Welche Alternativen gibt es?
- Welche Lösung wäre kurzfristig schneller, aber langfristig teurer?
- Welche Auswirkungen hätte das auf Betrieb, Support oder Folgefeatures?
- Was müssen wir heute verstehen, um sauber entscheiden zu können?
Das sind keine Entwicklerfragen. Das sind gute Produktfragen mit technischem Bewusstsein.
Was mir in der Praxis am meisten geholfen hat
Mir hat vor allem geholfen, Technik nicht als Spezialgebiet der Entwickler zu sehen, sondern als Teil des Produktkontexts.
Nicht im Sinn von: "Ich muss alles selbst können."
Sondern im Sinn von: "Ich muss genug verstehen, um die Tragweite von Entscheidungen zu erkennen."
Das verändert Gespräche enorm.
Plötzlich diskutierst du nicht mehr nur über Wünsche und Aufwand. Sondern über Auswirkungen, Zielkonflikte, Risiken und sinnvolle Reihenfolgen.
Und genau dort wird die Zusammenarbeit zwischen Product Owner und Entwicklung wirklich stark.
Fazit
Ein guter Product Owner muss nicht programmieren können. Aber er sollte technische Zusammenhänge so gut verstehen, dass er Klarheit schafft, statt zusätzliche Unschärfe zu erzeugen.
Er sollte erkennen, wo Komplexität entsteht. Wo Risiken unterschätzt werden. Wo Qualität Produktwert beeinflusst. Und wo technische Themen keine Nebensache, sondern Teil der eigentlichen Produktentscheidung sind.
Wer das beherrscht, wird nicht zum halben Entwickler. Sondern zu einem deutlich wirksameren Product Owner.
