In meinem Blogbeitrag über die Lean Startup Methode habe ich den aus dem gleichnamigen Buch bekannten Build-Measure-Learn Kreislauf erläutert und die Produktentwicklung als eine Reise voller Ungewissheiten bezeichnet. Durch die Lektüre des Buches „Inspired: How To Create Products Customers Love“ kam ich zu der Erkenntnis, dass diese Entdeckungsreise mit einer Vision startet, deren konkrete Umsetzung – das eigentliche Produkt – aber am Anfang noch gar nicht existiert und erst während der Reise Stück für Stück entdeckt wird. Während dieser schrittweisen Entdeckung können verschiedene Methoden genutzt werden. Und oft gibt es kostengünstigere Alternativen als einfach ein Feature fertig zu entwickeln und dann erst zu prüfen ob es von den Nutzern und Kunden akzeptiert und gekauft wird. 

Für digitale Produkte und deren Features gilt, dass sie skalierbar, performant, wartbar, kontinuierlich releasebar sein müssen, durch automatisierte Regressionstest abgesichert sein sollten sowie für die Weiterentwicklung die erforderliche Analysedaten sammeln und zu guter Letzt auf die Unternehmensmarke abgestimmt sein müssen. 

The output of discovery is a validated product backlog

Bevor all dies sichergestellt wird, sollte man sich sehr sicher sein, dass mit der Produktidee oder der Featureidee auch wirklich ein dauerhaftes Business aufgebaut werden kann, was bedeutet, dass das Produkt sich dauerhaft finanziell selbst trägt. Um dies sicherzustellen muss jede Produktidee auf die folgenden Risiken hin validiert werden, bevor das Produkt entwickelt wird.

Jede Produktidee muss gegen die folgenden Risiken validiert werden, um zu beweisen, dass diese den Risiken standhält.  

Mehrwert, Nutzen & Usability Risiko 

• Hat der Kunde das Problem was wir versuchen zu lösen?
• Ist unsere Lösung hausragend besser als die Lösung die der Kunde aktuell nutz, um sein Problem zu lösen?
• Ist der Kunde in der Lage zu verstehen und zu erlernen wie unsere Lösung funktioniert?
• Wird der Kunde sich dazu entscheiden die Lösung zu nutzen oder zu kaufen?
• Wie wir das Produkt an den Kunden geliefert und ist dies für ihn ein akzeptabler Weg?

Machbarkeitsrisiko

• Können wir die anvisierte Lösung entwickeln?
• Haben wir die erforderlichen Skills und Technologien?

Markfähigkeits- & Realisierungsrisiko

Funktioniert die Lösung für unsere verschiedenen Unternehmensbereiche?

• Vertrieb: Haben die Mitarbeiter das erforderliche (technische) Wissen, um das Produkt bewerben, verkaufen und Rückfragen beantworten zu können? Auch die Organisation des Vertriebs kann eine hohe Relevanz haben. Teure Vertriebskanäle, wie Direktvertrieb, benötigen sehr hochwertige Produkte mit hohen Preispunkten.
• Marketing:  Ist die geplante Lösung konsistent zu unserem Markenversprechen?
• Legal: Welche Vorgaben aus Sicht Compliance, Datenschutz, Urheberrecht, geistigem Eigentums, Wettbewerbsrecht sind einzuhalten?
• Kundenservice: Haben die Mitarbeiter das erforderliche (technische) Wissen, um Kundenprobleme zu lösen? Ist der Service organisatorisch (z.B. Anzahl der Mitarbeiter) entsprechend aufgestellt?
• Business Development: Welche Anforderungen bestehen seitens Partnern?
• IT-Security: Welche Vorgaben sind einzuhalten?
• Finanzen: Können wir uns die Erstellung und den Betrieb des Produktes leisten? Wie sieht die Monetisierungsstrategie aus und ist sie so ausgelegt, dass sich das Produkt in absehbarer Zeit selbst trägt? Welche Finanzströme gibt es? Ist das Rechnungswesen in der Lage die Verbuchung der Einnahmen durchzuführen?

Um das Realisierungsrisiko zu testen müssen die Stakeholder aus den genannten Bereichen ganz genau verstehen wie die Lösung funktioniert. Jedes Bedenken aus den genannten Bereichen sollte sehr ernst genommen werden. 

