Lernen mit ChatGPT als Product Owner – Warum dieser Abschnitt der Serie hier endet – und was jetzt folgt
Diese Serie endet an dieser Stelle nicht. Aber sie wechselt den Fokus.
Mit dem Reflexionspanel ist die inhaltliche Intervention abgeschlossen. Der Lernraum ist bewusst gestaltet. Der Ablauf klar begrenzt. Design ist zu diesem Zeitpunkt bewusst nach hinten priorisiert.
Aus Product-Owner-Sicht ist damit eine Phase abgeschlossen: Die Phase der didaktischen Klärung.
Laptop auf einem aufgeräumten Schreibtisch mit einem Reflexionspanel, das den Übergang vom Ablauf zur bewussten Nachbereitung einer Intervention markiert.
Was folgt, ist keine inhaltliche Erweiterung mehr, sondern eine Professionalisierung.
Der nächste Schritt: vom Prototyp zur belastbaren Entwicklungsbasis
Ab hier verschiebt sich der Schwerpunkt:
vom „Was soll dieses System zeigen?“
hin zu „Wie wird dieses System zuverlässig weiterentwickelt?“
Das bedeutet konkret:
Einbindung des Projekts in GitHub
Aufbau einer CI/CD-Pipeline für Unity
erste Schritte in Richtung Testautomatisierung
Nicht, weil es technisch schick ist. Sondern weil Lernen ohne Stabilität nicht skalierbar ist.
Warum auch das Teil von Lernen mit ChatGPT ist
Auch in dieser nächsten Phase bleibt ChatGPT Teil des Prozesses. Nicht als Ersatz für Engineering-Kompetenz, sondern als Denk- und Strukturhilfe.
Die Fragen ändern sich:
Wie strukturiere ich Build- und Testprozesse?
Wo lohnt sich Automatisierung – und wo nicht?
Welche Qualitätssignale brauche ich als Product Owner?
Die Serie geht also weiter. Aber mit einem anderen Blick:
Vom Lernprototyp zur professionellen Entwicklungsarbeit.
Lernen mit ChatGPT als Product Owner – Warum Regie, Sprecher und Fehleranalyse zusammengehören
In dieser Blogserie teile ich meine Lernerfahrungen im Umgang mit ChatGPT – aus der Perspektive eines Agile Coaches und Product Owners, der KI nicht nutzt, um schneller zu liefern, sondern um besser zu denken. Die Texte entstehen dabei selbst im Dialog mit ChatGPT und sind Teil dieses Lernprozesses.
Reflexionen über Coaching, Produktdenken und KI-gestützte Entwicklung
Am sechsten Tag habe ich begonnen, etwas umzubauen, das auf den ersten Blick wie ein UI-Thema aussah.
Es ging um Text. Aber nicht um Inhalte.
Es ging um die Frage, welche Information welche Verantwortung trägt.
Was ich an diesem Tag bewusst verändert habe
Aus Produkt- und Entwicklungssicht habe ich mich entschieden, eine bislang implizite Annahme explizit zu machen:
Systemzustand und gesprochener Text sind nicht dasselbe.
Konkret habe ich zwei Ebenen voneinander getrennt:
Regie: Systemstatus, Phasen, Meta-Informationen
Sprecher: das, was die Personas tatsächlich sagen
Bis dahin war beides technisch vorhanden, aber nicht klar voneinander abgegrenzt.
Als Product Owner war das eine bewusste Produktentscheidung: Das System soll beobachtbar sein, ohne sich selbst zu erklären.
Darstellung eines Entwicklungsarbeitsplatzes mit klar getrennten Informationen für Regie, Sprechertexte und Fehleranalyse.
Warum diese Entscheidung zunächst neue Probleme erzeugt hat
Nach der Trennung wurde etwas sichtbar, das vorher verdeckt war.
Texte erschienen an unerwarteten Stellen. Einige Informationen überlagerten sich. Manche Zustände waren sichtbar, obwohl sie es nicht hätten sein sollen.
Das System lief. Aber es fühlte sich inkonsistent an.
Das war kein klassischer Bug. Es war ein Konsequenzproblem.
Das Auftauchen der Fehleranalyse
Erst durch die bewusste Trennung von Regie und Sprecher wurde klar, wo das eigentliche Problem lag:
UI-Elemente hatten mehrere Verantwortungen gleichzeitig
Systemwissen wurde ungefiltert sichtbar gemacht
Fehler ließen sich nicht isolieren, weil Zuständigkeiten vermischt waren
Die Fehleranalyse war nicht der Startpunkt dieses Tages. Sie war das Ergebnis einer vorherigen Designentscheidung.
Wie ChatGPT bei der Fehleranalyse geholfen hat
ChatGPT hat mir an diesem Tag keinen Code korrigiert.
Die Hilfe lag an einer anderen Stelle: bei der sprachlichen Präzisierung des Problems.
Statt „Warum ist der Text falsch platziert?“ habe ich Fragen formuliert wie:
Welche Verantwortung hat dieses UI-Element?
Für wen ist diese Information gedacht?
Warum fühlt sich diese Anzeige erklärend an?
Diese Fragen haben mir geholfen, Symptome von Ursachen zu trennen.
ChatGPT war hier kein Problemlöser, sondern ein Sparringspartner für sauberes Denken.
Was ich daraus als Product Owner gelernt habe
Ich habe an diesem Tag sehr konkret gelernt:
Fehleranalyse ist Teil von Produktarbeit, nicht nur Teil von Entwicklung.
Erst wenn Zuständigkeiten klar sind, werden Fehler sichtbar. Und erst dann werden sie lösbar.
Die Trennung von Regie und Sprecher war keine UI-Verbesserung.
Sie war eine Voraussetzung dafür, überhaupt sinnvoll über Fehler sprechen zu können.
Eine Einladung an Dich
Wenn du Systeme, Produkte oder Oberflächen gestaltest:
Wo versuchst du Fehler zu beheben, ohne vorher Verantwortungen zu klären?
Und wo könnte eine saubere Trennung erst ermöglichen, dass Probleme überhaupt sichtbar werden?
Am nächsten Tag habe ich begonnen, das Ende bewusst als eigenen Reflexionsraum zu gestalten.
Serien-Abspann: Dieser Beitrag ist Teil einer fortlaufenden Blogserie, in der ich meine Lernerfahrungen im Umgang mit ChatGPT dokumentiere. Die Texte entstehen im Dialog mit ChatGPT und spiegeln meinen aktuellen Denkstand als Agile Coach und Product Owner wider – nicht fertige Antworten, sondern bewusst geteilte Zwischenschritte.
Lernen mit ChatGPT als Product Owner – Warum Dialoge, Sprache und Grenzen zusammengehören
In dieser Blogserie teile ich meine Lernerfahrungen im Umgang mit ChatGPT – aus der Perspektive eines Agile Coaches und Product Owners, der KI nicht nutzt, um schneller zu liefern, sondern um besser zu denken. Die Texte entstehen dabei selbst im Dialog mit ChatGPT und sind Teil dieses Lernprozesses.
Reflexionen über Coaching, Produktdenken und KI-gestützte Entwicklung
Am fünften Tag habe ich begonnen, dem System eine Stimme zu geben. Nicht im Sinne von Interaktion, sondern im Sinne von Text.
Dialoge wurden konkret. Und damit auch viele neue Entscheidungen.
Was an diesem Tag entstanden ist
Technisch betrachtet habe ich an diesem Tag weniger Logik gebaut, sondern Inhalte strukturiert.
erste Dialogtexte, generiert mit ChatGPT
klare Trennung von Dialoginhalt und Ablaufsteuerung
eine einfache Struktur für mehrere Sprachen
Der entscheidende Punkt war dabei: Dialoge sind Daten, keine Intelligenz.
Darstellung eines Entwicklungsarbeitsplatzes mit Textinhalten als Datenbasis für Dialoge und Internationalisierung.
ChatGPT als Textlieferant, nicht als Erzähler
ChatGPT hätte problemlos komplexere Dialoge erzeugen können. Variabler. Situativer. Reaktiver.
Genau das wollte ich nicht.
Als Product Owner habe ich an diesem Tag gelernt: Nicht alles, was möglich ist, ist hilfreich.
Die Dialoge sollten klar sein. Wiederholbar. Vorhersehbar.
Internationalisierung als Strukturentscheidung
Parallel zu den Dialogen habe ich eine zweite Sprache eingeführt. Nicht, weil es nötig war, sondern weil es strukturell sinnvoll war.
Internationalisierung ist kein Feature. Sie ist eine Frage der Architektur.
Ich habe mich bewusst dagegen entschieden:
während des Ablaufs die Sprache zu wechseln
Dialoge dynamisch zu übersetzen
Komplexität durch Komfort zu rechtfertigen
Die Sprache wird festgelegt. Dann läuft das System.
Vereinfachung als Produktverantwortung
Dieser Tag war ein gutes Beispiel dafür, wie schnell Systeme unnötig komplex werden.
Jede zusätzliche Option hätte sich plausibel anfühlen können. Und genau darin liegt die Gefahr.
Als Product Owner habe ich gelernt: Vereinfachung ist keine technische Einschränkung. Sie ist eine bewusste Entscheidung.
Was ich über Lernen mit ChatGPT gelernt habe
ChatGPT war an diesem Tag sehr effizient. Texte waren schnell da.
Der eigentliche Lernprozess lag aber nicht im Schreiben, sondern im Weglassen.
Ich habe gemerkt: KI hilft mir hier nicht durch Kreativität, sondern durch die Möglichkeit, Optionen sichtbar zu machen – und mich dann bewusst dagegen zu entscheiden.
Grenzen machen Systeme verständlich
Am Ende des Tages war das System weniger flexibel als möglich. Aber deutlich klarer als zuvor.
Die Dialoge sagen, was sie sagen sollen. In der gewählten Sprache. Zur richtigen Zeit.
Mehr nicht. Und genau das ist ausreichend.
Eine Einladung an Dich
Wenn du mit KI Texte, Inhalte oder Dialoge erzeugst: Wo lässt du Optionen bewusst offen?
Und wo setzt du Grenzen, damit dein System verständlich bleibt?
Am nächsten Tag habe ich begonnen, Regie und Sprecher konsequent zu trennen. Und damit eine weitere Grenze eingezogen.
Serien-Abspann: Dieser Beitrag ist Teil einer fortlaufenden Blogserie, in der ich meine Lernerfahrungen im Umgang mit ChatGPT dokumentiere. Die Texte entstehen im Dialog mit ChatGPT und spiegeln meinen aktuellen Denkstand als Agile Coach und Product Owner wider – nicht fertige Antworten, sondern bewusst geteilte Zwischenschritte.
Lernen mit ChatGPT als Product Owner – Warum Zeitlogik wichtiger war als Dialogsteuerung
In dieser Blogserie teile ich meine Lernerfahrungen im Umgang mit ChatGPT – aus der Perspektive eines Agile Coaches und Product Owners, der KI nicht nutzt, um schneller zu liefern, sondern um besser zu denken. Die Texte entstehen dabei selbst im Dialog mit ChatGPT und sind Teil dieses Lernprozesses.
Reflexionen über Coaching, Produktdenken und KI-gestützte Entwicklung
Am vierten Tag habe ich begonnen, das Daily Scrum nicht mehr als Gespräch zu betrachten, sondern als System mit einem zeitlichen Ablauf.
Das war ein bewusster Perspektivwechsel. Und ein technischer.
Was ich an diesem Tag gebaut habe
Aus Entwicklungssicht ging es an diesem Tag nicht um Inhalte, sondern um Struktur unter Zeitdruck.
eine klar definierte Abfolge von Phasen
eine explizite Zeitlogik
einen zentralen Controller, der den Ablauf steuert
Dialoge waren nachgeordnet. Wichtig war zunächst nur eines: Was passiert wann – und was passiert dann nicht mehr?
Arbeitsplatz mit Laptop, Uhr und schematischem Ablaufdiagramm, das Zeitlogik und Phasensteuerung als Teil des Systemdesigns zeigt.
Warum Zeit eine Produktentscheidung ist
Als Product Owner habe ich an diesem Tag etwas sehr Konkretes gelernt: Zeit ist kein UI-Detail. Zeit ist Teil des Produktdesigns.
Indem ich Phasen fest definiere, lege ich fest, welche Verhaltensmuster überhaupt sichtbar werden können.
Ein offenes System lädt zum Ausweichen ein. Ein zeitlich begrenztes System erzeugt Druck. Und genau dieser Druck ist der eigentliche Lernträger.
Eskalation als Systemeigenschaft
Die Eskalation war kein Sonderfall, sondern eine logische Konsequenz des Designs.
Ich habe bewusst darauf verzichtet:
einzugreifen
zu moderieren
das System „klüger“ zu machen
Nicht aus Bequemlichkeit, sondern aus einer Produktentscheidung heraus:
Das System soll Muster zeigen, nicht lösen.
Was ich technisch gelernt habe
Technisch habe ich an diesem Tag vor allem gelernt, wie stark sich frühe Entscheidungen auswirken.
Ein zentraler Ablaufcontroller macht Dinge explizit: Übergänge. Zustände. Grenzen.
Und er zwingt mich als Product Owner, jede Ausnahme zu rechtfertigen.
Das war anstrengend. Aber sehr klärend.
Was ChatGPT in diesem Schritt beigetragen hat
ChatGPT war an diesem Tag kein Ideengeber. Sondern ein Korrektiv.
Immer wieder kam dieselbe Rückfrage: Ist das hier eine Produktentscheidung – oder ein Reflex?
Diese Frage hat mir geholfen, Zeitlogik nicht als technische Notwendigkeit, sondern als bewusstes Designmittel zu verstehen.
Das Ende ist Teil des Systems
Ein wichtiges Detail dieses Tages war das Ende.
Das Daily endet. Unabhängig davon, wie es gelaufen ist.
Dieses Ende ist kein Bug. Es ist ein Feature.
Als Product Owner habe ich hier gelernt: Nicht jedes System darf sich selbst korrigieren.
Eine Einladung an Dich
Wenn du Produkte, Prozesse oder Lernformate gestaltest: Wo behandelst du Zeit als Rahmen – und wo als aktives Gestaltungselement?
Und wo versuchst du, durch Flexibilität etwas zu kaschieren, das eigentlich sichtbar werden müsste?
Am nächsten Tag habe ich begonnen, Regie und Beobachtung explizit zu trennen. Und damit eine weitere Produktentscheidung getroffen.
Serien-Abspann: Dieser Beitrag ist Teil einer fortlaufenden Blogserie, in der ich meine Lernerfahrungen im Umgang mit ChatGPT dokumentiere. Die Texte entstehen im Dialog mit ChatGPT und spiegeln meinen aktuellen Denkstand als Agile Coach und Product Owner wider – nicht fertige Antworten, sondern bewusst geteilte Zwischenschritte.
Lernen mit ChatGPT als Product Owner – Warum technische Struktur wichtiger war als Spielfluss
In dieser Blogserie teile ich meine Lernerfahrungen im Umgang mit ChatGPT – aus der Perspektive eines Agile Coaches und Product Owners, der KI nicht nutzt, um schneller zu liefern, sondern um besser zu denken. Die Texte entstehen dabei selbst im Dialog mit ChatGPT und sind Teil dieses Lernprozesses.
Reflexionen über Coaching, Produktdenken und KI-gestützte Entwicklung
Am dritten Tag habe ich zum ersten Mal ernsthaft in Unity gearbeitet. Nicht mit dem Ziel, etwas Spielbares zu bauen, sondern um zu verstehen, wie sich technische Entscheidungen anfühlen.
Es gab keinen Spielfluss. Keine Animation. Keinen Moment, den man hätte zeigen können.
Stattdessen habe ich Struktur gebaut.
Was an diesem Tag technisch entstanden ist
Rückblickend war dieser Tag überraschend technisch. Nur eben nicht sichtbar.
eine klare Ordnerstruktur für Szenen, Skripte, UI und Charaktere
erste Konventionen für Namensgebung
eine bewusste Trennung von Ablaufsteuerung und Darstellung
ein zentraler Einstiegspunkt für den Tagesablauf
Ich habe gelernt, dass Technik nicht erst mit Code beginnt, sondern mit Entscheidungen darüber, wo Code überhaupt leben darf.
Arbeitsplatz mit Laptop und Skizzen, die eine klare Projekt- und Ordnerstruktur in der technischen Entwicklung zeigen.
Struktur als technische Entscheidung
Der größte Lernmoment war für mich: Struktur ist keine Vorarbeit. Sie ist bereits Implementierung.
Jede Ordnerentscheidung nimmt zukünftige Entscheidungen vorweg. Jede klare Trennung reduziert spätere Kopplung. Und jede Abkürzung rächt sich nicht sofort, aber zuverlässig.
Als Product Owner habe ich das früher oft unterschätzt. Jetzt habe ich es körperlich gespürt.
Die Versuchung, Technik zu vermischen
Mehrmals an diesem Tag war ich kurz davor, Logik dort zu platzieren, wo sie gerade „praktisch“ gewesen wäre.
Ein Skript hier. Ein schneller Zugriff dort. Ein kleiner Workaround, der schon funktionieren würde.
ChatGPT war hier kein Erklärbär. Es war eher ein nerviger Nachfrager:
Willst du das später noch verstehen?
Diese Frage hat gereicht.
Was ich konkret über Lernen mit ChatGPT gelernt habe
ChatGPT hat mir an diesem Tag nicht beigebracht, wie Unity funktioniert. Das hätte ich nachlesen können.
Es hat mir geholfen, technische Entscheidungen explizit zu machen: Warum trenne ich das hier? Warum benenne ich das so? Warum kommt diese Logik nicht einfach mit in das Skript?
Ich habe gelernt, dass Lernen mit KI für mich bedeutet, mein implizites Bauchgefühl in explizite Entscheidungen zu übersetzen.
Technik kann Ruhe erzeugen
Am Ende des Tages hatte ich kein Spiel. Aber ich hatte Orientierung.
Ich wusste, wo Dinge hingehören würden. Und vor allem: wo nicht.
Ordner und Hierachy Struktur
Die Technik fühlte sich nicht schwer an. Sondern stabil.
Eine Einladung an Dich
Wenn du selbst technische Entscheidungen triffst – als Entwickler, PO oder Coach: Woran merkst du, dass Struktur dir gerade hilft, klar zu bleiben?
Und woran merkst du, dass du Struktur benutzt, um unangenehme Entscheidungen aufzuschieben?
Am nächsten Tag habe ich dann angefangen, Ablauf und Zeitlogik umzusetzen. Und ich war überrascht, wie wenig Widerstand das plötzlich hatte.
Serien-Abspann: Dieser Beitrag ist Teil einer fortlaufenden Blogserie, in der ich meine Lernerfahrungen im Umgang mit ChatGPT dokumentiere. Die Texte entstehen im Dialog mit ChatGPT und spiegeln meinen aktuellen Denkstand als Agile Coach und Product Owner wider – nicht fertige Antworten, sondern bewusst geteilte Zwischenschritte.
