Illustration Discovery Venn

Product Discovery – aber bitte richtig

Wenn es einen Begriff gibt, der sich in Produktmanagement- und UX-Kreisen in den letzten Jahren herumgesprochen hat, dann ist es sicher „Product Discovery“. Hierbei handelt es sich um die Phase, in der für eine Produktidee zunächst untersucht werden soll, ob es überhaupt echte Nutzer gibt, die das Produkt haben wollen. Anschließend soll dann eine Lösung gefunden werden, die nutzbringend (valuable), bedienbar (usable) und umsetzbar (feasible) ist. Der Begriff „Product Discovery“ und die dahinter stehende Philosophie wurde dabei schon 2007 von Marty Cagan geprägt.

Aus meiner eigenen Erfahrung heraus sowie in Gesprächen mit anderen musste ich allerdings immer wieder feststellen, dass Product Discovery häufig falsch verstanden oder nicht richtig angegangen wird. So wird der Begriff teilweise entweder nur als Vorwand genutzt wird, sich 1-2 Wochen einem Thema zu widmen („Wir machen jetzt mal eine Discovery dafür“) oder aber dann in der Discovery-Phase doch nur eine Lösungs-Idee exploriert und mit Nutzern getestet wird. Daher möchte ich im Folgenden ein paar Tipps geben, worauf es bei einer echten Product Discovery ankommt und was zu beachten ist.

Discovery ist ergebnisoffen

Ganz wichtig ist es, sich und dem Management klarzumachen, dass eine Discovery Phase ergebnisoffen ist. Denn eine Kernaufgabe hierbei ist ja gerade herauszufinden, ob es überhaupt Sinn macht, eine Produktidee weiter zu verfolgen und ob es überhaupt Nutzer / Kunden gibt, die das Produkt benötigen und nutzen wollen. Bevor auch nur eine Zeile echter Code durch Entwickler produziert wird, sollte dies geklärt werden.

Da es aber viele Produktideen oder Marktchancen (Opportunities) gibt, von denen sicher nicht alle sinnvoll und erfolgreich sind, liegt es auf der Hand, dass das Ergebnis einer Discovery Phase auch sein kann (und sollte), dass die Idee doch nicht so gut ist oder die Opportuniy doch nicht so groß ist, wie gedacht. Oder aber man findet heraus, dass die Idee zwar gut ist, aber man nicht in der Lage ist, eine Lösung zu finden, die den Kriterien valuable, usable und feasible entspricht.

Wenn man in eine Discovery Phase geht, sollte man also auch akzeptieren können, dass die Idee nicht weiter verfolgt wird.

Discovery braucht Zeit

In einer Discovery finden verschiedenste Tätigkeiten statt – Problemerfassung- und definition, Ideation, Prototyping, User Testing etc. – und all diese Tätigkeiten benötigen eine gewisse Zeit (die es zwar zu optimieren gilt, aber man benötigt sie). Außerdem findet in der Discovery ein kreativer Prozess statt, der sich unter Zeitdruck nicht richtig entfalten kann. Daher finde ich es erstaunlich, wie wenig Zeit Teams immer wieder bekommen bzw. sich nehmen, um eine Discovery durchzuführen. Häufig soll schon nach zwei Wochen ein fertig getesteter Prototyp vorliegen, der die Nutzer begeistert – und das parallel zum Tagesgeschäft.

Meine Empfehlung an dieser Stelle ist, dass sich die Teams mehr Zeit nehmen um die Opportunity zu verstehen, (viele verschiedene) Lösungsansätze zu entwickeln, diese mit Nutzern zu testen und iterativ weiter zu entwickeln oder aber wie eben beschrieben auch zu verwerfen. Zwei Wochen Vollzeit sind hierbei ein guter Anfang und mit Prozessen wie Design Thinking kann man auch in zwei Wochen viel erreichen. Ich favorisiere jedoch eher 3-4 Wochen, sodass ausreichend Zeit ist, mehrere Iterationen zu durchlaufen und viele unterschiedliche Ideen zu explorieren und zu testen.