Während der Validierung der Produktideen bzgl. der genannten Risiken sollten wir die folgenden Leitplanken beachten:

• Menschen können nicht einfach befragt werden was sie brauchen, da sie es selbst nicht wissen.
• Dennoch müssen wir unsere Ideen an realen Menschen testen und quantifizierbares und qualitatives Feedback einholen.
• Wir wissen, dass wir manche Dinge nicht wissen und nicht wissen können. Daher gehen wir davon aus, dass mindestens die Hälfte unserer Ideen nicht funktionieren wird.
• Somit müssen wir unsere Ideen auf dem schnellsten und kostengünstigsten Weg validieren der uns möglich ist. Hierzu stellen wir erforderliche Skills und Technologien sicher. 
• Da die meisten unserer Lösungsideen nicht funktionieren werden, ist es wichtig „to fall in love with the problem, not with the solution“. Wir halten am zu lösenden Problem fest und stellen unsere Lösungsideen immer wieder in Frage.
• Daher setzen wir keine Feature-Roadmaps auf, da wir nicht wissen können, welches der Features wirklich das Problem löst.
• Jede Idee validieren wir auch mit den Stakeholdern des Unternehmens, um herauszufinden, ob die Idee für das Unternehmen tragfähig ist.

Der Zweck eines Experiments ist es, etwas zu lernen und dabei weniger Zeit und Kosten zu verbrauchen, als wenn man die Idee vollständig entwickeln würde. Auch bei einem Experiment muss die Idee bereits tiefer durchdacht und konzipiert werden. Die Teammitglieder entwickeln dabei eine gemeinsame Vorstellung der Ausgestaltung der Produktidee. Hierbei können verschiedene Arten von Experimenten unterschieden werden, um die verschiedenen Risiken zu testen.

Machbarkeitsexperimente testen technische Aspekte wie Algorithmen, Performance, Skalierbarkeit, Fehlertoleranz, neue Technologien, Drittkomponenten oder die Abhängigkeiten zu anderen Systemen und Teams. Ist eines der Gebiete für das Team unbekannt, dann schafft ein Experiment Erkenntnisse und damit Sicherheit z.B. für eine Zeit- oder Kostenschätzung. 

Userinterface Prototypen (z.B. Klick-Dummys) unterschiedlicher Güte können genutzt werden, um dem Kunden die Lösung näher zu bringen und zu beobachten ob dieser diese versteht. Dieses qualitative Feedback kann aber nicht beweisen und sicherzustellen, dass das Produkt auch wirklich genutzt werden würde. 

Data beats opinion

Live-Data Prototypen müssen gut genug sein, um für einen speziellen Anwendungsfall echte Daten einzusammeln, um zu beantworten wie stark der Bedarf an der Produkitdee ist oder ob Nutzer bereit wären dafür zu bezahlen. Auch wenn dieser Prototyp produktiv für Endkunden verfügbar ist, ist es kein Produkt und wird wieder abgeschaltet, sobald die erforderlichen Daten vorliegen. 

In bestehenden Produkten kann zur Datensammlung der „fake door“ Test genutzt werden. Um eine neue Funktion zu testen, wird ein Button platziert, der aber nicht zu der Funktion, sondern zu einer Umfrage führt. Diese erklärt, dass man gerade überlegt diese Feature zu entwickeln und vorher noch ein paar Informationen der Nutzer benötigt. Zusätzlich wird angeboten, dass der Nutzer sich mittels E-Mailadresse registrieren kann, um z.B. nähere Informationen zu erhalten oder auf ein Interview eingeladen zu werden. Um diesen Test nicht für alle Nutzer auszuspielen, kann er mittels einem A/B-Test nur einem kleinen Teil der Besucher angeboten werden. 

Bei komplett neuen Produktideen bietet sich eine Landingpage an. Hierbei wird eine Website aufgesetzt, auf der die Produktidee beworben wird. Es wird ein Kaufen- oder Registrieren-Button angeboten. Gemessen wird dann das Verhältnis von Seitenbesuchern zu Registrierungen, um zu bestimmen ob die Produktidee einen Bedarf trifft.  

Mit den Live-Data Prototypen können quantifizierte Beweise gesammelt werden, ob es wirklich ein entsprechendes Kundenbedürfnis gibt. Ebenso kann eine Liste von Emailadressen, von Menschen die schon mal ein hohes Interessen an der Lösung haben, generiert werden. Vornehmlich funktionieren diese Tests für B2C Ideen, im B2B Bereich wird es vermutlich schwieriger sein eine hohe Anzahl an Leads zu generieren. 

