thoughts
Wo ich glaube, dass ich falschliege
Alle anderen Artikel auf dieser Seite sind mit einer gewissen Überzeugung geschrieben. Dieser Text ist das Gegengewicht dazu.
Wenn ich nur Argumente veröffentliche, die meine eigene Sicht bestätigen, mache ich genau das, was ich selbst kritisch sehe: Ich vermittle Gewissheit, obwohl es sie oft gar nicht gibt. Deshalb möchte ich bewusst die stärksten Gegenargumente zu meinen eigenen Positionen festhalten – nicht, weil ich sie widerlegen kann, sondern weil ich sie ernst nehme.
Macht KI wirklich Zeit für Wichtiges frei?
Ich argumentiere häufig, dass KI repetitive Arbeit übernimmt und dadurch Zeit für strategische Aufgaben schafft.
Das setzt allerdings voraus, dass diese gewonnene Zeit tatsächlich dort investiert wird.
Vielleicht passiert genau das nicht.
Freie Kapazität füllt sich erstaunlich schnell mit neuen Meetings, zusätzlichen Tickets oder noch mehr operativer Arbeit. Ein leerer Kalender bleibt selten lange leer.
KI gibt mir also nicht automatisch mehr Zeit für Strategie. Sie gibt mir lediglich die Möglichkeit dazu. Ob ich diese Möglichkeit nutze, hängt letztlich von meiner eigenen Disziplin ab – und die kann mir kein Werkzeug abnehmen.
Ein weiterer Punkt beschäftigt mich ebenfalls. KI macht es immer einfacher, produktiv auszusehen. Gut formulierte Dokumente, saubere Tickets und perfekt strukturierte Boards entstehen heute in wenigen Minuten. Dadurch wird es schwieriger zu erkennen, ob tatsächlich gute Produktarbeit geleistet wurde oder lediglich viel Output entstanden ist.
Vielleicht täuscht KI nicht nur andere. Vielleicht täuscht sie manchmal auch mich selbst.
Wird durch weniger Schreiben auch weniger gedacht?
Ich argumentiere oft, dass Product Owner weniger Zeit mit dem Schreiben von Tickets verbringen sollten.
Dabei übersehe ich möglicherweise einen wichtigen Punkt.
Schreiben dient nicht nur der Dokumentation. Sehr oft entsteht Klarheit überhaupt erst während des Schreibens. Erst wenn Gedanken in vollständige Sätze übersetzt werden, fallen Lücken, Widersprüche oder fehlende Annahmen auf.
Wenn KI diesen Schritt übernimmt, besteht das Risiko, dass nicht nur das Schreiben ausgelagert wird, sondern auch ein Teil des Denkprozesses.
Vielleicht verliere ich dadurch genau den Moment, in dem ich selbst erkannt hätte, dass meine Idee noch nicht ausgereift war.
Gewinnen Daten wirklich immer?
Ich schreibe häufig, dass Daten langfristig bessere Entscheidungen ermöglichen als Meinungen.
Das stimmt wahrscheinlich oft – aber eben nicht immer.
Daten können nur das messen, was bereits existiert. Sie belohnen schrittweise Verbesserungen und machen es schwer, große neue Ideen objektiv zu bewerten. Viele erfolgreiche Produkte hätten in ihrer ersten Version vermutlich keine überzeugenden Kennzahlen geliefert.
Außerdem kann man sich hinter Daten genauso verstecken wie hinter Meinungen.
„Die Zahlen sagen das“ klingt objektiv, kann aber genauso gut bedeuten, dass niemand Verantwortung für eine schwierige Entscheidung übernehmen möchte.
Nicht jede Diskussion sollte mit einer Kennzahl beendet werden.
Reicht ein bisschen Programmieren wirklich aus?
Ich bin überzeugt, dass Product Owner selbst Software bauen sollten.
Gleichzeitig sehe ich darin auch ein Risiko.
Ein kleines Nebenprojekt vermittelt schnell das Gefühl, Softwareentwicklung verstanden zu haben. Tatsächlich lernt man dabei aber häufig nur einen kleinen Ausschnitt kennen – ohne Legacy-Systeme, komplexe Architekturen, Sicherheitsanforderungen oder tausende Nutzer.
Gerade dieses Halbwissen kann gefährlich werden.
Wer einmal erfolgreich eine kleine Anwendung gebaut hat, unterschätzt möglicherweise den Aufwand echter Produktionssysteme oder beginnt, technische Entscheidungen treffen zu wollen, ohne den gesamten Kontext zu kennen.
Das wäre genau das Gegenteil dessen, was ich eigentlich erreichen möchte.
Sollten Product Owner wirklich Pull Requests öffnen?
Das ist wahrscheinlich die These, bei der ich selbst die größten Fragezeichen habe.
Vielleicht funktioniert sie nur in kleinen Teams. Vielleicht scheitert sie an Verantwortlichkeiten. Vielleicht erzeugt sie sogar mehr Probleme, als sie löst.
Wenn ein Product Owner einen KI-generierten Pull Request erstellt, stellt sich zwangsläufig die Frage nach der Verantwortung. Wem gehört der Fehler, wenn später ein Bug entsteht? Der Person, die den Pull Request erstellt hat? Dem Entwickler, der ihn reviewed hat? Oder der KI, die den Code geschrieben hat?
Darauf habe ich heute keine überzeugende Antwort.
Ein weiterer Punkt beschäftigt mich ebenfalls.
Ein erster funktionierender Entwurf wirkt schnell wie eine offensichtliche Lösung. Genau dadurch kann er bessere Ideen verhindern. Menschen orientieren sich stark am ersten Vorschlag, den sie sehen. Vielleicht sorgt ein funktionierender Prototyp deshalb manchmal dafür, dass Teams weniger kreativ denken, statt mehr.
Und letztlich hängt das gesamte Modell davon ab, dass KI-generierte Entwürfe gut genug sind, um ein sinnvolles Review überhaupt zu ermöglichen. Wenn sie dauerhaft knapp unter dieser Schwelle bleiben, kostet das Review mehr Zeit, als komplett neu zu entwickeln.
Dann wäre die gesamte Idee falsch.
Warum ich trotzdem an diesen Gedanken festhalte
Keiner dieser Punkte überzeugt mich davon, dass meine bisherigen Positionen grundsätzlich falsch sind.
Sie erinnern mich lediglich daran, dass Überzeugungen keine Gewissheiten sind.
Ich möchte meine Meinungen deshalb eher als Arbeitshypothesen verstehen: stark genug, um danach zu handeln, aber flexibel genug, um sie wieder zu ändern, wenn die Realität etwas anderes zeigt.
Vielleicht werde ich mit einigen dieser Einschätzungen falschliegen. Wahrscheinlich sogar.
Aber ich glaube, es ist sinnvoller, die eigenen Zweifel offen auszusprechen, als so zu tun, als hätte man auf komplexe Fragen bereits endgültige Antworten.

