Wie funktioniert ECHTE Product Discovery?

Stolperst du immer wieder über den Begriff Product Discovery?

Da bin ich mir sicher! 

Marty Cagan von der silicon valley product group formulierte das durchaus revolutionäre Produktmanagement-Konzept schon 2007 in einem unscheinbaren Blogartikel.

Mit Product Discovery ist es wie mit agilen Methoden: Jeder kennt sie, jeder findet sie irgendwie gut, doch die wenigsten verstehen sie richtig und mit der praktischen Umsetzung hapert es in den meisten Unternehmen gewaltig.

Also, was bedeutet echte Product Discovery wirklich?

Wie setzt du sie in deinem Produktmanagement um?

Mit diesem Artikel bekommst du eine grundlegende, leicht verständliche Einführung ins Thema.

Product Discovery: Die Grundidee

Product Discovery ist ein Teil der Idee, das Produktmanagement in zwei nebeneinander existierende Hauptprozesse einzuteilen: das so genannte Dual Track Development, oder auf Deutsch, die „Zweigleisige Entwicklung“.

Die beiden „Tracks“ sind:

• Product Discovery: Die richtigen Produktideen oder -initiativen entdecken
• Product Delivery: Die Produkte entwickeln und ausliefern

Die beiden Tracks sind keine aufeinanderfolgenden Schritte eines linearen Prozesses. Sie stehen gleichberechtigt nebeneinander. Sie laufen jeweils in sich iterativ ab und beeinflussen sich an bestimmten Schnittstellen gegenseitig.

Klingt abstrakt, aber diese Grafik macht es anschaulich:

Diese Darstellung finde ich ebenfalls sehr gut:

Die Product Discovery umfasst folgende Aufgaben:

• Ungelöste Probleme in den Zielmärkten zu finden
• Produktideen zu finden, mit denen die Probleme gelöst werden könnten
• Herausfinden, ob es genügend Kunden gibt, die das Produkt kaufen und nutzen möchten
• Herausfinden, ob ein Produkt machbar wäre und die Anforderungen des Marktes erfüllen würde

Während des Product Discovery Prozesses erlangst du als Produktmanager die Gewissheit, dass deine Produktidee die größtmöglichen Chancen auf Erfolg hat. Erst dann zapfst du die kostbaren Budgets und Ressourcen in der Entwicklung an und gibst den Programmierern oder Konstrukteuren das Go.

Was Product Discovery NICHT ist

Bevor wir in die Details der Product Discovery eintauchen, schauen wir uns an, wie viele Produktteams heute arbeiten – nämlich nach dem genauen Gegenteil von Product Discovery.

Ein Produktteam erstellt und pflegt eine Liste mit Produktideen und Features. In regelmäßigen Priorisierungsrunden legen sie fest, welche davon zuerst umgesetzt werden.

Die Ideen kommen von den Produktmanagern selbst oder vom Management. Sie werden aus verschiedenen Quellen gesammelt: aus Kundenbefragungen, aus dem Nutzersupport oder vom Vertrieb.

Für die Priorisierung nehmen sie diverse selbst definierte Kriterien her: Sie ermitteln den Business Value für sich durch eine Formel oder ein Punktesystem, sie werten Marktanalysen aus oder zählen die Feature Requests von Kunden. Oder am Ende entscheidet einfach der Chef.

Dann geht das neue Produkt oder Feature in die Entwicklung.

Diese Vorgehensweise beruht auf diesen Annahmen:

In der Praxis führen diese Annahmen zu folgenden Fehlentwicklungen im Produktmanagement:

Das Management (oder der Produktmanager) legt sich von vornherein auf eine Idee fest. Die Product Discovery soll dafür die nötige Legitimation liefern und die Idee mit Marktzahlen „belegen“ – wenn überhaupt.

Kundenwissen, das gegen eine Idee spricht, wird umgedeutet oder ignoriert.

Um Leerlauf in der Entwicklung zu vermeiden, erwartet das Management ein umsetzbares Produktkonzept bis zu einem fixen Termin. Die Product Discovery wird wie ein reguläres Projekt geplant, mit festen Phasen und Deadlines.

