Agentic Product Ownership für Teams

Teams, die Agentic Product Ownership übernehmen, liefern mehr, mit schärferen Spezifikationen und weit weniger Momenten von „Moment, was meinten wir damit eigentlich?“.

Der Unterschied liegt darin, wo die KI sitzt. Die meisten Teams schnallen eine KI ans Ende des Zyklus, um aus einem halbfertigen Ticket Code zu erzeugen. APO stellt einen Mitarbeiter über den ganzen Zyklus — vom Zuschnitt der Arbeit über das Bauen bis zum Prüfen —, damit Qualität eingebaut wird statt nachträglich geflickt. Die vollständige Methode steht in der APO-Übersicht.

Der Ablauf, den ein Team übernimmt

APO legt sich auf die Rollen, die dein Team schon hat:

Der Product Owner fährt /we:story-Sessions, um eine Absicht in einen build-reifen Plan mit echten Acceptance Criteria zu verwandeln — oder beruft einen Council ein, wenn eine Entscheidung mehr als eine Linse braucht (Architect, Security, UX).
Der Entwickler fährt /we:orchestrate, den Lead. Er schickt Worker los, die nur entwickeln, führt zusammen, was sie pushen, auf einen Branch, und fährt den Rest einmal über den gemeinsamen Diff — vereinfachen, das Acceptance-Gate, die Qualitätsprüfungen, die Dokumentation und einen prüfbaren PR.
Das Review ist teilweise automatisiert — die Gates laufen, bevor ein Mensch überhaupt hinsieht, das menschliche Review startet also auf Grün. N Worker kosten weiterhin einen CI-Lauf, nicht N.

Was sich ändert

Bessere Tickets hinein heißt weniger Nacharbeit heraus. Ein Plan, der seine Acceptance Criteria vorab benennt, ist ein Plan, den das ganze Team gleich liest. Die Höhenebenen — Vision, Saga, Epic, Story — halten große Absichten mit den kleinen Schnitten verbunden, die sie liefern, damit nichts abdriftet.

Erste Schritte

Ein Team braucht Claude Code, das we Plugin und — für Vision und Erinnerung aus einem Companion — einen weside-Account über den MCP-Server. Fahre /we:setup einmal je Repository, damit Stack und Ticketing-Werkzeug erkannt werden, und fang dann auf der Höhenebene an, zu der die Arbeit gehört. /we:standup sagt, wo ein Branch steht, und /we:map gibt den nur lesenden Baum über alle Pläne — niemand muss raten, was als Nächstes dran ist.