#customer-development #customer-validation #lean-canvas
21. Oct 2014 |
- min Lesezeit
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.
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:
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?
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.
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.)
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.
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:
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.
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:
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.
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.
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.