Product Discovery – ein ergebnisoffener Deep Dive (Teil 1)

Agiles, innovatives und nutzerzentriertes Arbeiten im heutigen Unternehmen ist längst kein optionaler Zusatz mehr, sondern eine Selbstverständlichkeit.

Mit Methoden wie den Design Sprints ist es auch für Neulinge unter Anleitung leicht, in 4-5 Tagen zu Innovationen und testbaren Prototypen zu gelangen. Die Prämisse dafür ist jedoch, dass sich das gesamte Team für diese Tage von ca. 10-17 Uhr dem Design Sprint verschreibt – ohne Handy, ohne Laptop, ohne Zwischenmeetings.

Doch was, wenn das Team zwar gewillt ist, aber bei dem aktuellen Pensum durch das Tagesgeschäft unmöglich 4-5 volle Arbeitstage fehlen kann? Dann könnte die Einführung einer Product Discovery zum gewünschten Ziel führen.

Was ist die Product Discovery?

Die Product Discovery bezeichnet einen ergebnisoffenen Deep Dive mit dem gesamten Team in ein neues Themengebiet oder ein Themengebiet, das auf sein Potenzial hin untersucht werden soll – bevor es vollständig entwickelt wird und Änderungen daran sehr kostspielig werden. Denn weniger die Entwicklung selbst, sondern die Identifikation eines (für den Nutzer!) relevanten Problems oder Bedürfnis ist die Herausforderung.

Und der Unterschied zu Design Sprints?

Der Design Sprint hält festgesetzte Bausteine mit festgesetzten Methoden und Zeitplänen für jeden Tag bereit. Die Product Discovery hat zwar Bausteine mit ähnlichen Inhalten (Evaluation des Status Quos, Ideation, Prototyping und Testing), doch der Unterschied zum Design Sprint liegt im Vorgehen. Bei der Product Discovery gibt es keine vorgegebene Agenda, keine festgesetzten Methoden und selbst die Länge eines Sprints ist flexibel. Auch hier wird also „gesprintet“, aber im eigenen Tempo des Teams. So können Sprints auch mehrere Wochen dauern, wenn die Teammitglieder nur wenige Stunden am Tag entbehren können. Das Tagesgeschäft bleibt somit nicht auf der Strecke und die Mitarbeiter haben trotzdem die Möglichkeit die Product Roadmap agil im Team abzuarbeiten.

Im Design Sprint wird außerdem eine konkrete Idee entwickelt und getestet – durch die Intensivität ist es schwierig bis unmöglich jede Woche einen Sprint zu absolvieren. Die Product Discovery hingegen bietet ein flexibles Framework um kontinuierlich innovative Ansätze zu entwickeln.

Was ist das Ziel der Product Discovery?

Ziel einer Product Discovery ist es die laut Marty Cagan (Inspired, 2008) wichtigsten Fragen an ein neues Produkt zu beantworten:

1) Kauft oder nutzt der Nutzer das Produkt (valuable)?
2) Versteht der Nutzer, wie das Produkt funktioniert (useable)?
3) Können wir das Produkt bauen (feasible)?

In erster Linie hat man also den Nutzer und nicht die technischen (Un-)möglichkeiten im Hinterkopf – wobei diese auch nicht ganz außer Acht gelassen werden. Außerdem werden Ideen in einem sehr frühen Stadium mit Nutzern getestet, um die Spreu vom Weizen zu dem Zeitpunkt zu trennen, zu dem Änderungen noch sehr schnell und günstig gemacht werden können.

Was ist eine Dual Track Discovery?

Das Zusammenspiel zwischen den Entwicklern und den UX-/Usability- Designern/Product Designer/PMs wird Dual-Track genannt.

Dabei ist die Product Discovery (geleitet durch UUX-Experten) das nutzungszentrierte Gegenstück zur Product Delivery, der Umsetzung einer Idee oder eines Produktes durch Entwickler (oft in Scrum-Zyklen). Product Discovery bestimmt also das WAS, Product Delivery das WIE. Produzierende Unternehmen haben zwangsläufig eine Entwicklungsfachabteilung, die sich schon oft in Scrum-Sprints, Kanban oder ähnlichen Methoden organisiert hat. Doch dabei steht eher die technische (Un-)Möglichkeit im Vordergrund und weniger die Interessen und Bedürfnisse der Nutzer. Mit einer Product Discovery kann eine schon vorhandene Idee mit Nutzern auf ihr Potenzial hin untersucht, oder ganz neue – für den Nutzer relevante – Ideen entdeckt werden. Diese können dann – nach prototypischem Testing – in die Entwicklung gegeben werden. Aber auch aus der Entwicklung können aufgekommene Fragen wiederum in die Product Discovery zurückgespielt und dort im nächsten Sprint bearbeitet werden (die sogenannte Continuous Discovery im Gegensatz zu einer einmaligen Discovery mit anschließender Delivery, die nie wieder iterativ getestet wird).

Diese Vorgehensweise bewahrt das Unternehmen davor, Produkte zu entwickeln, bei denen man erst nach Fertigstellung merkt, dass sie nicht auf die Nutzerbedürfnisse abgestimmt sind. Dadurch wird Geld und Zeit gespart – denn um einen Prototyp zu verändern, benötigt man wenige Minuten; ein fertiges Produkt zu verändern dauert hingegen mehrere Tage oder Wochen.

Was bei der Durchführung außerdem noch beachtet werden sollte, lesen Sie in meinem 2. Teil „Product Discovery – Erfahrungsbericht einer Moderatorin„.