Wenn Sie als Produktmanager an Sprint-Retrospektiven teilnehmen, ist Ihnen wahrscheinlich etwas aufgefallen: Das Gespräch konzentriert sich auf den Entwicklungsprozess. Wie war der Sprint geplant? Haben wir gut geschätzt? Gab es Blocker? Was können wir an unserem Arbeitsablauf verbessern?
Das sind berechtigte Fragen. Aber sie übersehen etwas Grundlegendes für Ihre Rolle: Bauen wir die richtigen Dinge auf?
Sprint-Retros optimieren die Lieferung. Produkt-Retros optimieren den Lern- und Mehrwert. Sie benötigen beides, und als PM sind Sie wahrscheinlich derjenige, der die produktorientierte Version umsetzen muss.
Was ein Retro-Produkt anders macht
Bei einem Standard-Sprint-Retro geht es um die Ausführung. Bei einem Produkt-Retro geht es um Ergebnisse. Der Unterschied ist subtil, aber wichtig.
Bei einem umsetzungsorientierten Retro-Prozess lautet die Frage: „Haben wir das geliefert, wozu wir uns verpflichtet hatten, und wie war der Prozess?“ In einer ergebnisorientierten Retro-Studie lautet die Frage: „Hat das, was wir geliefert haben, den erwarteten Wert geschaffen, und was haben wir gelernt?“
Als PM sind Sie in der einzigartigen Position, diese beiden Perspektiven zu verbinden. Sie sehen die Kundenbedürfnisse, die strategische Ausrichtung, die technischen Kompromisse und die Marktreaktion. Bei einer Produkt-Retro fassen Sie all das zusammen, um zu lernen, worauf Ihr Team reagieren kann.
Hier ist, was ein Produkt-Retro untersucht, was ein Sprint-Retro normalerweise nicht tut:
- Ob die von Ihnen gelieferten Funktionen die für Sie wichtigen Messwerte verändert haben
- Was Sie über Kunden erfahren haben, die Ihre Pläne ändern sollten
- Ob Ihre Wetten und Hypothesen bestätigt oder ungültig wurden
- Wie gut Produkt, Technik, Design und andere Funktionen bei Entscheidungen zusammengearbeitet haben (nicht nur bei den Ergebnissen)
- Ob Ihre Roadmap angesichts Ihres jetzigen Wissens noch Sinn macht
Fünf Formate, die tatsächlich funktionieren
Unterschiedliche Situationen erfordern unterschiedliche Herangehensweisen. Hier sind fünf Formate, die jeweils für einen anderen Kontext geeignet sind. Verwenden Sie nicht jedes Mal die gleiche Standardeinstellung.
1. Entdeckung/Erstellung/Start
Am besten geeignet für: Teams, die in längeren Zyklen arbeiten oder gerade eine wichtige Initiative abgeschlossen haben.
Teilen Sie die Retro in drei Phasen des Produktlebenszyklus ein:
- Entdeckung: Haben wir das Problem gut genug verstanden, bevor wir uns auf eine Lösung festgelegt haben? Gab es Signale, die wir übersehen oder ignoriert haben? Haben wir ausreichend mit den richtigen Kunden gesprochen?
- Build: Hat die von uns erstellte Lösung tatsächlich das von uns identifizierte Problem behoben? Wo haben sich die Ausweitung des Umfangs oder technische Einschränkungen auf das ausgewirkt, was wir geliefert haben, im Vergleich zu dem, was wir beabsichtigt hatten?
- Launch: Hat der Launch das richtige Publikum erreicht? Entsprach die Adoption den Erwartungen? Was hat uns an der Reaktion der Kunden überrascht?
Dieses Format funktioniert, weil es das Team dazu zwingt, die gesamte Reise zu bewerten, nicht nur die letzte Meile.
2. Kunde / Team / Unternehmen
Am besten geeignet für: Funktionsübergreifende Teams, in denen Produkt, Technik, Design, Marketing und Support aufeinander abgestimmt werden müssen.
Drei Objektive im gleichen Zeitraum:
- Kunde: Was haben wir über unsere Kunden erfahren? Haben wir echte Probleme gelöst oder angenommene? Welches Feedback hören wir nach der Veröffentlichung?
- Team: Wie gut haben wir funktionsübergreifend zusammengearbeitet? Waren die richtigen Leute zur richtigen Zeit beteiligt? Wo scheiterten die Übergaben?
- Geschäft: Hat diese Arbeit zu unseren Geschäftszielen beigetragen? Sind wir mit den Maßstäben, zu denen wir uns verpflichtet haben, auf dem richtigen Weg? Wie sieht der ROI aus?
Dieses Format ist nützlich, wenn ein Spannungsverhältnis zwischen den Wünschen der Kunden, den Leistungen des Teams und den Anforderungen des Unternehmens besteht. Es ist gesünder, die Spannung deutlich zu machen, als sie köcheln zu lassen.
3. Hypothese / Experiment / Lernen
Am besten geeignet für: Wachstumsorientierte Teams, Produkte im Frühstadium oder Teams, die viel experimentieren.
Strukturieren Sie die Retro rund um Ihre Lernschleife:
- Hypothese: Woran haben wir zu Beginn dieses Zyklus geglaubt? Wurden unsere Hypothesen klar dargelegt oder basierten wir auf Annahmen, die wir nie artikuliert hatten?
- Experiment: Was haben wir getan, um diese Hypothesen zu testen? War das der schnellste Weg zum Lernen, oder haben wir vor der Validierung zu viel aufgebaut?
- Lernen: Was wissen wir jetzt, was wir vorher nicht wussten? Wie sollte dies unsere Pläne ändern? Welche neuen Hypothesen sollten wir aufstellen?
Dieses Format ist bewusst unbequem. Es erfordert, zuzugeben, was man nicht weiß und was man falsch gemacht hat. Das ist der Punkt.
4. Was wurde versendet / Was wir gelernt haben / Was kommt als nächstes?
Am besten geeignet für: Continuous-Delivery-Teams, die häufig versenden und ein schnelles, leichtes Format benötigen.
Drei Kolonnen, schnelle Pässe:
- Versand: Was ist aus der Tür gegangen? War es das, was wir geplant hatten, oder haben sich die Prioritäten verschoben?
- Gelernt: Was sagen uns Nutzungsdaten, Kundenfeedback und Teamerfahrung? Irgendwelche Überraschungen?
- Weiter: Was sollten wir basierend auf dem, was wir gelernt haben, als nächstes priorisieren? Muss sich an der Roadmap etwas ändern?
Dies ist das pragmatischste Format. Es sorgt dafür, dass das Gespräch auf aktuellen Arbeiten basiert und zukunftsorientiert ist. Gut für Teams, die alle zwei Wochen ein Retro-Release durchführen und keine Stunde mit Reflektion verbringen möchten.
5. Starten / Stoppen / Fortfahren (Product Decisions Edition)
Am besten geeignet für: Teams, die harte Priorisierungsanrufe tätigen müssen.
Das klassische Starten/Stoppen/Fortfahren, aber speziell auf Produktentscheidungen und nicht auf Prozesse angewendet:
- Start: In was sollten wir investieren, was wir derzeit ignorieren? Auf welche Kundenbedürfnisse oder Marktsignale reagieren wir nicht?
- Stop: Womit sollten wir aufhören, auch wenn wir bereits Zeit darin investiert haben? Welche Wetten zahlen sich nicht aus? Welche Funktionen pflegen wir, die niemand nutzt?
- Weiter: Was funktioniert und verdient mehr Investition? Wo sehen wir Traktion?
Die Spalte „Stopp“ ist der schwierigste und wertvollste Teil. PMs hat selten ein Forum, in dem man sagen kann: „Wir sollten das abschaffen“ – dieses Format gibt ihnen eines.
Produktspezifische Fragen, die Sie stellen sollten
Führen Sie unabhängig vom Format eine Liste der Fragen, die Sie abwechselnd durchgehen. Nicht immer alle – wählen Sie zwei oder drei aus, die für den aktuellen Zyklus relevant erscheinen.
Zum Kundennutzen:
- Wenn wir in diesem Sprint nichts verschickt hätten, was hätten die Kunden verpasst?
- Hören wir von den Funktionen, die wir eingeführt haben, oder herrscht Stille?
- Wie groß ist die Lücke zwischen dem, was wir gebaut haben, und dem, was die Kunden tatsächlich brauchten?
Zur strategischen Ausrichtung:
- Bringt uns die Arbeit, die wir gerade abgeschlossen haben, unseren Quartalszielen näher?
- Verbringen wir Zeit mit dringender Arbeit, die strategisch irrelevant ist?
- Wenn ein Wettbewerber unsere Ergebnisse im letzten Monat sehen würde, welche Schlussfolgerungen würde er über unsere Strategie ziehen?
Zur Lerngeschwindigkeit:
- Was haben wir in diesem Zyklus gelernt, was wir im letzten Zyklus nicht hätten lernen können?
- Wo haben wir zu lange auf Feedback gewartet?
- Welche Annahme erwies sich als falsch und wie haben wir reagiert?
Über funktionsübergreifende Gesundheit:
- Hatte das Design früh genug das, was es brauchte?
- Gab es Entscheidungen, die technischen Input erforderten, diesen aber erst zu spät trafen?
- Sehen Support und Vertrieb Dinge, von denen wir nichts hören?
Maßnahmen haften lassen
Die größte Fehlerquelle bei Produktretros besteht darin, Erkenntnisse zu gewinnen, die zu nichts führen. Sie verlassen das Meeting voller Energie und zwei Wochen später hat sich nichts geändert.
Die Lösung liegt in der Spezifität. Vergleichen Sie diese:
Vage: „Wir müssen mehr mit Kunden sprechen.“
Spezifisch: „Bevor wir die Neugestaltung der Benachrichtigungen spezifizieren, führt [PM-Name] fünf Kundeninterviews mit Schwerpunkt auf Benachrichtigungspräferenzen durch. Die Interviews sind bis zum 14. März abgeschlossen.“
Vage: „Wir sollten stärker datengesteuert sein.“
Spezifisch: „Wir definieren Erfolgsmetriken für jedes Feature, bevor die Entwicklung beginnt, und überprüfen sie im Retro-Stil zwei Wochen nach dem Start.“
Vage: „Die funktionsübergreifende Kommunikation muss verbessert werden.“
Spezifisch: „Design wird Wireframes im #Produktkanal mindestens drei Tage vor der Sprintplanung für Feedback freigeben. Beginn des nächsten Sprints.“
Jeder Maßnahme sollte einen Eigentümer, eine zu erbringende Leistung und ein Datum haben. Überprüfen Sie zu Beginn jeder neuen Retro die Maßnahmen der vorherigen Retro. Wenn derselbe Maßnahme zweimal ohne Fortschritt angezeigt wird, ist das ein Zeichen dafür, dass er entweder weiter aufgeschlüsselt werden muss oder dass er eigentlich keine Priorität hat.
Timing und Trittfrequenz
Alle zwei Wochen ist für die meisten Produktteams ein guter Standard. Es orientiert sich an gängigen Sprintlängen und bietet genügend verstrichene Zeit, damit neue Daten und Kundenreaktionen entstehen.
Monatlich funktioniert besser für Teams, die längere Entdeckungszyklen durchführen, oder wenn der PM mehrere Teams überwacht und realistischerweise nicht alle zweiwöchigen Retros mit jedem einzelnen durchführen kann.
Nach wichtigen Meilensteinen – ein großer Start, ein Pivot, ein gescheitertes Experiment – rechtfertigt eine spezielle Retro, unabhängig von Ihrer regulären Kadenz. Diese sind in der Regel länger (60 bis 90 Minuten) und strategischer.
Halten Sie Ihre reguläre Trittfrequenz im Retro-Stil bei 45 bis 60 Minuten. Wenn Sie die Zeit ständig überschreiten, decken Sie entweder zu viel Umfang ab oder messen die Zeit nicht effektiv.
Anti-Patterns, auf die Sie achten sollten
Das „Alles ist in Ordnung“-Retro. Wenn bei Ihren Retros nie Probleme auftauchen, stimmt etwas nicht. Entweder fühlen sich die Leute nicht sicher, kritisch zu sein, oder Sie stellen nicht gezielt genug Fragen. Versuchen Sie es mit der anonymen Eingabeerfassung, um ehrlicheres Feedback zu erhalten.
Der PM-Monolog. Wenn der PM den Großteil des Gesprächs übernimmt, wird die Retro zu einem Status-Update und nicht zu einer Lernsitzung. Ihre Aufgabe ist es, zu moderieren, nicht zu präsentieren. Stellen Sie Fragen und lassen Sie andere den Raum füllen.
Die Schuldzuweisungssitzung. Bei Retros sollte es um Systeme und Prozesse gehen, nicht um Einzelpersonen. Wenn die Konversation in Richtung „Der und der hat
Die „Das nächste Mal reparieren wir“-Schleife. Wenn Sie immer wieder die gleichen Probleme identifizieren, ohne sie zu lösen, erzeugt der Retro eher Zynismus als Verbesserung. Eskalieren Sie wiederkehrende Probleme an jedes Forum, das sie tatsächlich lösen kann – Skip-Levels, Planungsbesprechungen oder Architekturüberprüfungen.
Erste Schritte
Wenn Sie ein PM sind und noch nie eine produktspezifische Retro durchgeführt haben, ist dies der einfachste Weg, damit anzufangen: Fügen Sie am Ende Ihrer nächsten Sprint-Retro 15 Minuten hinzu und stellen Sie eine Frage:
„Wenn wir uns ansehen, was wir in diesem Sprint geliefert haben, welchen Beweis haben wir dafür, dass es für die Kunden von Bedeutung war?“
Allein diese Frage wird das Gespräch vom Output auf die Ergebnisse verlagern. Wenn das Team diese Frage für wertvoll hält – und das wird es mit ziemlicher Sicherheit auch –, haben Sie die Möglichkeit, ein spezielles Retro-Produkt vorzuschlagen.
Beim Produktmanagement geht es grundsätzlich darum, schneller zu lernen als die Konkurrenz. Ein reguläres Produkt-Retro ist die Praxis, die das Lernen systematisch und nicht zufällig macht.
Probieren Sie NextRetro kostenlos aus – Wählen Sie aus über 17 retrospektiven Vorlagen für Produktteams mit integrierter Abstimmung und Phasenverwaltung, um die Diskussionen fokussiert zu halten.
Letzte Aktualisierung: Februar 2026
Lesezeit: 8 Minuten