Hybride „Zauberer von Oz“ Prototypen stellen ein funktionierendes Frontend zur Verfügung aber die Verarbeitung der eingehenden Daten oder Aufträge passiert manuell. Diese Prototypen sind nicht skalierbar und auf eine sehr kleine Nutzerbasis ausgelegt. Beispiel: Eine Frontend für Bestellungen wird entwickelt. Aber die Anbindung an das Backendsystem ist technisch noch nicht verfügbar. Mitarbeiter geben die eingehenden Aufträge manuell in das Backendsystem ein.  

Quantitative Tests werden klären ob eine Idee funktioniert oder nicht.

Aber nur qualitative Tests erklären warum eine Idee funktioniert oder nicht

und schafft so ein tieferes Verständnis für den Nutzer und Kunden.

In der Product Discovery werden Kundeninterview genutzt, um mehr über die Kunden zu lernen. Sind die Kunden so wie ich denke dass sie sind? Haben sie wirklich das Problem was ich denke das sie es haben? Wie lösen die Kunden dieses Problem heute, wo es das Produkt noch nicht gibt? Was wäre nötig, damit sie davon überzeugt sind zu wechseln und mein Produkt zu nutzen? 

Ein Interview läuft in den folgenden vier Phasen ab:

• Warm-Up: Stelle dich selbst vor und versuche eine Verbindung zu der Person aufzubauen. Frage ob du von dem Gespräch eine Audio- oder Videoaufnahmen erstellen kannst.
• Allgemeine Probleme: Frage die Person nach den Problemen die sie in Bezug auf den Bereich hat in dem das Produkt angesiedelt sein soll. Die Person soll allgemein über ihre alltäglichen Probleme aus dem Bereich erzählen und wie sie sich dabei fühlt.  
• Spezifisches Problem: Frage die Person nach Tipps und Tricks, um genau das spezifische Problem zu lösen was Du versuchst zu lösen. Frage danach wie stark das Problem ist und ob noch mehr Personen das Problem haben.
• Pitch die Idee: Erkläre der Person sehr sachlich Deine Lösungsidee und das Problem das du damit lösen möchtest. Frage danach ob sie auch das Problem hat und was sie über die Lösung denkt. Was ist ihre erste Reaktion und ihre ersten Worte? Frage danach welche Informationen sie braucht, um entscheiden zu können, ob sie es kauft oder nicht. Frage nach einer Preisspanne, die sie bereit wäre dafür zu bezahlen. Frage danach, ob sie schon von etwas ähnlichem gehört hat.

Folgende Personengruppen sollten für ein Interview kontaktiert werden:

• Personen die öffentlich im Internet kundgeben, dass diese das Problem haben was du lösen möchtest. Welche Aussagen machen Personen die das Problem haben bzw. welche Fragen haben diese?
• Influencer (z.B. Blogger oder Experten) die in dem relevanten Gebiet eine eigene Website betreiben.
• Kunden der Konkurrenz, die du über Twitter und Facebook findest.
• Personen die relevante Blogs, Foren, Artikel kommentieren sind am Problem stark interessiert und sich offen für Befragungen.
• Menschen die exakt in die Kundensegmentierung fallen. 

Bewertung der Ergebnisse

• Welche Probleme erwähnten die interviewten Personen?
• Ist dein Problem, was du versuchst zu lösen, in der Liste der genannten Probleme enthalten?
• Wie stark ist das Problem vertreten?
• Gibt es Muster in den genannten Problemen?

Hilfreiche Tools

• Streak.com ist ein CRM PlugIn für GMail und hilft dabei zu tracken mit welchen Personen du bereist in Kontakt warst.
• Bitly.com wandelt lange URLs in eine Kurzform um. Außerdem sieht man wie viele Personen den Link aufgerufen haben und welche Personen diesen geteilt haben.
• Mturk.com bietet die Möglichkeit kleine Tasks online zu stellen, die dann durch die Crowd gelöst werden. Diese Tasks können auch Interviews sein.
• Fivesecondtest.com: Uploade ein Bild, dieses wird für fünf Sekunden zufällig diversen Nutzern gezeigt, die dann einige Fragen dazu beantworten. Komprimiere deine Idee in genau einen Satz, präsentieren ein Bild davon und stelle geeignete Fragen. 
• Proved.co ein Umfrageservice.

