xingtwittersharerefreshpicture as pdfLogo_DPM_SCHRIFTZUGinstagram icon blackShapeGroup 3 Copy 2Group 2 Copydepartment_productdepartment_datascienceuserclosebasic clockblogShapearrows slim right copy 3

Product Discovery Sprint - Tag 1: Understand

DieProduktMacher

DieProduktMacher |

21. Okt. 2014 |

- min Lesezeit

An Tag 1 des Product Discovery Sprints gilt es zu verstehen wer mein Kunde ist und welche Bedürfnisse ihn treiben. Wir führen uns Hypothesen vor Augen und werden den Problemraum ausleuchten. Unsere Annahmen der Nutzerbedürfnisse halten wir im Lean Canvas fest. Auf dieser Basis entsteht ein Problem Interview – und dann heißt es "Get out of the building!".

Ziel des ersten Tages ist durch das Gespräch mit unseren potenziellen Nutzern unsere Hypothesen zu validieren. In welcher Situation befindet sich unser Nutzer, wenn er mein Produkt brauchen könnte? Wie geht er damit aktuell um? Ein echtes Verständnis für den Nutzer ist die Grundlage der Produktentwicklung. Alle unvalidierten Hypothesen, die wir im Kopf haben sind reine Annahmen – aber kein Wissen! Bei der Strukturierung unserer Hypothesen hilft uns der Lean Canvas.

Der Lean Canvas - Struktur schaffen

Je mehr Zeit wir mit unseren Produkten verbringen, desto mehr Annahmen haben wir. Die Annahmen sind gut - sie bieten die Grundlage für ein fruchtbares Lernen in den nächsten Tagen. Für was man aber oft einfach keine Zeit hat ist die Strukturierung der Hypothesen. Uns hilft dabei der Lean Canvas das Produkt, die Idee, den Service explizit nutzerorientiert zu betrachten.

Bei der Arbeit mit dem Lean Canvas empfiehlt sich die folgende Reihenfolge. Sie bildet auch eure nächsten Schritte bei der Produktvalidierung ab:

1. Problem

Dabei geht es um die Annahmen, die wir über die Situation/das Problem haben, in der unser Produkt benötigt wird. Ein Unterpunkt hiervon sind die Alternativen. Es sind keine Wettbewerber gemeint, sondern Workarounds mit denen das Problem aktuell gelöst wird. Ein gefährlicher aber nicht zu missachtender Workaround ist “Nichts”. Denn dann stellt sich die Frage: Ist das Problem es überhaupt wert gelöst zu werden, wenn keiner eine Lösung dafür sucht?

2. Customer

An wen denken wir, wenn wir von unserem Kunden sprechen? Dabei sind nicht nur grobe demografische Merkmale relevant, sondern auch Bedürfnisse und Situationen. Als Unterpunkt gibt es die Überlegung: Wer ist eigentlich unser Early Adopter. Welche Erstanwender suchen bereits akut nach einer Lösung und helfen dadurch bei der Produktentstehung.

3. Unique Value Proposition

Nicht zu verwechseln mit dem gerne rezitierten USP (Unique Selling Proposition). Beim UVP geht es um Mehrwerte und diese zu formulieren ist kniffeliger als es klingt. (Hier werden keine Lösungen formuliert.)

4. Solution

So und jetzt sind wir bei der Lösung – endlich! Hier denken wir drüber nach, welche Lösung so einfach wie möglich das Problem (siehe 1.) für den Kunden (siehe 2. ) löst und dabei den UVP liefert (3.). Jetzt kann wie wild überlegt werden, wie das aussehen kann – vielleicht ist es ja eine Papyrusrolle. Klingt verrückt? Schaut euch mal unsere Erfahrung auf der Lean Startup Machine 2013 an. Damals war unsere erste Lösung (MVP) eine ausgedruckte Google Maps Karte mit 5 Insidertipps, für die wir von Touristen bares Geld erhielten.

5. Channel

Wo treffe ich meinen Kunden an? Offline, Online oder auch Marketingkanäle. Für den ersten Wurf hilft es euch aber aus Erfahrung zu überlegen: An welchem physischen Ort befindet sich mein Kunde, wenn er in der Situation ist und das Bedürfnis hat? Für MyTripMap ist das in einer Stadt wie München sehr einfach: Marienplatz.

Wir werden uns bei dem Product Discovery Sprint auf Punkt 1-5 fokussieren, daher sind die weiteren Punkte weniger ausführlich.

