Im Rahmen eines Lean Start-ups werden Hypothesen, also Annahmen, aufgestellt und diese systematisch in sogenannten Build-Measure-Learn-Zyklen validiert. Dabei gibt es Start-ups nicht nur im freien Markt, sondern die Methode findet auch innerhalb von Konzernen Anwendung. Wie funktioniert das?Nehmen wir einmal folgende Beispielhypothese für eine Idee im IT-Umfeld eines Konzerns an: „Wenn die Kunden (Mitarbeiterinnen und Mitarbeiter einer bestimmten Abteilung) unsere Software nutzen, sparen sie 20 % der Zeit, die sie heute benötigen, um zum gleichen Ergebnis zu kommen.“ Klingt doch vielversprechend, oder?Doch es gibt ein paar Stolperfallen, die es zu beachten gilt. Start-ups, drinnen wie draußen, müssen gerade zu Beginn mit extrem wenig Budget auskommen. Häufig begehen diese dann den Fehler, so von der Idee überzeugt zu sein, dass sie sofort mit der Umsetzung der (vermeintlichen) Lösung beginnen. Im hypothetischen Fall unseres Beispiels startet man mit der Programmierung einer entsprechenden Software. Das vorhandene Budget wird investiert und später stellt sich heraus, dass man am eigentlichen Kunden vorbei entwickelt hat.
Hinsichtlich der Verringerung dieses Risikos ist es sinnvoll, zunächst nur Annahmen aufzustellen, welche die eigentliche (Haupt-)Hypothese stützen, und diese mit ganz einfachen Methoden zu überprüfen. Trifft eine der Annahmen nicht zu, kann man die Idee bereits entsprechend anpassen, noch bevor etwas Kostspieliges gebaut wurde.Dabei sollte man sich zwei Fragen stellen:
Bedenke:
(Zitat von Ywan van Loon)
Bevor man also echte Lösungen baut, sollte man zunächst die richtigen Fragen stellen, um sicherzustellen, dass man am Richtigen arbeitet. Empfehlenswert ist es dabei, Interviews mit potenziellen Usern zu führen. Damit man sich in dieser Phase entsprechend fokussieren kann, hilft das sogenannte Value Proposition Canvas.
Grafik: StrategizerTipp für die Praxis: Das Canvas auf DIN-A0-Größe ausdrucken und mit der rechten Seite (Customer) beginnen. Im Team dann mit Post-its die Annahmen zum Kunden sammeln und die folgenden Fragen beantworten:
Ein Beispiel für die Annahme eines echten Schmerzes wäre: „Um meine Arbeit machen zu können, muss ich in fünf verschiedenen Systemen Informationen zusammensuchen. Das macht mich extrem langsam.“Danach führt kein Weg daran vorbei, hinaus zu den Usern/Kunden zu gehen und die Annahmen durch entsprechende (offene) Fragestellungen zu validieren, z. B.: „Was behindert dich am meisten bei deiner Arbeit?“ Gibt es noch weitere Kunden, die ähnliche Probleme haben, kann man vielleicht sogar unterschiedliche Kundensegmente identifizieren, die es zu betrachten gilt. In diesem Fall kann man pro Kundensegment ein separates Canvas erstellen.Durch den direkten Kontakt mit den Nutzern ergeben sich oft ganz neue Erkenntnisse, die dann im linken Teil des Canvas zu ganz neuen oder passenderen Produktideen führen können. In unserem Beispiel ist es vielleicht nicht nur das Bündeln von notwendigen Informationen, sondern auch das mobile Arbeiten, das eine echte Zeitersparnis bringt.
Wenn man einmal soweit ist, dass die Annahmen vom User bestätigt wurden, ergibt es Sinn, den nächsten Schritt zu gehen und mit einem einfachen Prototypen zu testen, ob sich das Gesagte auch mit dem tatsächlichen Verhalten deckt. Meiner Erfahrung nach ist es zu wenig, nur nachzufragen, ob jemand eine Software nutzen würde. Man muss anhand eines konkreten Prototyps einfach einmal ausprobieren, ob die Kunden einen Nutzen darin sehen. Bezogen auf unser Beispiel wäre ein Klick-Dummy – so etwas ist heute mit kostenlosen Handy-Apps in wenigen Minuten erstellt – mit vielleicht 5 ausgewählten Informationen, die in den geführten Interviews als wichtig erschienen, eine mögliche Variante, um zu validieren, ob und wie die Nutzer mit einem Tool arbeiten würden.Sicher ist es sinnvoll, grundsätzlich in Ergebnissen und Lösungen zu denken. Zu früh mit der Umsetzung zu starten, kann aber teuer werden und führt oftmals dazu, dass man am Kunden vorbei entwickelt und damit das Falsche liefert.