Wenn ich ehrlich auf meine Woche als Product Owner schaue, geht ein erstaunlich großer Teil nicht für Entscheidungen drauf, sondern für Vorarbeit. Recherchieren, was der Markt macht und was technisch überhaupt geht. Aus dieser Recherche tragfähige Stories formen. Die technische Planung so weit vorbereiten, dass ein Gespräch mit den Entwicklern überhaupt sinnvoll ist. Das sind die Aufgaben, die mir über Jahre die meiste Zeit gefressen haben. Die Stakeholderpflege kostet auch Zeit, aber die nimmt mir keine Maschine ab – und das ist auch gut so. Bei allem anderen stellte sich irgendwann die Frage: Muss ich das wirklich jedes Mal von Hand machen?
Kurze Unterbrechung – das Agile-Nachschlagewerk unserer Agile Community
Warum eine Strecke und nicht einfach ein Prompt
Mein erster Reflex war, einzelne Aufgaben an ein Large Language Model zu geben. Das half punktuell, blieb aber beliebig: Mal war das Ergebnis brauchbar, mal nicht, und ich musste jedes Mal neu erklären, was ich eigentlich will. Der Wendepunkt war die Entscheidung, nicht mehr in einzelnen Prompts zu denken, sondern in einer Strecke – mehreren spezialisierten Agenten, die nacheinander arbeiten und deren Ergebnis jeweils das Material für den nächsten Schritt ist.
Gebaut habe ich das im Terminal mit Claude Code. Das Leitprinzip dabei war bewusst eng: ein Agent, eine klar abgegrenzte Aufgabe. Kein Alleskönner, der alles halb macht, sondern drei Spezialisten, die jeweils eine Sache gut machen. Genau dieser Zuschnitt sorgt dafür, dass ich die Ergebnisse auch prüfen kann – ich weiß bei jedem Schritt, was er leisten soll, und merke deshalb schnell, wenn er es nicht tut.
Die drei Agenten
- Der Rechercheagent (Sonnet) steht am Anfang. Er sammelt und verdichtet, was ich sonst aus vielen Quellen zusammensuchen müsste: Markt und Wettbewerb, Nutzerbedürfnisse, die Features der Konkurrenz, erste Hinweise zur technischen Machbarkeit. Für diese Aufgabe habe ich bewusst das schnellere Modell gewählt – hier geht es um Breite und Tempo, nicht um die letzte Tiefe der Argumentation.
- Der fachliche Planungsagent (Opus) nimmt die Recherche und baut daraus ein fachlich abgestimmtes Storyboard, inklusive passender Personas. Aus losen Erkenntnissen wird hier also schon eine fachliche Struktur, an der ich weiterarbeiten kann.
- Der technische Planungsagent (Opus) erstellt parallel eine technische Struktur, die ich als Diskussionsgrundlage in die Entwicklerrunde werfen kann. Für beide Planungsschritte nutze ich das stärkere Modell, weil hier die anspruchsvollere Arbeit liegt: Zusammenhänge bewerten, Optionen abwägen, eine Struktur vorschlagen, die einem fachlichen Gegencheck standhält. Die Modellwahl ist also kein Zufall, sondern folgt dem Anspruch der jeweiligen Aufgabe – breit und schnell vorne, gründlich und stark hinten.
Die Phasentrennung ist das eigentliche Quality Gate
Der Trick, warum ich den Ergebnissen überhaupt trauen kann, steckt nicht in der KI, sondern im Aufbau. Jede Phase hat eine harte Verbots-Regel – und zwar genau an der Stelle, wo der natürliche Reflex wäre, vorzupreschen.
Die Recherche darf nicht lösen. Der Rechercheagent liefert Fakten, aber ausdrücklich keine Implementierungsvorschläge. Jede relevante Aussage muss belegt sein – mit Pfad, Datei und Zeile plus einem Satz Begründung. Annahmen müssen als Annahmen markiert werden, statt als Fakten durchzugehen. Und es gibt eine Pflicht-Sektion „Offene Fragen“, damit nichts an die Planung übergeben wird, solange Kernfragen ungeklärt sind. Das verhindert das, was bei KI am gefährlichsten ist: halluzinierte Sicherheit und vage „irgendwo im Code“-Aussagen.
Die fachliche Planung darf nicht technisch werden. Keine Tabellen, keine Feld- oder Endpoint-Namen, keine Frameworks – auch nicht in den Akzeptanzkriterien. Die werden überprüfbar formuliert (Given/When/Then, rein beobachtbares Verhalten), und eine Pflicht-Sektion „Nicht-Ziele / Abgrenzung“ hält den Scope sauber. So nimmt keine technische Lösung die Anforderung vorweg, bevor das Problem überhaupt verstanden ist.
Die technische Planung darf nicht coden. Kein Produktivcode, nur planen. Entscheidungen werden mit „gewählt vs. verworfen + Begründung“ dokumentiert, die Schritte klein und abarbeitbar geschnitten, eine Teststrategie ist verpflichtend mitgeplant, und „Risiken & Seiteneffekte“ sind eine Pflicht-Sektion. Das holt die blinden Flecken nach vorne, statt sie in Produktion auffallen zu lassen.
Die Phasentrennung selbst ist also das Quality Gate. Nicht ich muss bei jedem Lauf daran denken, das Modell zu bremsen – die Strecke ist so gebaut, dass sie es gar nicht erst tun lässt.
Vom Entwurf zur Diskussion
Der spürbarste Unterschied zeigt sich beim Übergang in die Entwicklerrunde. Früher waren genau diese Vorbereitungen viele Arbeitsstunden – besonders die technische Planung, die ich oft gemeinsam mit ein paar ausgesuchten Entwicklern gemacht habe. Das sind wertvolle Leute, die ich damit für den ersten Aufschlag gebunden habe, lange bevor überhaupt klar war, in welche Richtung es geht.
Heute steht der Erstentwurf deutlich schneller. Die Struktur des technischen Planungsagenten „werfe“ ich in die Runde, und wir steigen auf einer fertigen Vorlage ein, statt bei null anzufangen. Wichtig ist mir dabei: Diese Vorlage ist ein Diskussionsentwurf, kein Beschluss. Aus dem KI-Vorschlag und der Erfahrung der Entwickler entsteht in der Diskussion meistens ein Mix – und dieser Mix ist am Ende besser als beides für sich allein.
Der ehrliche Teil
So gut das klingt: Die Strecke nimmt mir die Arbeit nicht ab, sie verschiebt sie. Zwei Dinge halte ich konsequent durch, sonst funktioniert das Ganze nicht.
Erstens, der harte Gegencheck. Ich übernehme nichts blind. Ein Beispiel, das mir das deutlich vor Augen geführt hat: Bei der Recherche für einen Chatbot ist die Strecke in eine völlig falsche Richtung abgebogen. Die Personas passten nicht, und das Story Mapping war so schlicht nicht zu gebrauchen. Das wieder geradezuziehen hat mich am Ende richtig Arbeit gekostet – mehr, als wenn ich von vornherein genauer hingesehen hätte. Seitdem ist mir klar: Die Gates erzwingen Belege und Begründungen, aber ob die Belege stimmen und die Richtung überhaupt passt, entscheide am Ende ich. Die KI beschleunigt den Weg zum Entwurf, die Verantwortung für die Qualität bleibt bei mir.
Zweitens, die Kontextgrenze. Wird ein Projekt sehr speziell, kann die KI wenig beitragen, weil sie selbst nicht genug Kontext herstellen kann. Dann nützt mir die beste Strecke nichts, und ich bin wieder klassisch gefragt. Es lohnt sich, das früh zu erkennen, statt einem Modell etwas abringen zu wollen, das es nicht liefern kann.
Was sich wirklich ändert
Unterm Strich spare ich viel Zeit bei Recherche und Planung. Und diese Zeit fließt dorthin, wo ich als PO wirklich gebraucht werde: in Priorisierung und Stakeholderarbeit. Die Maschine räumt die Fleißarbeit weg, ich kümmere mich um die Entscheidungen. Das ist der eigentliche Gewinn – nicht „die KI macht meinen Job“, sondern „die KI macht den Teil, der mich von meinem Job abgehalten hat“.
Eine Sache solltest du dabei aber nicht übersehen, und sie ist fast die Pointe: Die Zeit verschwindet nicht, sie wandert. Das Wissen, das ich in Stakeholdermeetings gewinne, muss ich anschließend aufbereiten und der Strecke wieder als Kontext bereitstellen, damit die nächste Runde etwas taugt. Praktisch läuft das über Dokumente: Ich reiche Meetingprotokolle oder andere Unterlagen ein und lasse daraus ein Markdown erzeugen, oder ich lege die Dokumente in einen Ordner, auf den Claude direkten Zugriff hat. Gute Ergebnisse kommen eben nicht aus dem Tool – sie kommen aus dem Kontext, den ich hineinstecke. Wer das überspringt, bekommt schnellere, aber schlechtere Vorlagen.
Eine Gedächtnisschleife über Sessions hinweg
Damit dieser Kontext nicht bei jedem Start verloren geht, habe ich mir zwei Skills bauen lassen, die als symmetrisches Paar gedacht sind: /resume öffnet eine Session, /wrap schließt sie. Das Problem dahinter ist banal und trotzdem teuer: Ein Sprachmodell beginnt jede Session bei null. Ohne bewusste Übergabe erkläre ich jedes Mal aufs Neue, wo wir stehen.
/wrap schreibt den Zustand am Ende einer Runde gezielt in zwei dauerhafte Speicher – die Fakten in einen Speicher, den eigentlichen Arbeitskontext in einen Übergabe-Prompt für die nächste Session. /resume liest beides beim nächsten Start wieder ein, fasst in wenigen Zeilen zusammen, wo wir stehen, und stoppt dann – es startet nichts, ändert nichts, sondern wartet auf meine Richtung.
Und genau hier schließt sich der Kreis zum Aufbau der ganzen Strecke: /wrap darf schreiben, /resume darf nur lesen. Diese saubere Trennung von Schreib- und Lesephase verhindert, dass der Wiedereinstieg versehentlich Zustand verändert – dasselbe Gate-Prinzip wie bei den Planungs-Agenten, nur eine Ebene höher. Nicht die KI sorgt für Verlässlichkeit, sondern die Disziplin, die ich ihr im Aufbau mitgebe.
Was du mitnehmen kannst
Wenn du nur eine Sache ausprobierst: Zerleg nicht gleich deine ganze PO-Rolle, sondern eine einzige nervige Teilaufgabe – etwa die Recherche – und bau dir dafür einen klar umrissenen Agenten. Eng zugeschnitten, ein Agent für eine Aufgabe. Das ist schneller gebaut, leichter zu prüfen, und du merkst sofort, ob es dir tatsächlich Zeit bringt. Erst wenn dieser eine Schritt sitzt, lohnt es sich, ihn zu einer Strecke wachsen zu lassen.
Und gib jeder Phase eine harte Verbots-Regel an der Stelle, wo der Reflex wäre vorzupreschen. Genau diese Disziplin – plus der Gegencheck danach – macht den Unterschied zwischen einem netten Spielzeug und einem Werkzeug, das im Alltag trägt. dokumentiert, die Schritte klein und abarbeitbar geschnitten, eine Teststrategie ist verpflichtend mitgeplant, und „Risiken & Seiteneffekte“ sind eine Pflicht-Sektion. Das holt die blinden Flecken nach vorne, statt sie in Produktion auffallen zu lassen.
Die Phasentrennung selbst ist also das Quality Gate. Nicht ich muss bei jedem Lauf daran denken, das Modell zu bremsen – die Strecke ist so gebaut, dass sie es gar nicht erst tun lässt.
Schreibe einen Kommentar