Kreativität ist nicht planbar und braucht Zeit. Diese Zeit ist keinesfalls verschwendet; sie sollte vielmehr als wichtiges Investment in den Produkterfolg angesehen werden. Denn bevor man unnötig viel Geld in die Entwicklung und Umsetzung eines Produkts steckt, sollte man vorher (und nicht erst zum Launch) sicher gehen, dass es auch wirklich Nutzer gibt, die das Produkt nutzen und dafür bezahlen werden.

Discovery muss geplant werden

Auch wenn ich gerade schreibe, dass Kreativität nicht planbar ist, so sollte man allerdings eine konkrete Planung für die Durchführung einer Discovery Phase aufstellen. Denn die Zeit und Ressourcen, die man für eine Discovery hat, sollten möglichst effizient und zielführend eingesetzt werden.

Folgende Fragen sollten u.a. vor Beginn der Discovery beantwortet werden, und das nachvollziehbar für alle Teilnehmer:

  • Wer ist in welchem Umfang beteiligt?
  • Wann findet was statt?
  • Was wird alles benötigt?
  • Mit welchen Nutzern soll wann und wie evaluiert werden?
  • Wie viel Zeit geben wir uns im ersten Anlauf?

Verantwortlich für die Planung der Discovery sollten meiner Meinung nach der Product Owner und / oder UX-Designer (inhaltlich) zusammen mit dem Scrum-Master (organisatorisch) sein.

Marty Cagan beschreibt in seinem Artikel „The Product Discovery Plan“ ausführlich, worauf bei der Planung einer Discovery noch geachtet werden soll.

Discovery bedeutet, das Problem zu verstehen

Den Einstieg in eine Discovery bietet häufig eine Produktidee, eine Marktchance – oder besser noch – ein unbefriedigtes Kundenbedürfnis oder -problem. Bevor man sich in den kreativen Ideation-Prozess stürzt und Lösungen für das Problem erarbeitet, sollte man jedoch mit allen Beteiligten herausfinden, ob das Problem mit all seinen Facetten von allen verstanden wurde und – noch wichtiger – ob es sich überhaupt um das richtige Kundenproblem handelt.

Häufig werden Ideen oder Problem nämlich aus Unternehmenssicht betrachtet (z.B. „Wir benötigen mehr zahlende Mitglieder“) oder die wahren Bedürfnisse sind nicht klar („Die Kunden wollen einkaufen“). Dies führt allerdings dazu, dass falsche Lösungen generiert werden, die den Kern des Problems nicht treffen und somit nicht erfolgreich sind.

Zum Herausarbeiten und Verstehen echter Kundenprobleme gibt es verschiedenste Techniken wie z.B. die „5 Why“-Methode und auch im Design Thinking Prozess steht die Problemdefinition an erster Stelle, wobei hier ein starker Fokus auf Interviews mit (potentiellen) Nutzern gelegt wird.

Discovery heißt, viele verschiedene Ideen iterativ auszuprobieren

Als Lösung für ein herausgearbeitetes Kundenproblem kommen in der Regel verschiedenste Ansätze in Frage. Den richtigen und optimalen Lösungsansatz zu identifizieren und weiter zu verfolgen ist jedoch die große Herausforderung in der Product Discovery.

Häufig werden daher zu Beginn einer Discovery sogenannte Ideation- oder Kreativ-Workshops durchgeführt, in der durch Brainstorming und andere Methoden viele Ideen generiert werden. Von diesen werden die 1-2 vielversprechendsten Ansätze ausgewählt und dann im Detail ausgearbeitet, als Prototyp umgesetzt, getestet und optimaler Weise iterativ weiter entwickelt.

Das Problem hierbei ist jedoch, dass man sich zu früh auf einige wenige Ansätze konzentriert und an diesen festhält – und somit den Ideenraum zu früh wieder schließt. So läuft man Gefahr, dass man sich in die Ideen verliebt und diese hin zu einem lokalen Maximum weiter entwickelt – aber den großen Sprung zu einem noch viel besseren Ansatz verpasst.