Wie marktfähig eine Produktidee wirklich ist, zeigt sich so erst einige Zeit nach dem Produkt-Launch an den Umsatzzahlen. Im schlimmsten Fall hast du viel Geld und Monate der Entwicklung komplett in den Sand gesetzt. 

Das ist eine ziemlich teure Lernmethode!

Anstatt nach den wahren Ursachen eines Produkt-Flops zu suchen, gibt man dir als Produktmanager die Schuld, selbst wenn du nur Anweisungen befolgt hast.

So funktioniert ECHTE Product Discovery wirklich

Echte Product Discovery hat mit der zuvor beschriebenen Vorgehensweise rein gar nichts zu tun!

Sie erfordert eine umgekehrte Sichtweise, ein radikal anderes Mindset!

Sie basiert auf folgenden Annahmen:

Product Discovery heißt: Du sitzt nicht im Büro und fragst „Was können wir bauen?“, sondern du gehst raus in den Markt und redest mit Kunden.

Du tauchst in seine Welt ein, lernst seine Probleme und Bedürfnisse im Kontext verstehen. Kennst du seine Probleme, entstehen daraus Produktideen, um diese Probleme zu lösen.

Achte auf die Wortwahl: Du „entwickelst“ keine Ideen, sondern sie „entstehen“ aus deinen Erkenntnissen über Kunden. Sie drängen sich dir praktisch auf.

Als Nächstes musst du herausfinden, ob es einen Markt für deine Produktidee gibt. Ob viele andere Kunden ein ähnliches Problem haben und bereit sind, für eine bestimmte Lösung zu bezahlen.

Du musst außerdem herausfinden, ob und wie du das Problem mit deinem Produkt am besten lösen kannst. Das Produkt muss für den Kunden möglichst nützlich und wertvoll sein. Andererseits muss das Produkt für euch intern technisch machbar sein und sich wirtschaftlich lohnen.

Dabei gehst du jeweils iterativ vor, in kleinen Schritten. Jede Annahme oder Idee, die du hast, validierst du durch vorhandenes Kundenwissens oder Tests.

Lässt sich eine Idee nicht validieren, veränderst du sie und führst deine Tests erneut durch. Oder du gibst sie auf, wenn sich herausstellt, dass du in eine falsche Richtung gedacht hast – auch das gehört zur Product Discovery!

Selbst wenn du eine (scheinbar) gute Idee gefunden hast, baust du nicht gleich einen Prototyp oder gar das Produkt. Du gehst weiter iterativ vor und entwickelst deine Ideen immer nur ein Stück weiter, bis du den nächsten Test durchführen kannst.

Am Ende dieses Prozesses steht ein Minimum Viable Product (MVP), mit dem du an den Markt gehst.

Die zwei Dimensionen der Product Discovery

Product Discovery umfasst zwei Aufgaben oder Dimensionen:

Die beiden Dimensionen stehen in Wechselwirkung: Aus deinem Kundenverständnis entstehen neue Ideen, die du testest. Durch die Tests wiederum lernst du deine Kunden noch besser verstehen. Du stößt auf neue Probleme, die dich wieder auf neue Ideen bringen können.

Schauen wir uns diese beiden Dimensionen näher an, was sie beinhalten und welche Tools dir dafür zur Verfügung stehen.

1. Ein tiefes Verständnis für die Kunden entwickeln (Idea & Discover)

Im Team entwickelt ihr ein gemeinsames Verständnis eurer Kunden. 

Dieses Verständnis beruht nicht auf der Meinung oder Sichtweise des Produktteams oder des Managements, sondern auf Fakten und Daten!

Du als Produktmanager bist dafür verantwortlich, diese Daten zu sammeln. Dafür nutzt du folgende Tools und Methoden:

Allerdings bringt es nicht viel, wenn du dein Wissen für dich selbst behältst. Bereite die Daten und Fakten übersichtlich und verständlich auf und teile sie mit dem gesamten Produktteam, einschließlich der Entwicklung und des Produktmarketings.

Kompakte, visuelle Darstellungen eignen sich dafür besonders, wie

• Buyer und User Personas (Käufer- und Nutzer Personas)
• Customer Journey Map

Hier ein sehr detailliertes Beispiel einer Customer Journey Map (zur Großansicht auf Flickr):