In diesem Test lässt du dir von den potentiellen Nutzern und Kunden direkt zeigen, wie sie ihr Problem heute lösen und erledigst dann persönlich die Arbeit für sie, um einen tiefen Einblick in die aktuelle Erlebniswelt deiner zukünftigen Nutzer zu erhalten. Einige diese Nutzer kannst du vielleicht zu Referenzkunden entwickeln. 

Referenzkunden sind echte Kunden die ein produktives Produkt mit deren Geld gekauft haben und willens sind ihre Erfahrungen mit dem Produkt an andere weiter zu geben. Währenddessen wir unser Produkt entwickeln und entdecken, versuchen wir auch Referenzkunden für eine intensive Zusammenarbeit zu finden. Wir starten also sehr früh mit der Suche nach Referenzkunden, auch wenn wir noch kein fertiges Produkt haben. Die Referenzkunden sollten alle aus einem gemeinsamen Zielmarkt und derselben Zielgruppe stammen. Referenzkunden müssen willens sein, selbst Zeit zu investieren, um mit uns am Produkt zu arbeiten. Der Vorteil für die Kunden ist, dass sie stark involviert sind und einen gewissen Einfluss nehmen können. Wir suchen hier nach Menschen die ein schwerwiegendes Problem haben und bereit sind an der Lösung mitzuarbeiten. Sollten wir keine Referenzkunden finden, dann ist dies ein erstes Indiz dafür, dass wir versuchen ein nicht signifikant vorhandenes Problem zu lösen. 

Eine Entdeckungsreise in unbekannten Gewässern ist ein anstrengendes Unterfangen für die Besatzung. Mehrere Prototypen werden erstellt werden, viele Interviews mit positiven und negativen Feedback wird es geben und viele Daten sind zu interpretieren. Um die Zuversicht zu behalten ist es wichtig den Aktivitäten einen positiven Rahmen zu geben. Im StartUp zählt nichts mehr als so schnell wie möglich zu einem fertigen Produkt zu kommen, welches die Bedürfnisse eines initialen Marktes trifft, bevor die Finanzierung ausläuft. In etablierten Unternehmen ist oft eine der größten Schwierigkeiten, dass das Produktteam nicht sieht wie ihr Produkt zum großen Ganzen beiträgt. 

Customer Letter

Für Produktaktivitäten die einen großen Umfang haben, mehrere Business Ziele erreichen sollen und dabei mehrere Kundeprobleme und Zielgruppen gleichzeitig angehen, braucht es eine Vision, um den Rahmen zu setzen. Ein fiktiver Kundenbrief bietet die Möglichkeit diese Vision bildlich zu transportieren. Der fiktive Kundenbrief wird vom Product Owner aus der Perspektive eines sehr zufriedenen Kunden geschrieben und beschreibt wie das Produkt das Leben des Kunden positiv verändert und verbessert hat. Der Brief beinhaltet eine fiktive Antwort der Geschäftsführung an das Produktteam, die erklärt, wie dies dem Unternehmenserfolg hilft.

Canvas

Ein Cancas zeigt auf einer Seite alle wesentlichen Information, die das Produktteam im Auge behalten muss. Wenn es darum geht ein vollkommen neues Produkt zu entdecken, dann biete sich der Lean Canvas an, auf welchem die folgenden Informationen abgebildet werden:

• Probleme der Kundenzielgruppe
• Aktuell existierende Lösungsalternativen
• Beschreibung der neue Lösung
• Schlüsselmetriken zur Messung ob es einen Bedarf an der Lösung gibt.
• Die Unique Value Proposition beschreibt warum die neue Lösung signifikant besser ist als bestehende.
• Die Unfair Advantage sagt aus welchen nicht kopierbaren Vorteil das Projektteam gegenüber der Konkurrenz hat.
• Beschreibung der Vertriebskanäle und der Zielkundensegmente
• Kostenstruktur mit allen fixen und variablen Kosten    
• Auflistung aller Umsatzquellen

