Team & Agilität

Wie Product Owner ihre Teams aus der Umsetzungsecke holen

Lucian Katzbach Gamification Designer & Startup Coach

6. Juni 2025Veröffentlicht

2 MinLesezeit

Am Whiteboard links zwei ausgefüllte Spezifikationsblöcke, ein Pfeil nach rechts, und dort eine Kette aus Nutzer, Zielscheibe und drei Schritten, darunter zufriedenes Gesicht, steigende Kurve und Stern

Viele Product Owner kennen das Dilemma:

Sie schreiben sorgfältig formulierte User Stories, oft mit detaillierten Akzeptanzkriterien, klaren UI-Spezifikationen und sauberen Prozessen. Trotzdem kommen vom Team Rückfragen wie:

„Was genau soll hier passieren, wenn…?“
„Warum braucht der Nutzer das eigentlich?“
„Kann ich einfach das Pattern vom letzten Feature übernehmen?“

Auf den ersten Blick scheint es, als bräuchte das Team mehr Kontext oder klarere Vorgaben. Die Folge: Noch detailliertere Stories. Noch mehr „Handholding“. Noch mehr Verantwortung auf Seiten des Product Owners.

Aber was wäre, wenn der Detaillierungsgrad selbst das Problem ist?

Von Umsetzung zu Mitdenken

Auf dem Bildschirm eine Kette: Nutzer, ein unzufriedenes Gesicht, eine Glühbirne und ein grüner Haken, mit gestrichelter Rückkopplung; darunter vier Kacheln mit Kennzahlen

In vielen Teams entstehen User Stories primär aus der Perspektive: Was soll gebaut werden?

Das führt dazu, dass Lösungen bereits in der Story „eingebaut“ sind – der Entwickler wird zum Umsetzer, nicht zum Mitdenker.

Ein anderer Weg: Stories, die beschreiben, was der Nutzer erreichen möchte – und warum. Nicht wie.

Das verändert den Fokus:

vom Feature zur Wirkung
von der Umsetzung zum Ziel
vom Briefing zur gemeinsamen Lösung

Häufige Einwände – und warum sie sich auflösen

Links Entwürfe mit Fragezeichen daneben, rechts hinter einem Pfeil die Folge aus Nutzer, Zielscheibe, drei Schritten und Haken mit steigender Kurve

Viele Product Owner befürchten, dass ihr Team damit überfordert ist.

Kein Produktverständnis. Zu wenig Erfahrung. Keine Zeit zum Nachdenken.

Die gute Nachricht: Es funktioniert trotzdem – wenn man den Übergang richtig gestaltet.

Was hilft:

Klare Beschreibung des Nutzungsziels
Konkrete, überprüfbare Kriterien für Erfolg (aus Nutzersicht!)
Ein schrittweiser Übergang – z. B. bei kleineren Stories oder in Parallelfassung zur alten Methode
Zusätzlicher Kontext im Refinement, nicht im Ticket

Der Effekt:

Das Team stellt andere Fragen. Es versteht den Zweck hinter der Story.

Es entwickelt Eigenverantwortung – und bessere Lösungen.

Aber was ist mit Teams, die noch nicht so weit sind?

Zwei aus dem Team stehen selbst am Board und zeichnen, während er mit den Händen in den Taschen danebensteht; oben die Kette aus Nutzer, Warnzeichen, Sprechblase mit Rückkopplung und Stern

Natürlich braucht es Zeit. Besonders bei Entwickler:innen, die neu im Produkt sind oder wenig Nutzereinblick haben. Aber genau dieser Ansatz kann helfen, das Verständnis aufzubauen – durch echte Auseinandersetzung mit dem „Warum“ hinter einer Story.

Statt blind Anforderungen umzusetzen, beginnen die Entwickler, Muster zu erkennen, Vorschläge zu machen, Risiken früh zu adressieren.

Langfristig ist das nicht nur effizienter – es macht die Arbeit im Team auch sinnvoller.

Fazit: Die Perspektive zählt

Eine Kette am Whiteboard: eine Gruppe unter der Lupe, ein Puzzleteil mit Fragezeichen, eine steigende Kurve mit Haken und am Ende eine Gruppe im Lichtkreis - darunter führt ein gestrichelter Weg über Idee, Entwurf, Umsetzung und Rückmeldung zurück

Wer möchte, dass sein Team Verantwortung übernimmt, muss dafür auch den Raum schaffen.

Nicht durch bessere Spezifikationen, sondern durch bessere Orientierung:

Wen wollen wir damit unterstützen?
Welches Problem lösen wir?
Woran merken wir, dass es funktioniert?

Wenn Product Owner sich trauen, diese Fragen ins Zentrum zu stellen, beginnt sich etwas zu verändern:

Weg von „Abarbeiten“. Hin zu echter Produktentwicklung.