Da du regelmäßig neue Daten erhebst, verändert und verbessert sich euer Verständnis für den Kunden. Die erwähnten Dokumente müssen „leben“: Halte sie aktuell und ergänze sie laufend.

Euer Ziel ist, echte Empathie für eure Kunden zu entwickeln. Was bedeutet das?

Stell dir einen guten Freund vor, mit dem du regelmäßig Zeit verbringt und intensive Gespräche führst. Du spürst, wenn es ihm nicht gut geht oder er ein Problem hat.

Musst du dich zu Hause mit Stift und Papier hinsetzen oder ein Brainstorming durchführen, um herauszufinden, wie du ihm helfen kannst?

Natürlich nicht! 

Du weißt es einfach. Dir kommen automatisch Ideen in den Sinn, was du für ihn tun kannst.

Genau so eine Beziehung müsst ihr zu euren Kunden aufbauen. Seid ihr wie ein guter Freund für eure Kunden, müsst ihr keine Ideen suchen. Sie kommen zu euch!

Deshalb ist das gemeinsame Verständnis im Team so wichtig! 

Je mehr „Freunde“ ihr seid, desto mehr Augen und Ohren habt ihr für die Kunden, desto mehr unterschiedliche Sichtweisen gibt es und desto mehr Ideen werdet ihr haben – die ihr im zweiten Schritt testen könnt.

2. Ideen iterativ testen (Validate)

Bevor du eine Idee weiter verfolgst und Ressourcen in die Entwicklung steckt, musst du herausfinden, ob sich das wirklich lohnt.

Product Discovery bedeutet, jede Idee so früh wie möglich und ergebnisoffen zu testen. 

Entweder funktioniert die Idee und du kannst sie iterativ weiterentwickeln und wieder testen. Funktioniert sie nicht, veränderst du sie und testest sie erneut oder du gibst sie komplett auf und gehst zur nächsten Idee über.

Wie gehst du dabei vor?

Stelle Hypothesen auf und validiere sie

Du stellst für jede Idee mehrere Hypothesen – oder Annahmen – auf und versuchst sie zu validieren.

Stelle diese beiden Fragen: 

Eine gute Hypothese erfüllt die folgenden Kriterien:

Diese Beispiele helfen dir, zu verstehen, wie eine Hypothese aufgebaut sein muss:

Hast du erkannt, dass alle diese Hypothesen einem festen Muster folgen? Nutze einfach den folgenden „Lückentext“, um deine eigenen Hypothesen zu bauen: 

Wie validierst du eine aufgestellte Hypothese?

Nutze vorhandenes Wissen

Zuerst nutzt du dein vorhandenes Kundenwissen: nicht deine Meinung, sondern die Daten, die du zum Beispiel durch Kundeninterviews gewonnen hast. (Weiter oben, unter Idea & Discover, hatte ich bereits eine längere Liste an Methoden aufgeführt.)

Analysiere diese Daten und suche nach Erkenntnissen, die eine Hypothese beweisen oder widerlegen.

Nutze dafür die bereits erwähnten Tools Persona und Customer Journey Map.

Versetze dich in die Rolle einer deiner Kunden-Persona und spiele das Szenario durch, das deine Hypothese beschreibt.

Greife auch auf das Wissen der Entwickler, Produktmarketer, Vertriebler oder von externen Partnern zu.

Für manche Annahmen hast du jedoch noch zu wenige Daten, um sie zu validieren. Oder bestimmte Annahmen erscheinen dir riskant und sehr weitreichend, so dass du schlagkräftige Beweise dafür brauchst.

Führe Tests und Experimente durch

In diesem Fall führst du Tests oder Experimente durch, um deine Hypothesen zu validieren.

Der Business Model Testing Reference Guide von Strategyzer erklärt, dass du grundsätzlich drei verschiedene Dinge testen kannst:

Für jeden Test definierst du zuerst folgende Faktoren:

Am Beispiel oben:

Die Test Card von Strategyzer ist ein simples Tool, mit der du einen Test aufbauen kannst. Trage deine Hypothese und die drei Testfaktoren ein und los gehts…

Um den Test durchzuführen kannst du Methoden des Pretotyping nutzen:

• Du beschreibst oder präsentierst eine Idee und fragst nach Feedback dazu – entweder persönlich in deinen regelmäßigen Kundeninterviews oder im Rahmen einer Umfrage (wie im Beispiel oben).
• Du führst sogenannte Smoke-Tests durch: Du bewirbst ein (nicht vorhandenes) Produkt oder Feature, zum Beispiel auf einer Landing-Page oder mit einem Flyer, und misst, wie viele Kunden sich dafür interessieren.
• Du baust einen statischen oder interaktiven Dummy deines Produkts und lässt es von Nutzern testen, zum Beispiel klickbare Wireframes für eine neuen Webseiten.
• Du modifizierst ein Wettbewerber-Produkt und lässt es von Kunden testen.

Hier findest du eine ausführlichere Beschreibung zu Pretotyping-Methoden.

Anhand der Testergebnisse findest du heraus, wie viele deiner Annahmen sich bewahrheiten.

Darauf basierend entwickelst du die Idee iterativ weiter. Du optimierst und testest die Idee so lange, bis die Daten dafür sprechen, das Produkt zu bauen. Oder anders ausgedrückt, bis sich ausreichend viele Hypothesen bewahrheitet haben, um die Idee als „wertvoll“ zu bezeichnen. 

Kannst du nicht genügend Daten sammeln, um ausreichend viele Hypothesen für eine Idee zu validieren, musst du die Idee verwerfen.

Verändere je Iteration, also von einem Test zum nächsten, nicht zu viele Variablen. Am besten immer nur eine. Sonst kannst du die Ergebnisse nicht interpretieren und kaum herausfinden, welche Änderung welchen Effekt verursacht hat.

Halte deine Learnings aus den Tests auf jeden Fall fest, damit sie in dein „vorhandenes Wissen“ einfließen. Später kannst du bei neuen Produktideen darauf zurückgreifen, ohne den Test erneut durchführen zu müssen.

Auch dafür hat Strategyzer ein tolles Tool, die Learning Card:

Aller Anfang ist schwer

Am Anfang, wenn du mit deiner Product Discovery beginnst, kostet dich die Validierung viel Zeit und Mühe. 

Du hast viele unbestätigte Annahmen und wenige Erkenntnisse – nur Vermutungen. Du musst für jede einzelne Hypothese Experimente durchführen, sie auswerten und wiederholen, bis du genügend Daten gesammelt hast. 

Du wirst vielleicht das Gefühl haben, dass das Produkt nie fertig werden wird.

Doch es gibt Hoffnung!

Wenn du neue Produkte oder Features entwickelst, wirst du immer wieder auf dieselben, bekannten Annahmen stoßen. Du kannst immer öfter auf bereits vorhandenes Wissen zurückgreifen und musst immer weniger Experimente durchführen. 

Baue dir eine Bibliothek an Kundenwissen und Erkenntnisse auf. Das wird dein wertvollster Schatz als Produktmanager!

Übrigens: Nicht jede kleine Idee muss validiert werden. Es wäre nicht sinnvoll, zwei Tage Aufwand in die Validierung einer Idee zu stecken, wenn dein Entwickler das Feature in der gleichen Zeit bauen könnte. 

Je strategischer eine Idee ist und je größer die notwendigen Investitionen sind, desto wichtiger ist die iterative Vorgehensweise der Product Discovery. Auch Ideen, die scheinbar klein sind, aber ein hohes Geschäftsrisiko bergen, musst du testen (zum Beispiel Preiserhöhungen).

Nur so kannst du vermeiden, viel Zeit und Geld in eine Idee zu stecken, die sich später als Flop erweist.

Das Ziel der Product Discovery: Das Minimum Viable Product

Das Ergebnis der Product Discovery ist das Minimum Viable Product (MVP): Ein Produkt, das die Mindestanforderungen erfüllt, um am Markt Erfolg zu haben.

Laut Definition muss ein MVP folgende Kriterien erfüllen:

Wie genau muss das MVP für eine konkrete Idee aussehen? Auch das musst du im Rahmen der Product Discovery durch Tests und Experimente herausfinden.

Wie bereits erwähnt ist der Prozess der Product Discovery nie zu Ende, auch nicht nach Auslieferung des MVP.