Geht es darum ein bestehendes Produkt weiterzuentwickeln, kann der Opportunity Canvas genutzt werden. Er gibt Aufschluss über zu Business Ziele, anhand welcher Metriken deren Erreichung gemessen wird, welches Kundenproblem mit welcher Lösungsidee adressiert und auf welche Kundenzielgruppe/ Nutzerzielgruppe sich fokussiert wird. 

Roadmaps sollen dem Management Sicherheit und Vertrauen geben, dass das Produktteam immer an den aktuell wichtigsten Themen arbeitet. Ebenso sollen sie Planbarkeit für den Rest des Unternehmens sicherstellen, damit dieses vorher informiert ist, wenn kritische Dinge passieren. Das Hauptproblem mit Roadmaps ist dabei, dass sobald diese Liste von Ideen bekannt gegeben wird, wird es immer Menschen im Unternehmen geben, die diese Liste als gesetzt ansehen und darauf pochen werden, dass diese Ideen umgesetzt werden.

The truth is that at least half of our ideas are just not going to work.

Doch mindestens die Hälfte der Ideen die auf einer Roadmap stehen werden nicht die erhofften Ergebnisse erzielen. Hierfür kann es viele Gründe geben, die im Zusammenhang mit den erwähnten Risiken stehen. Starke Produktteams werden diese Risiken früh validieren und beweisen, dass diese überwunden werden können oder falls nicht, werden sie die Idee früh stoppen. Auf einer Roadmap die auf Produktideen passiert wird es also wöchentlich Änderungen geben und diese Volatilität strahlt keine Sicherheit und Planbarkeit aus. 

You can release all the features you want,

but if it does not solve the underlying business problem,

you have not really solved anything.

Als Alternative zu Roadmaps (Sammlung konkreter Ideen) können eine gute Produktvision, Produktstrategie sowie konkrete OKRs (Business Objektives & Key-Results) die benötigte Sicherheit und Planbarkeit sicherstellen. 

Fall in love with Problem, not with the solution.

Die Produktvision beinhaltet Langzeitziele und ist auf zwei bis fünf, manchmal zehn Jahre ausgerichtet. Sie sollte inspirierend, begeisternd und sinnstiftend wirken und damit die Frage nach dem „Warum“ beantworten. Sie enthält keine konkreten Features sondern beschreibt wie sich die Welt der Menschen verändert hat, wenn das Produkt wahr geworden ist. 

We need to discover the product to be built,

and we need to delivers that product to market.

Die Produktstrategie ist ein grober Plan für die gezielte Einführung des Produktes in unterschiedlichen Zielmärkten und für unterschiedliche Kundengruppen. Hauptziel ist es, dass sich das Team zu jederzeit nur auf einen Markt und eine Zielgruppe fokussieren kann. Die Strategie beschreibt ebenso wie Risiken validiert werden und wie Kunden und Nutzer sowie die Unternehmensbereiche Sales, Marketing, Finanzen und Kundenservice in der Produktentwicklung beteiligt werden. 

Where the product vision describes the future you want to create,

and the product strategy describes your path to achieving that vision,

the product principles speak to the nature of the product you want to create.

Produktprinzipien Runden die Produktvision und Produktstrategie ab. Sie erklären die grundlegende Natur des gewollten Produktes und was erreicht werden soll. Prinzipien sind keine Produktfeatures und sind nicht Abhängig von Releases. Ein Beispiel könnte sein: Sollte es kontroverse Interessen von Zielgruppen geben, welcher Zielgruppe geben wir im Zweifel immer den Vorrang? Daraus könnte ein Prinzip definiert werden, was die Entscheidungsfindung z.B. in den Bereichen Design und Konzeption vereinfacht und beschleunigt. 

It is not about implementing features,

it is all about achieving goals by solving the underlying problem.  

OKRs sind eine qualitative Beschreibung was das Team erreichen soll (Objektives) gepaart mit quantitativen, messbaren Geschäftszielen (Key-Results). Dem Team wird vollständig überlassen mit welche Maßnahmen und Features sie diese Ziele erreichen. Der Unterschied zu Roadmaps liegt darin, dass jetzt Geschäftsziele priorisiert werden und nicht mehr einzelnen Produktfeatures. Das Team hat hierdurch mehr Freiheit in der Ausgestaltung der Lösung, ist aber auch stärker gebunden die richtige Lösung zu finden und zu liefern, um das Geschäftsziel zu erreichen.

Never tell people how to do things.

Rather tell them what to achieve and

they will surprise you with their creativity.