Wie viel Product Discovery ist genug?
Das Thema Discovery ist gerade aktuell im Bereich der Produktentwicklung in aller Munde. Die Zeiten, in denen Discovery häufig zu kurz kam, gehören der Vergangenheit an. Warum heutzutage manchmal zu viel Zeit im Problemraum verbracht wird und welche Daumenregeln dir wirklich helfen, deine Kund:innen
Das Thema Discovery ist gerade aktuell im Bereich der Produktentwicklung in aller Munde. Die Zeiten, in denen Discovery häufig zu kurz kam, gehören der Vergangenheit an (Ja, nicht überall). Warum heutzutage manchmal zu viel Zeit im Problemraum verbracht wird und welche Daumenregeln dir wirklich helfen, deine Kund:innen besser zu verstehen, finden wir heute gemeinsam heraus.
Das sagen Expert:innen zu Product Discovery
Alberto Savoia
(Erfinder des Pretotypings und ehem. Product Manager bei Google)
„You need to design and run a bare minimum of three to five experiments.“
Teresa Torres
(International anerkannte Autorin, Speakerin und Coachin)
„If you're still wondering how much time you should spend in Discovery, the answer is: As much as you can every week.“
Die Zitate spiegeln wider, aus welchen Bereichen die Expert:innen kommen. Alberto Saboia kommt seinerseits aus der Neuproduktentwicklung. Teresa Torres spricht wiederum eher aus dem Umfeld der Bestandsprodukte, in dem es in der Praxis häufig zu wenig Raum für Discovery gibt.
Beide Zitate treffen nicht ganz, was Thomas zu Discovery denkt. Laut ihm solltest du so viel Zeit mit Discovery verbringen, bis du die Kund:innen verstanden hast. Du bist bereit, wenn du den kausalen Zusammenhang zwischen der gewollten Interaktion und dem Grund für diese verstehst.
Das Problem: Zu viel oder zu wenig Discovery
Lange Zeit wurde in Organisationen viel zu wenig Discovery betrieben. Im schlimmsten Fall bedeutete dies für das Entwicklungsteam zwei Jahre Entwicklung für etwas, das am Ende nicht funktionierte und dann mühsam umgebaut werden musste.
Sebastian beobachtet heute immer häufiger, dass aufgrund der Vergangenheit aktuell sehr viel Discovery betrieben wird. Ein Maß oder eine Grenze für zu viel Discovery fehlt. Das führt dazu, dass manche Teams eher in Richtung Overdiscovery abzudriften scheinen.
Beide Szenarien stellen eine Verschwendung dar: Zum einen auf der Seite der Entwicklungsressourcen, da das Team umsonst etwas entwickelt hat. Zum anderen auf der Seite der UX-Ressourcen. Beides verfehlt das Ziel, Kund:innen möglichst schnell zu verstehen und sie daraufhin mit einer Lösung zu konfrontieren.
Die Lösung: Switche schnell zwischen Problemraum und Lösungsraum
Ein effektiver Ansatz ist, möglichst schnell vom Problemraum in den Lösungsraum zu switchen und den Kund:innen eine Lösung zu präsentieren. Dazu führt Thomas mit seinen Kund:innen fünf bis zehn Interviews. Danach stellt er ihnen eine erste visuelle Skizze oder einen Prototyp vor, welcher zeigen soll, wie das Produkt in etwa aussehen wird. So bleiben dem gesamten Team die oben genannten Verschwendungen erspart.
Wichtig bei dieser Herangehensweise ist das schnelle Feedback der Kund:innen. Diese können anhand der präsentierten Skizze direkt anmerken, was funktioniert – und was nicht.
Falls die Lösung für die Kund:innen nicht funktioniert, switcht du zurück in den Problemraum, um das Problem besser zu verstehen. Je schneller dieser Mechanismus funktioniert, desto schneller lernst du, deine Kund:innen zu verstehen.
Wie komme ich schneller in den Lösungsraum?
Steckst du in der Situation, dass du schon lange im Problemraum festhängst? Dann hat Thomas einen konkreten Vorschlag: Baue eine kleine Lösung die dein aktuelles Verständnis vom Problem abbildet.
„Bauen“ kann hier vieles bedeuten:
- Eine Landingpage, die eine Lösung für das Problem anbietet
- E-Mails an bestehende Kund:innen, in denen du eine erste Lösung anbietest
- Eine Präsentation
- Ein kleiner klickbarer Prototyp
Wenn die Kund:innen dann wirkliches Commitment zeigen und die Lösung kaufen wollen: Super. Wenn nicht: Zurück in den Problemraum.
Falls du hierzu gerne ein konkretes Beispiel hättest, erläutert Thomas es dir im obigen Video ab Minute 7:38.
- Du solltest schnell aus dem Problemraum in den Lösungsraum kommen. Stichwort: Speed of learning.
- Du solltest dies so lange iterieren, bis du vorhersagen kannst, wie sich deine Kund:innen verhalten werden.
- Außerdem solltest du benennen können, warum die Kund:innen sich so verhalten, wie sie es tun.
Hilft dir dieser Leitfaden, die Discovery-Zeit in deinem Team zu optimieren? Wir freuen uns, von deinen Erfahrungen zu hören.
Wohin entwickelt sich Produktmanagement als Nächstes?
Bleib auf dem Laufenden mit unserem Product Newsletter und verpasse keine kostenlosen Artikel, Videos, Templates und Produktmanagement Events.