Validiertes Lernen über die Kunden ist das Maß des Fortschritts in einem Lean Startup – und nicht etwa funktionierende Code-Zeilen oder das Erreichen von Meilensteinen in der Produktentwicklung.
Werfen wir also mal einen Blick darauf, wo im Produktentwicklungsprozess wir es mit dieser Art des Lernens zu tun haben.
Wo wir etwas über den Kunden lernen
Während wir einige Dinge schon im Anforderungsstadium lernen (forciert durch die Customer-Development-Aktivitäten), findet der größte Erkenntnisgewinn statt, nachdem ein Release ausgeliefert worden ist – und weniger während der eigentlichen Entwicklung oder der Qualitätssicherung.
Auch wenn die Entwicklung eines Produkts die Bestimmung eines Lean Startups ist, steht sie dem Lernen über die Kunden tatsächlich im Wege.
Nun können wir Entwicklung und Qualitätssicherung nicht einfach weglassen und das Lernen über die Kunden in diesen Phasen auch nicht intensivieren, doch wir können die Zykluszeiten von den Anforderungen bis zum Release verkürzen, um schneller zum Lernen-Teil zu kommen. Genau das ist das Ziel von Continuous Deployment.
Ich habe meinen Übergang von traditionellen Entwicklungsprozessen hin zu Continuous Deployment bereits in einer Fallstudie in Eric Ries’ Blog Startup Lessons Learned beschrieben. Das Kernkonzept von Continuous Deployment ist der Wechsel von großen auf kleine Batch-Größen. Für mich bedeutete dies einen Wechsel von 14-täglichen zu täglichen Releases. Man kann ein Feature nicht immer an einem Tag fertigstellen, aber man wird gut in der inkrementellen Entwicklung und darin, zuerst für den User unsichtbare Features zu deployen. Die Resultate waren eine sofortige und spürbare Optimierung der Zykluszeiten, eine Beschleunigung des Feedbacks und vor allem mehr Zeit für nicht-produktbezogene Entwicklungsaktivitäten wie das Lernen.
Aber selbst mit einem stromlinienförmigen Produktentwicklungs-Flow – wie lässt sich sicherstellen, dass wir etwas erschaffen, das die Kunden wollen, und nicht einfach nur Features schneller raushauen?
Hier ein paar Regeln, denen ich folge.
Wie ich Features baue
Regel 1: Sei kein Feature-Anschieber
Wenn Sie einen Customer-Discovery-Prozess durchlaufen, ein Problem, dass sich zu lösen lohnt, gefunden und als Ergebnis ein Minimum Viable Product definiert haben, pushen Sie keine neuen Features, ehe Sie das MVP validiert haben. Das bedeutet nicht, die Entwicklung einzustellen, doch die meiste Zeit sollte damit verbracht werden, bestehende Features zu bewerten und zu verbessern, statt hübschen neuen Funktionen nachzujagen.
Aus Erfahrung weiß ich, dass dies schwer umzusetzen sein kann. Viele von uns messen Fortschritt immer noch in Form von Code-Zeilen und glauben, dass unsere Probleme in Sachen Zugkraft darin begründet liegen, dass wir die richtigen Killer-Features noch nicht gefunden haben. Die nächste Regel hilft hier.
Regel 2: Die Feature-Pipeline beschränken
Eine gute Methode, um die 80/20-Regel zu befolgen, besteht darin, die Feature-Pipeline zu begrenzen – ein gängiges Vorgehen aus der agilen Praxis, das aber um ein Stadium des validierten Lernens für jedes Feature erweitert wird.
Idealerweise sollte ein neues Feature von mehr als einem Kunden verlangt werden, damit es Aufnahme in das Backlog findet. Es ist okay, mit einigen neuen Funktionen herumzuexperimentieren, die Ihnen so in den Kopf kommen, aber ich suche und finde immer Wege, um sie erst mit ein paar Kunden zu testen (im Rahmen einer Demo oder einer Produktpräsentation), ehe ich sie in das Backlog aufnehme.
Leidenschaft hinsichtlich einer Vision ist gut.
Leidenschaft hinsichtlich der Entwicklung von etwas, das der Kunde will, ist besser.
Die Anzahl der In-Progress-Features ist durch die Anzahl der Entwickler begrenzt, und so ist das auch bei Features, die auf Validierung warten. Dies stellt sicher, dass Sie nicht an einem neuen Feature arbeiten, ehe ein zuvor ausgeliefertes validiert ist.
Regel 3: Den Kreislauf erst mit qualitativen Metriken schließen
Da es einige Zeit dauert, quantitative Metriken zu sammeln, empfehle ich, alle neuen Funktionen zuerst qualitativ zu validieren. Wenn ein starkes Anfangssignal ausbleibt, wird die Funktion direkt begraben. Ansonsten lebt sie, bis die quantitativen Daten reinkommen.
Um qualitatives Feedback zu bekommen, kontaktiere ich nach dem Go-live den (oder die) Kunden, der oder die das Feature angefragt haben, und bitte um Feedback. Folgt man Erics Rat, sich auf Makro-Effekte zu fokussieren, reicht es nicht aus, nur den Coolness-Faktor des Features zu bewerten. Vielmehr sollte man testen, ob die Funktion ein Kundenproblem löst und – noch viel wichtiger – ob es Abschlüsse generiert. Ich tendiere auch dazu, neue Features in User-Tests und in regelmäßig erscheinenden Release-Update-Newslettern besonders herauszustellen, sodass sie mehr Aufmerksamkeit erhalten.
Auf der quantitativen Seite nutze ich nach wie vor eine Kombination aus KISSmetrics und Mixpanel, um Nutzungsdaten für das Feature zu sammeln.
Kontra-intuitiv?
Einige dieser Ideen wie die Arbeit mit kleinen Batch-Größen, die restriktive Feature-Pipeline und das Erzwingen eines Stopps, wenn wir nichts lernen, erscheinen zunächst kontra-intuitiv. Die meisten von uns kennen nichts anderes, als sich auf die Arbeit in Abteilungen wie Entwicklung, Qualitätssicherung und Marketing zu spezialisieren – wir werden zu effizienten Large-Batch-Entwicklungsmaschinen, die unter Volllast laufen.
Doch dieser Ansatz des Arbeitens funktioniert heute nicht mal mehr in der produzierenden Welt, obwohl die Aufgaben hier vorhersagbarer (weniger variabel) und wiederkehrend sind. In der Software-Entwicklung gibt es dagegen extrem viele Variablen und Probleme mit großen Batches verschärfen sich immer weiter. Wer sich in die technischen Hintergründe dessen einlesen möchte, dem empfehle ich Donald Reinersteins Buch The Principles of Product Development Flow.
In der Produktentwicklung eines Lean Startups geht es nicht mehr nur um den Code. Alle sind dafür verantwortlich, dass wir von den Kunden lernen.
Hinweis: Wenn Sie tiefer in dieses Thema einsteigen möchten, könnte mein Buch hilfreich sein. Running Lean widmet 50 Seiten allein diesen Aspekten.