Das es auch anders gehen kann, habe ich in einem Vortrag von Tom Chi von Google gelernt, der auf der Mind the Product in London über Rapid Prototyping und Rate based goals referierte. In seinem sehr inspirierenden Vortrag berichtete Tom, dass seine Design-Teams in den Kreativ-Phasen die Aufgabe haben, pro Woche 15 verschiedene Prototypen zu erstellen und diese mit Nutzern zu testen. Am Ende der Woche werden dann die Erkenntnisse zusammen getragen, die guten Ansätze werden in die nächste Iteration übernommen und die weniger guten verworfen. Nach mehreren Iterationen erhält man so einen Prototypen, der die besten Ansätze vereint.

Die jeweiligen Prototypen und zu die beantwortenden Fragestellungen sind dabei freilich kleinteiliger, aber laut Tom liegt der Vorteil darin, dass nicht zielführende Ansätze frühzeitig und mit nur minimalem Aufwand erkannt werden.

Discovery bis zum MVP

Eine weitere Gefahr in der Product Discovery ist, dass man über das Ziel hinaus schießt und gleich ein zu umfangreiches Produkt mit einem zu großen Funktionsumfang konzipiert. Die Herausforderung gerade bei neuen Produkten ist es jedoch, einen Funktionsumfang zu finden, der einerseits ausreichend ist und einen möglichst großen Mehrwert für die Nutzer bringt; andererseits sollte der Umfang nicht zu groß sein, sodass man einen ersten Release frühzeitig an echte Nutzer herausgeben kann, ohne zu viel Zeit und Ressourcen zu verwenden. Die Rede hier ist also vom sogenannten Minimum Viable Product (MVP), wobei es hier zwei unterschiedliche Definitionen des Begriffs gibt.

Marty Cagan schreibt in seinem Blog:

I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.

Eric Ries verwendet in „The Lean Startup“ eine etwas andere Definition:

The MVP is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

Beide Definitionen gemein ist, dass möglichst wenig Ressourcen für einen möglichst großen Lernumfang verwendet werden soll.

Die spannende Frage ist allerdings, wie man das MVP findet. Eric Ries spricht häufig von möglichst kleinen Experimenten, die einem das Kundeninteresse belegen sollen. So schlägt er beispielsweise vor, für eine Produktidee zunächst eine Landingpage mit Newsletteranmeldung zu bauen, bevor das Produkt überhaupt konzipiert wird. Marty Cagan hingegen schlägt vor, dass insbesondere in Nutzertests immer wieder das Nutzungsinteresse an gewissen Funktionen hinterfragt wird und diese, falls das Interesse nicht ausreichend groß ist, in der nächsten Iteration einfach weg gelassen werden. Wenn die Funktion dann nicht von Nutzern vermisst wird, war sie nicht relevant für das MVP.

Discovery ist Teamsache

Zu guter letzt noch ein Punkt, der im agilen Umfeld und insbesondere wenn man dem Design Thinking Prozess folgt eigentlich selbstverständlich ist: Product Discovery ist eine interdisziplinäre Tätigkeit, in der möglichst viele aus dem Team, insbesondere auch die Entwickler, aber auch Stakeholder und Manager teilnehmen sollten. Denn je mehr  Perspektiven in die Discovery eingebracht werden, desto vielseitiger und unterschiedlicher werden die Lösungsansätze, die dabei heraus kommen.

 

Ich hoffe, dass euch diese Tipps etwas Inspiration für die nächste Discovery Phase geben konnten und bin gespannt auf euer Feedback: was sind eure Learnings bzgl. der Product Discovery? Was hat bei euch gut funktioniert, was weniger gut?

Über Rainer Gibbert

Rainer ist Produktmanager mit großer Begeisterung für gute, Kunden-orientierte und wirtschaftlich erfolgreiche Produkte. Derzeit arbeitet er bei der StyleRemains GmbH in Hamburg als Produktmanager und Product Owner für REBELLE, dem Online Marktplatz für hochwertige Designermode im Second Hand Bereich. Zuvor war Rainer u.a. bei Fielmann Ventures als Senior Produktmanager sowie bei OTTO als Produktmanager im E-Commerce Innovation Center tätig und leitete das User Insights Team bei der XING AG.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *