Für Product Owner ohne Luft zum Atmen
Du kannst dich nie darauf verlassen, dass dein Team ohne dich liefert.
Jedes brauchbare Ergebnis kostet dich Zeit und Nähe zum Team. Am Ende bleibt zu wenig davon für die Dinge, die wirklich wichtig sind.
Erstgespräch vereinbarenKein Verkaufsgespräch. Passt es nicht, sage ich das genauso offen wie du.
Kommt dir das bekannt vor?
- Sprint für Sprint wirkt das Team produktiv. Am Ende des Quartals sind die wirklich wichtigen Ziele trotzdem keinen Schritt näher.
- Du erklärst dieselbe Anforderung zum dritten Mal — und bekommst trotzdem nicht das, was du eigentlich brauchst.
- Im Daily Scrum heißt es „läuft“. Fragt dich zehn Minuten später ein Stakeholder nach dem Releasetermin, hast du trotzdem keine Antwort.
Was sich verändert
Wie schaffst du das?
Sechs Dinge verschieben sich, wenn dein Team anders priorisiert — messbar und im Alltag spürbar.
- Schätzverfahren — du schätzt endlich das, was du wirklich schätzen willst.
- Velocity — sie wird verlässlich statt beschönigend.
- Bugs nach Release — sie werden weniger, weil das Team versteht, was es baut.
- Support-Tickets — sie sinken, weil weniger an den Nutzern vorbei gebaut wird.
- Refactoring-Aufwand — er sinkt, weil weniger korrigiert werden muss.
- Team-Fluktuation — gute Entwickler bleiben lieber.
Entwickler verstehen tiefer, was sie eigentlich bauen — gerade jetzt entscheidend, wo KI-Tools diesen Effekt sonst weiter verschärfen. Der Arbeitsalltag wird weniger nüchtern und ermüdend — gute Entwickler bleiben lieber, auch ohne enorme Gehaltserhöhung.
Bisher hast du im Grunde deine Zeit geschätzt — sogar wenn du eigentlich Komplexität geschätzt hast. Kein Wunder, dass du dabei regelmäßig falsch liegst: Schon Nobelpreisträger Daniel Kahneman hat das mit der Planning Fallacy belegt. Also müssen wir hier anders schätzen.
Warum ich das gebaut habe
- Ich habe in großen Konzernprojekten erlebt, wie zu wenig Empathie für die Nutzer zu Bugs und ausuferndem Refactoring führt.
- Ich habe gesehen, wie viel Zeit endloses Korrigieren, Nachbessern und umständliche Arbeitsanweisungen kosten, wenn Entwickler nicht verstehen, was du wirklich willst.
- Ich war selbst in einem Team mit unzufriedenen Entwicklern und habe unter der Fluktuation gelitten, die daraus entstanden ist — bis ich ging.
Wie das Coaching abläuft
Acht Wochen, mit deinem echten Team
-
1
Kickoff im FlightRoom
Den Auftakt macht ein entspanntes Kickoff-Meeting als Team-Event namens FlightRoom — das zeigt schon eine Menge über dein Team.
-
2
Acht Wochen Begleitung
Acht Wochen lang begleite ich dich persönlich. Du bekommst ergänzende Videos, die dir das Wichtigste erklären — zeitlich flexibel, du teilst dir das selbst ein.
-
3
Regelmäßige Coaching Calls
Dazu regelmäßige Coaching Calls, in denen du alle deine Fragen stellst. Wir arbeiten praktisch, direkt mit deinem echten Team.
Bitte hab Geduld — Veränderung braucht Zeit.
Voraussetzung: Du solltest bereits Erfahrung mit User Stories oder Job Stories haben — das erfüllen die meisten Teams bereits. Schreib mir, falls nicht!
Möchtest du dir vorab ein Bild machen? Ich habe eines der Videos aus dem Coaching öffentlich gemacht, damit du siehst, wie ich arbeite und was dich erwartet.
Stimmen
Was andere sagen
»Viele vermeintlich innovative Ideen sind nur kosmetisch — als zertifizierter Product Owner habe ich bereits eine Menge Unsinn gesehen.«
»Als Unternehmer bin ich jetzt noch mehr daran interessiert, die Weichen zu stellen, dass ein Entwicklerteam auch ohne mich funktioniert.«
»Es verändert reale Entscheidungen im Sprint — nicht nur das Gespräch darüber.«
Was gleich bleibt
Verändert wird nicht, wonach agile Teams arbeiten — sondern, wie priorisiert wird. Kein neues Framework von Grund auf, sondern eine veränderte Praxis innerhalb der bestehenden Grundprinzipien.
Das hat nichts mit LEGO Serious Play oder klassischen Auflockerungsspielen für Meetings zu tun. Es verändert reale Entscheidungen im Sprint — nicht nur das Gespräch darüber.
Woher das kommt
Die Anfänge waren mit meinem eigenen Team — weil ich genau die gleichen Probleme hatte. Als Unternehmer wollte ich sechs Wochen mit meiner Familie in den Urlaub fahren, traute mich aber nicht. Also habe ich angefangen zu experimentieren.
Aber dann habe ich wie ein Irrer gelernt und noch mehr experimentiert — bis daraus ein Produkt wurde, das ich wirklich gerne vertreibe.
Wenn ich das über Bord werfe, verkommt meine Methode zu einem Massengut, das genauso halbherzig in der Praxis umgesetzt wird, wie es Scrum oft getan wird. Das würde allen Beteiligten mehr schaden als nützen.
Du kannst mit meiner Methode ein Team erhalten, das allein aufgrund des Teams einen Wert hätte, herausgekauft zu werden — ein sogenannter EquiHire. Ich weiß das, weil mein Team genau deshalb jetzt bei einem ehemaligen Kunden sitzt.
Nächster Schritt
Du willst Erfolge, die in deinem Lebenslauf zählen.
Das Material dafür sind die Ergebnisse deines Teams — sie bestimmen, was du daraus machen kannst. Erfolge entstehen nicht über Nacht: Je früher du anfängst, desto besser.
Jetzt Erstgespräch vereinbarenKein Verkaufsgespräch. Wenn es nach dem Gespräch nicht passt, sage ich das genauso offen wie du.