Der Build-Measure-Learn-Zyklus ist eine der zentralen Bausteine von leanem Vorgehen und taucht das erste Mal in The Lean Startup von Eric Ries auf. Es geht im Grunde darum, aus Ideen schnell etwas Benutzbares zu entwickeln (build), Datenpunkte über das Produkt zu sammeln (measure), Erkenntnisse aus diesen Daten zu generieren (learn) und diese Erkenntnisse in die nächste Iteration einfließen zu lassen. Viele Innovationsvorhaben, -methoden und -frameworks orientieren sich an diesem Prinzip oder einer Abwandlung dessen.

Build, Measure und Learn sind abhängig vom erhofften Erkenntnisgewinn

Dabei befinden sich unsere Kunden häufig an sehr unterschiedlichen Punkten im Innovationsprozess, wenn sie das erste Mal auf uns zu kommen: Teilweise ganz am Anfang, teilweise mittendrin und manchmal sogar mit ähnlichen Projekten gleichzeitig an verschiedenen Punkten.

Der hilfreichste nächste Schritt für das Projekt ist jedes Mal individuell, aber analog zu Ries’ Modell fast immer davon abhängig, was denn der erhoffte Erkenntnisgewinn ist, also: Was wir eigentlich lernen wollen.

Ist das Wertversprechen unseres existierenden MVPs tatsächlich so attraktiv, wie wir glauben und treffen wir auf Zahlungsbereitschaft? Gibt es überhaupt Nachfrage nach der Lösung, für die wir derzeit planen, eine mittlere 6-stellige Summe in Hardware zu investieren? Bei welchem Preis und mit welcher Erfolgswahrscheinlichkeit können wir unsere App profitabel am Markt platzieren? All das sind typische Fragen, die entstehen können und die sich gezielt mit Testballons untersuchen lassen.

Das Verhältnis von Aufwand und Erkenntnis in Innovationsvorhaben lässt sich steuern

Das heißt, dass wir letztlich gemeinsam mit unseren Kunden ganz unterschiedliche Artefakte schaffen. Diese sind abhängig davon, welche Erkenntnis für den aktuellen Stand des Projekts entscheidend ist für die Wahl des nächsten Schrittes oder um eine Entscheidungsgrundlage zu schaffen.

Diese Artefakte können sich insbesondere in ihrem Umfang extrem voneinander unterscheiden und stellen deswegen auch finanziell eine kleinere oder größere Investition dar: Während ein größeres Softwareentwicklungsprojekt schnell teuer sein kann, lassen sich einige der für die aktuelle Phase wichtigsten Erkenntnisse auch ganz ohne Code gewinnen.
Ein sogenanntes Fake Doors MVP beispielsweise eignet sich ausgezeichnet, um erste Abschätzungen darüber zu treffen, ob Problemwahrnehmung im Markt besteht, wie teuer die Akquise und Konversion von Nutzern ist und welche Zahlungsbereitschaft existiert.

Ein extremes Gegenbeispiel wäre die Umsetzung eines großen innovativen Multimillionen-Softwareprojekts, basierend auf der reinen Überzeugung der Entscheidungsträger; ein Sprung ins Ungewisse. Die möglichen Erkenntnisse sind hierbei stark abhängig davon, wie erfolgreich das Produkt tatsächlich ist. Schlägt beispielsweise bereits die Ansprache fehl, beschränkt sich das Learning zunächst darauf, dass wir die Kommunikation der Value Proposition unseres Produkts verbessern müssen. Das heißt, der Erkenntnisgewinn ist davon abhängig, wo ein Kunde oder eine Kundin in der Customer Journey abspringt. Gerade weil Softwareprojekte aufgrund ihrer Komplexität häufig so aufwendig sind, führt jede Ungewissheit über den Erfolg am Markt zu einem großen Investitionsrisiko. Und gerade deswegen ist es so wichtig, die Erkenntnisse schrittweise zu sammeln.

Fake Door MVP vs. Multimillionen-Projekt

Der Kontrast zwischen diesen beiden unterschiedlichen Vorgehensweisen soll folgendes illustrieren:

1. Unterschiedliche Artefakte (Software, Landing Page, Clickdummies, etc.) mit jeweils sehr unterschiedlichen Aufwänden können ganz unterschiedliche Erkenntnisse zu Tage fördern. Außerdem können diese Artefakte ganz unterschiedlicher Natur sein. “Build” kann hierbei also auch die Form qualitativer Validierung durch Interviews annehmen, wenn es der aktuellen Phase dienlich ist (eine ausführliche Unterscheidung verschiedener Validierungsansätze würde den Rahmen dieses Artikels sprengen, weswegen sie Teil eines zukünftigen Artikels werden soll).

2. Das bedeutet, dass wir das Verhältnis zwischen Erkenntnis und Aufwand beeinflussen können: Nämlich durch eine kluge Wahl der Experimente und Hypothesen, die wir testen wollen und deren Ergebnisse uns weiterbringen, sowie die bewusste Entscheidung für das kleinstmögliche Artefakt, das uns zu diesen Ergebnissen führt.

Für die aktuelle Projektphase das Optimum rausholen

Dass hinter jedem neuen Produkt eine Unsicherheit liegt, war uns intuitiv bewusst. Dass eine der zentralen Aufgaben in der Innovationsberatung darin liegt, das Risiko, das sich aus dieser Unsicherheit ergibt, zu senken, hat sich so klar erst mit der zunehmenden Projekterfahrung geschärft.

Am Ende stehen sich hinter jedem Build-Prozess im Build-Measure-Learn-Zyklus Investition und Erkenntnisgewinn gegenüber. Wir können das Verhältnis beeinflussen, da wir uns erstens klar machen können, welche Erkenntnis wir in der aktuellen Projektphase benötigen und zweitens den nächsten Projektschritt bzw. das nächste zu erstellende Artefakt so wählen können, dass es uns diese Erkenntnis bei minimalem zeitlichen und finanziellen Aufwand liefert.

Das wiederum heißt, dass wir das Investitionsrisiko für innovative Softwareprodukte durch ein schrittweises Vorgehen, evidenzbasierte Entscheidungsfindung und schlanke MVPs deutlich senken können.

Deine Idee auf Erfolgskurs?

Als Spezialisten für iterative Innovationen helfen wir Innovatorinnen und Innovatoren dabei, ihre Software zwar groß zu denken, aber in kleinen Schritten erfolgreich ans Ziel zu bringen. Wir unterstützen bei der Ideenfindung, identifizieren die größten Risiken der Idee, regen zu evidenzbasierten Entscheidungen an bauen einen ersten Prototypen. Schreib’ uns einfach eine Mail!

Du kennst den nächsten Schritt schon? Wir setzen ihn um!

Starte durch in Sachen Digitalisierung mit unserem Digital Kickoff.