6. Revenue: Wie kann ich mein Produkt monetarisieren? 7. Key Metrics: Welche sind die wichtigsten Kennzahlen? (Empfehlung: Pirate Metrics) 8. Engine of Growth: Diesen Punkt haben wir adaptiert. Eigentlich steht dort ein Unfair Advantage (Was haben wir, was uns keiner so schnell nachmacht?). Wichtiger finden wir zu wissen, welches unsere Engine of Growth ist und wie diese in den einzelnen Phasen zusammenspielen. Es gibt drei an der Zahl:

  • Viral (Bsp: WhattsApp oder das gute alte Fax)
  • Paid (Customer Acquisition ist geringer als Revenue)
  • Sticky (Wenn ich einmal den Aufwand betrieben habe, werde ich nicht wieder wechseln. Bsp: Oracle, SAP)

Das Problem Interview - Listen and Comprehend

Im nächsten Schritt werden wir überprüfen, ob unsere Hypothesen wahr sind. Und wie machen wir das? Wir fragen unsere potenziellen Kunden in sogenannten Problem Interviews. Dabei geht es darum viel zuzuhören, nachzuhaken und zu verstehen. Unsere Erfahrung hat gezeigt, dass ein direktes Gespräch mit der Zielgruppe die meisten Augen öffnet.

Hypothesen richtig validieren

Bevor wir rausgehen schauen wir uns genau an, welche Hypothesen bei (1) und (2) am kritischsten sind. Denn es geht genau um diese Punkte. Wir versuchen in Interviews Antworten auf folgende Fragen zu erhalten:

  • Wer ist mein Kunde?
  • Kennt er die Situation? Hat er das Bedürfnis?
  • Wie geht er aktuell damit um?
  • **Was wünscht er sich eigentlich in der Situation?*

Achtet bei der Befragung darauf nicht suggestiv zu fragen. Ihr solltet ein Gespräch aufbauen, bei dem das gegenüber mehr spricht - wir wollen zuhören und lernen. Versucht innerhalb 1 Stunde 10 Interviews mit Menschen zu führen, die das Problem haben. Am besten befragen immer zwei 2er-Teams und treffen sich nach Ablauf der Stunde (= 20 erfolgreiche Interviews). Dann wertet ihr die Ergebnisse gemeinsam aus und überlegt, was ihr noch lernen möchtet. Anschließend adaptiert ihr eure Fragen entsprechend und führt innerhalb von einer Stunde noch einmal 10 Interviews pro Team.

Oh nein! Keiner kennt das Problem

Es kann sein, dass sich  im Laufe der Interviews herauskristallisiert, dass die Interviewpartner das angesprochene Problem nicht haben. Dann gibt es regulär zwei Möglichkeiten.

  1. Customer Pivot Wir haben mit den falschen Personen gesprochen oder das Bedürfnis ist nicht relevant genug. Beides ist erst einmal sehr frustrierend. Aber nicht verzagen: Wer fein beobachtet und zuhört, hat zwischen den Zeilen ein ähnliches Problem oder Bedürfnis entdeckt. Wahlweise kann eine andere Zielgruppe das Bedürfnis viel stärker haben, einfach genau beobachten. Beispiel: Wenn ihr Männer befragt und alle sagen euch “Nee ich kenne die Situation nicht, aber meine Freundin!”, dann solltet überlegen Frauen anzusprechen.
  2. Problem Pivot Es gibt aber auch den Problem Pivot. Bei einem unserer eigenen Produkte (MyTripMap) war die initiale Frage: “Kennst du die Situation, dass du bei der Planung eines Städtetrips verschiedenen Quellen hast und am Ende eine lose Zettelsammlung und diverse Reiseführer vor Ort hast?” und die Antwort darauf war öfters “Ja, aber ich habe eher das Problem, dass ich nach Insidertipps suche und keine finde.” Dann ist die Überlegung, ob dieses Problem viel größer ist.

Ergebnis von Tag 1

An Tag 1 habt ihr vor allem gut zuhört und die Aussagen eurer potenziellen Nutzer konzentriert ausgewertet. Wo finden sich Überschneidungen oder gemeinsame Muster? Welche Bedürfnisse, Pain Points und Workarounds haben sich bestätigt oder wurden neu identifiziert. Durch das Validieren eurer Hypothesen und den direkten Nutzerkontakt spart ihr euch viel Zeit, Diskussionen und Entscheidungsfindungsprozesse bei der weiteren Produktentwicklung. Auf Basis des Gelernten wird an Tag 2 des Product Discovery Sprints eine Breite Fülle an Lösungsideen generiert.


Ähnliche Artikel

Ähnliche Artikel


Was denkst Du?

facebook

Wird geladen...

twitter

@beril from Google Analytics says at #dlsummit the…

instagram

Wird geladen...

ARKit, an opportunity you will regret having missed
blog

ARKit, an opportunity you will regret having missed