Arbeitsweise
KI ist bei mir kein Werkzeug im Prozess. Sie ist Teil des Teams.
Von der ersten Kundenstimme bis zum Nutzerfeedback in sechs Schritten. Klassisch war das eine Kette von Übergaben: Discovery, Spec, Design, Entwicklung, Test – jede Station mit Wartezeit und Interpretationsspielraum. Heute laufen Prototyp und Spezifikation parallel, und Agenten übernehmen die Umsetzung. Das verkürzt nicht nur die Zeit bis zum ersten benutzbaren Prototypen, es verschiebt auch meine Rolle: weg vom Beschreiben, hin zum Entscheiden und Prüfen.
Prinzip
Prototyp und PRD bewegen sich immer gemeinsam
Voraussetzung
Guardrails, die Qualität unabhängig vom Run sichern
Maßstab
Ob ein Feature gut ist, entscheiden die Nutzer
Haltung
KI soll die Arbeit übernehmen, die nicht menschlich ist – damit Raum bleibt für die, die es ist.
Im Produkt
Ich baue Produkte für die Menschen, die sie am Ende benutzen – zur Lösung echter Probleme. Wenn ich nicht benennen kann, wie und wem es konkret hilft, ist es nicht fertig gedacht.
In der Zusammenarbeit
Je mehr Arbeit an KI-Agenten geht, desto wichtiger wird, wie wir miteinander umgehen. Zuhören, Kontext teilen, Entscheidungen erklären – das lässt sich nicht delegieren.
Im Team
Neue Arbeitsweisen und Prozesse setzen sich nicht per Ansage durch. Ich probiere sie erst selbst aus, zeige Ergebnisse – und nehme das Team mit, statt es umzustellen.
Der Prozess
Sechs Schritte.
01
Anforderungen sammeln
So nah an den späteren Nutzern wie möglich: Gespräche, Beobachtung, Support-Signale. KI hilft dabei, die Vielzahl an Stimmen zu verdichten und überschneidende Probleme sichtbar zu machen. Die Priorisierung erarbeite ich daraus – begründet aus den Nutzerinterviews, nicht aus dem Bauch.
02
Prototyp bauen
Kein produktiver Code, sondern eine Attrappe, die aussieht und sich anfühlt wie die echte Software: Klickpfade, Zustände, Business-Logik. In Minuten spürt man, was an welcher Stelle Sinn ergibt – und was nicht.
03
PRD im Gleichschritt
Prototyp und Spezifikation bewegen sich immer gemeinsam. Jede Iteration am Prototyp schreibt sich in die Spec zurück, sodass am Ende ein PRD steht, das den Prototyp 1:1 abbildet – implementierbar, ohne weitere Klärungsschleifen.
04
Agent-Harness
Damit ein Agent verlässlich abliefert, braucht er mehr als eine gute Spec: verbindliche Konventionen, Architekturvorgaben, Definition of Done, automatische Tests und Checks vor jedem Merge. Das Harness ist die Voraussetzung dafür, dass Qualität nicht vom Zufall des einzelnen Runs abhängt, sondern reproduzierbar ist.
05
Agentisch umsetzen
Der Agent baut gegen drei Dokumente: das PRD für das Was, das ARD für die Architektur – von den Entwicklern erarbeitet – und das DRD für Prototyp, CI-Vorgaben und Design System. Meine Rolle verschiebt sich vom Beschreiben zum Prüfen: bewerten, ob das Ergebnis der Absicht entspricht, und nachsteuern, wo es abweicht.
06
Zurück zu den Nutzern
Bewertet wird dort, wo die Software später läuft – bei den Leuten, die sie benutzen. Deren Reaktionen gehen direkt in die nächste Runde aus Prototyp und PRD. Die Schleife endet nicht, sie wird nur kürzer.
Womit