Gesprächsrunde
💬 Teilnehmer dieser Episode
Product Expert 1
Head of Product
UX Researcher
Senior UX Researcher
Product Coach
Product Discovery Coach
Highlights aus dem Gespräch
Die wichtigsten Fragen und Antworten der Teilnehmer:
Wie integriert man Product Discovery sinnvoll in Scrum?
Product Discovery sollte dem Delivery vorausgehen, aber nicht getrennt davon stattfinden. Idealerweise hat ein Team Capacity für beides: Ein Teil des Sprints für Discovery (Research, Prototyping, Testing), der Rest für Delivery. Wichtig ist die enge Verzahnung – Learnings aus Discovery fließen direkt in die nächsten Sprints ein.
Ein häufiger Fehler ist, Discovery als separate Phase zu sehen. Besser ist ein kontinuierlicher Discovery-Prozess parallel zur Entwicklung. Das bedeutet: Immer etwas im Backlog haben, das bereits validiert ist, während man das nächste validiert. So vermeidet man Leerlauf und baut auf gesicherten Erkenntnissen.
Welche Methoden haben sich in der Praxis bewährt?
Kundeninterviews und Usability-Testing sind unverzichtbar. Aber entscheidend ist die richtige Fragestellung: Nicht 'Gefällt dir das Feature?', sondern 'Welches Problem löst das für dich?' und 'Wie löst du es heute?' Contextual Inquiry – Kunden in ihrer natürlichen Umgebung beobachten – liefert die wertvollsten Insights.
Assumption Mapping und Risiko-Priorisierung helfen, die richtigen Fragen zu stellen. Bevor man viel baut, sollte man die riskantesten Annahmen testen. Rapid Prototyping mit Tools wie Figma ermöglicht schnelles Testen ohne teure Entwicklung. Wichtig ist, früh und oft zu testen, nicht perfekt.
Das Wichtigste in Kürze
- Scrum ist ein Framework für die Lieferung (Delivery), aber nicht für die Entdeckung (Discovery) der richtigen Produktideen.
- Teams riskieren, effizient die falschen Dinge zu bauen, wenn sie ein Backlog ohne fundiertes Nutzerverständnis abarbeiten.
- Product Discovery ist kein optionaler Luxus, sondern eine notwendige Praxis, um Wertversprechen zu validieren und Fehlinvestitionen zu vermeiden.
- Die Rolle des Product Owners transformiert sich vom Backlog-Verwalter zum Entdecker, der Hypothesen formuliert und testet.
- Echte Agilität bedeutet, nicht nur schnell zu entwickeln, sondern auch schnell zu lernen, was für den Nutzer wirklich wertvoll ist.
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?
Für wen?
Diese Episode spricht alle an, die im oder mit einem Scrum-Team arbeiten und das Gefühl haben, dass trotz korrekter Prozesse der echte Impact ausbleibt.
Besonders wertvoll, wenn du:
- Als Product Owner das Gefühl hast, dein Backlog basiert mehr auf Vermutungen und Stakeholder-Wünschen als auf validierten Nutzerbedürfnissen.
- Als Developer oder Scrum Master im Team zwar die Prozesse laufen, ihr aber selten Rückmeldung zu dem Wert eurer Arbeit bekommt.
- In einer Führungsrolle bist und beobachtest, dass viele Entwicklungsressourcen in Features fließen, die keine messbare Wirkung entfalten.
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.
Product Discovery in deinem Team etablieren
In einem strategischen Gespräch analysieren wir, wo in eurem Prozess Lernen und Validierung fehlen und entwickeln einen pragmatischen Einstieg in die Product Discovery.
Termin für Strategiegespräch vereinbaren →Ressourcen
Weitere Ressourcen aus dem Netz
Externe Links zu weiterführenden Inhalten, die im Kontext dieser Episode hilfreich sein können.
Live zu diesem Thema
Vertiefe dieses Podcast-Thema in unseren Live-Webinaren und Trainings:
Die besten Tipps zu Scrum und Agilität
- Wo macht eine agile Arbeitsweise Sinn? Wo nicht?
- Was zeichnet Scrum im Kern aus?
- Wie gestalte ich Scrum effektiv aus?
- Wie arbeite ich in meiner Organisation agil?
Passende Scrum-Seiten
Weiterführende Themen & Ressourcen
#118: Product Owner Team
Product-Owner-Teams scheitern oft an gemeinsamer Ausrichtung. Erfahre die 3 No-Gos, 6 Herausforderungen & wie du das Team als echte Einheit organisierst.
146: Product Ownership
Scrum Master sind frustriert, weil sie mit einem schwachen Product Owner nicht effektiv arbeiten können. Erfahre, warum gute Product Ownership der Schlüssel für den Scrum-Erfolg ist.
#102: 7 Enabler damit Scrum Innovation fördert
Scrum als Innovationskiller? Ein verbreitetes Vorurteil. Erfahre, wie du mit 7 konkreten Enablern Scrum als Lernrahmen nutzt, um echte Produktinnovation zu ermöglichen.