Du gewinnst neue Erkenntnisse aus dem Betrieb, entdeckst Probleme deiner Kunden, hast Ideen für neue Features, testest und validierst sie, optimierst oder verwirfst sie wieder….

3 Must-haves für die Product Discovery

Teamarbeit

Dieser Punkt ist so wichtig, dass ich mich gerne wiederhole: Es bringt rein gar nichts, wenn das Wissen über die Kunden auf die Produktmanager beschränkt ist. 

Erstens entstehen so viel weniger Ideen.

Zweitens sollten die Entwickler in den Prozess der Discovery mit einbezogen werden. Sie können dabei helfen, umsetzbare Lösungen zu finden und diese zu testen.

Kennen die Entwickler jedoch den Kunden gar nicht, bleibt ihnen nur das Prinzip „Trial-and-Error“: Am Ende kommt vielleicht das richtige Ergebnis heraus, aber bis dahin braucht es viele Anläufe, die Ressourcen kosten.

Die zwei Tracks des Product Management dürfen nicht zugleich zwei Teams bedeuten.

Es gibt EIN Produktteam, das gemeinsam für den Produkterfolg verantwortlich ist!

Jeff Patton fasst diese Aussage sehr schön in wenigen Worten zusammen: 

“It’s Dual Track, not Duel Track”. 

Es ist deine Aufgabe als Produktmanager, die Arbeit im Produktteam zu koordinieren und die Erkenntnisse aus der Product Discovery mit allen zu teilen.

Ergebnisoffenheit

Das Ergebnis der Product Discovery kann niemand vorhersagen.

Du könntest nach wochenlanger Arbeit zu der Erkenntnis kommen, dass ihr aktuell KEINE Idee habt, deren Umsetzung sich lohnt. Oder dass es für die tolle Idee das Managements – deren „Baby“ – einfach keinen Markt gibt.

Steht das Ergebnis der Product Discovery von vornherein fest – „bis dann und dann muss diese Idee entwickelt sein“ –, verliert der ganze Prozess seinen Sinn.

Du als Produktmanager musst 100% ergebnisoffen an deine Tests herangehen. Die Wahrheit liegt in den Daten! 

Funktioniert eine Idee nicht, musst du sie gehen lassen.

Du und dein Management müsst davon überzeugt sein, dass die Zeit für die Product Discovery keine verschwendete Zeit ist. 

Ein „negatives“ Ergebnis der Product Discovery kann Millionen Wert sein: Weil es euch davor bewahrt, riesige Ressourcen zu verschwenden und ihr euch auf wirklich erfolgversprechende Produkte konzentrieren könnt.

Ein System

Die Product Discovery kann nicht wie ein reguläres Projekt geplant werden: Mit einem bestimmten Ergebnis zu einer bestimmten Deadline.

Trotzdem braucht sie ein System, vor allem bei großen Produktteams. 

Die Ressourcen müssen effizient genutzt werden. Es müssen die richtigen Daten erhoben und an die richtigen Stellen verteilt werden. 

Wird die Zusammenarbeit nicht geregelt, bleibt alles an dir als Produktmanager hängen und der Erfolg der Product Discovery ist gefährdet. 

Ein Blogartikel der Silicon Valley Product Group erklärt, wie ein Product Discovery Plan aussehen kann.

Du solltest darin grundlegende Fragen klären, wie:

• Wer ist wie beteiligt? Wer muss, sollte und kann an welchen Prozessen teilnehmen?
• Welche Ressourcen und Tools werden benötigt?
• Welche Aktivitäten werden wie oft und in welchem Umfang durchgeführt?
• Wie werden die Kunden/Nutzer für die Tests und Experimente ausgewählt?
• Wie viel Zeit geben wir uns im ersten Anlauf?
• Wie und wo werden die Daten geteilt und aufbereitet?
• Wer entscheidet über was?

Genauso wie für die Entwicklung solltest du die Product Discovery mit einem agilen Mindset planen. Organisiert die Aktivitäten in kurzen Sprints oder ‚Time-Boxes‘, an deren Ende jeweils eine neue Erkenntnis oder ein Testergebnis stehen muss.

Dieser Artikel ist inspiriert von “An Introduction to Product Discovery” von Teresa Torres.