Product Discovery und Scrum

Worum es geht

Die Situation ist in vielen agilen Teams ähnlich: Man hat Scrum eingeführt, die Sprints laufen, das Team wird schneller. Doch das Ergebnis ist oft frustrierend. Es wird effizient gearbeitet, aber der erhoffte Produkterfolg oder die Nutzerbegeisterung bleiben aus.

Das Problem ist nur: Scrum allein adressiert nicht die fundamentale Frage, ob man das Richtige baut. Es optimiert das Wie der Entwicklung. Teams folgen oft dem Product Owner und dem Backlog, ohne die zugrundeliegenden Annahmen zu hinterfragen. Das Backlog wird zur To-Do-Liste, deren Wertgehalt nicht validiert ist.

Die zentrale Frage dieser Episode lautet daher: Wie können Scrum-Teams den Schritt vom bloßen Abarbeiten von Anforderungen hin zu einer wertorientierten, nutzerzentrierten Produktentwicklung schaffen? Die Antwort liegt in der Integration von Product Discovery.

Für wen?

Episoden-Insights

1. Delivery ohne Discovery ist organisierter Blindflug

Scrum ist exzellent für die Delivery – also die Umsetzung und Auslieferung von Inkrementen. Es bietet jedoch keine Werkzeuge oder Rituale, um zu validieren, ob diese Inkremente auch ein echtes Nutzerproblem lösen. Ein Team kann also perfekt nach Scrum arbeiten und dennoch ein Produkt bauen, das niemand will. Was ich konsistent beobachte ist, dass Teams dann in einen Zyklus aus "Build, Release, (Keine) Reaktion" geraten, anstatt in einen Lernzyklus.

2. Das Backlog ist eine Hypothese, kein Fakt

Ein Product Backlog Item ist in seiner ursprünglichen Form oft nichts weiter als eine ungeprüfte Annahme. "Wenn wir Feature X bauen, dann werden Nutzer Y tun und dadurch entsteht Z Wert." Ohne Discovery wird diese Annahme nie hinterfragt oder getestet. Das Team arbeitet dann an der Lösung, ohne das Problem wirklich verstanden zu haben. Die Rolle des Product Owners muss sich dahingehend entwickeln, diese Hypothesen explizit zu machen und durch Research und Experimente zu validieren, bevor sie als detaillierte Aufgaben im Sprint landen.

3. Product Thinking erfordert eine Erweiterung des Scrum-Modells

Um erfolgreich zu sein, muss das klassische Scrum-Modell um eine Discovery-Schleife erweitert werden. Bevor ein Item in die Sprint-Planung geht, sollte es eine Phase der Problem- und Lösungsvalidierung durchlaufen haben. Das bedeutet nicht, dass das gesamte Team ständig in Discovery-Aktivitäten eingebunden ist, sondern dass die Ergebnisse und das daraus gewonnene Nutzerverständnis kontinuierlich in die Arbeit des Teams einfließen. So wird aus einem ausführenden Team ein mitdenkendes, wertorientiertes Produktteam.

Dein nächster Schritt

Versteh mich nicht falsch – Scrum ist ein starkes Framework. Aber ohne den Blick auf den Nutzer und die Validierung deiner Annahmen bleibt ein Großteil des Potenzials ungenutzt. Wenn du als Product Owner oder Product Manager lernen willst, wie du Discovery systematisch in deine Arbeit integrierst, dann lass uns darüber sprechen.