Do things that don’t scale: MVP ohne Softwareentwicklung – geht das?

Der Begriff Minimum Viable Product (kurz MVP) ist im Mainstream angekommen und wird  insbesondere im Kontext digitaler Produkte gerne verwendet. Im Umfeld der Softwareentwicklung wird der strategische Spielraum zum Einsatz eines  MVP dabei häufig auf die erste Version eines Softwareprodukts reduziert. In diesem Artikel stelle ich eine mögliche Umsetzung eines MVP jenseits von Softwareentwicklung vor und erörtere, warum diese Formen von MVP elementarer Bestandteil im Werkzeugkasten moderner Produktmanager sein sollten.

Der Aufstieg des MVP

In der Digitalisierung spielt neben der Transformation bestehender Geschäftsmodelle, – prozesse und -strukturen vor allem die Innovation, die Suche nach neuen, digitalen Geschäftsmodellen, eine entscheidende Rolle. Amazon, Airbnb oder Tesla, um nur einige wenige bekannte Beispiele zu nennen, drohen, lange etablierte Märkte in ihren Grundfesten zu erschüttern oder haben es bereits.

Um in diesem Wettbewerb der digitalen Innovationen zu bestehen, orientieren sich Unternehmen zunehmend an den schlanken, kundenzentrierten und datengetriebenen Methoden, die in den letzten Jahren durch eben jene und andere massiv erfolgreiche Startups populär wurden. Allen voran ist hier “The Lean Startup” zu nennen, dessen prominentestes Beispiel für eine Konzern-Adaption “FastWorks” des amerikanischen Giganten General Electric ist. Warum identifizieren sich etablierte Unternehmen aber mit einer Methode, die dem Namen nach offensichtlich für Startups entworfen worden ist? Betrachten wir dazu einmal die Definition des Autors, Eric Ries:

A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.

Diese Definition bezieht sich nicht auf Faktoren, wie die Dauer des Bestehens eines Unternehmens, sondern einzig auf die Umstände, in denen eine Unternehmung oder Institution operiert. Damit sind vor allem etablierte Unternehmen, die sich auf neuen oder unbekannten Märkten bewegen, explizit mit eingeschlossen. Eine Tatsache, die auch Eric Ries selber betont. Was hat es also mit dieser Methode auf sich?

Lean Startup ist inspiriert durch zahlreiche bewährte Ideen und Methoden, wie beispielsweise Design Thinking, Agile Engineering, Lean Production/Management oder Customer Development von Steve Blank. Das wichtigste Kernkonzept ist jedoch angelehnt an die “Wissenschaftliche Methode”:

1. Beobachte und beschreibe ein Phänomen.
2. Formuliere eine Hypothese, die das Phänomen erklärt.
3. Verwendet die Hypothese, um die Ergebnisse weiterer Beobachtungen vorherzusagen.
4. Messe die Qualität der Hypothese und der resultierenden Vorhersage durch angemessene Experimente.

Die Adaption der Wissenschaftlichen Methode nach Lean Startup ist der sogenannte “Build-Measure-Learn” Zyklus.

Abbildung 1: Build-Measure-Learn Zyklus

Hypothesen bzw. Ideen zu einem Produkt oder Geschäftsmodell werden formuliert, es wird ein Experiment implementiert, um diese Ideen zu validieren, und die resultierenden Ergebnisse werden als Input für die nächste Iteration verwendet.

Dieses Vorgehen trägt der Tatsache Rechnung, dass die Entwicklung von Produkten und Services – sobald man unter den zitierten Bedingungen hoher Unsicherheit operiert – immanent durch Annahmen und nicht durch Wissen getrieben ist. Durch rigoroses Testen dieser Annahmen am Zielmarkt wird dieses Wissen erst erworben. Dadurch erhöht sich die Chance, ein perfekt auf den Markt zugeschnittenes Produkt zu entwickeln (Product-Market-Fit). Oder aber man stellt frühzeitig fest, dass ein Produkt oder ein Geschäftsmodell nicht funktioniert und spart sich weitere kostspielige Fehlinvestitionen (fail fast and smart).

Die hier dargestellte Strategie hat einen guten Grund. Eine Studie von CB Insights mit 101 gescheiterten Startups in 2014 hat ergeben, dass der Hauptgrund für das Scheitern mit 42% ein fehlender Bedarf am Markt war.

Abbildung 2: CB Insights Studie

Ein elementares Werkzeug in der Lean-Startup-Methode, um genau dieses Risiko zu adressieren, ist das Minimum Viable Product. Aus diesem Grund erfreut sich das MVP steigender Aufmerksamkeit und Beliebtheit.

Was vom MVP übrig blieb

Die Bezeichnung Minimum Viable Product wird im Allgemeinen auf Frank Robinson (CEO, SyncDev) zurückgeführt. Maßgeblich geprägt wurde der Begriff jedoch, wie bereits erwähnt,  von Eric Ries in dessen Buch “The Lean Startup”. Eine seiner frühesten Definitionen stammt aus Ries’ Blog “Startup Lessons Learned” , den er überwiegend als Vorlage für sein 2011 erschienenes Werk verwendete:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

In den Hochglanzfolien zur neuen Digitalstrategie – vornehmlich der IT-Abteilungen – zahlreicher Unternehmen wird die Interpretation des Begriffs MVP hingegen oft deutlich enger umrissen. Hier ist in verschiedenen Abwandlungen und Ausprägungen von der “ersten Version einer Software mit minimalem Feature-Set” die Rede, die “iterativ” weiterentwickelt wird. Das klingt zunächst wunderbar einfach und präzise, vor allem aber bekannt. Insbesondere im Kontext agiler Softwareentwicklung drängt sich nämlich die Frage auf, was an diesem Konzept originell, neu und anders sein soll. Man mag argumentieren, dass Eric Ries als Softwareentwickler stark durch die Ideen aus der agilen Softwareentwicklung, insbesondere eXtreme Programming von Kent Beck , geprägt wurde.

Ein Blick auf die zitierte Definition offenbart jedoch eine weitere mögliche Erklärung: Zunächst einmal ist die Abbildung des Begriffes “Produkt” auf “Software” allein bereits eine stark limitierte Interpretation im Sinne der Definition. Entscheidender ist jedoch die Frage, inwiefern eine Software dem Kriterium des “geringsten Aufwands” genügt, der für den maximalen Lernumfang investiert werden soll.

Natürlich ist ein Softwareprodukt durch seine Skalierbarkeit und Reichweite eine valide und sehr wertvolle Möglichkeit die Kernhypothesen eines Geschäftsmodells zu testen und daher ein guter Kandidat für ein MVP. Es ist jedoch wichtig zu wissen, dass es nur eine unter mehreren möglichen Varianten ist. Insbesondere bei komplexen Geschäftsmodellen – beispielsweise bei einer komplexen Wertschöpfungskette, die viele verschiedene Stakeholder umfasst – kann es elegantere, schnellere, wenn auch schlechter skalierende Methoden geben, um zu lernen, ob das Produkt tatsächlich einen Markt hat oder was ihm fehlt, um den Product-Market-Fit zu erreichen.

Joe Gebbia, einer der Gründer der Plattform Airbnb , lässt sich gerne zitieren , dass eine der wichtigsten Lektionen, die ihnen Y-Combinator Gründer Paul Graham mit auf den Weg gegeben hat, folgende gewesen ist: “Do things that don’t scale” . Auf diesen Rat hin hat Airbnb in seinen Anfängen intensiv den persönlichen Kontakt zu seinen ersten Kunden gesucht und dabei gelernt, dass attraktive Fotos der angebotenen Appartements ein Schlüssel für den späteren Erfolg der Plattform und somit ein wichtiger Baustein für den Product-Market-Fit sein sollten.

Tatsächlich wird dieser Ratschlag jedem jungen Gründer im Y-Combinator mit auf den Weg gegeben. Genau diese Prämisse, auch nicht skalierbare “Dinge” zu tun, lässt sich hervorragend auf die Wahl der Strategie für ein MVP anwenden.

In den letzten Jahren hat es zahlreiche Beispiele für junge, digitale Unternehmen gegeben, die ihre Produktidee bereits erfolgreich validieren konnten, bevor sie ein skalierbares Softwareprodukt entwickelt hatten. Aus diesen Beispielen haben Eric Ries und andere Autoren Muster extrahiert, die als Blaupause für das Design eines MVPs verwendet werden können.

MVP-Typen

Ein gängiges Vorurteil über das MVP ist, dass der Begriff nur eine neue, kunstvolle Umschreibung für ein unfertiges und schlechtes Produkt ist.

Sicher ist der Begriff nicht ideal und gibt Anlass zu Diskussionen. Nicht umsonst ist es inzwischen fast zu einem Wettbewerb geworden, Alternativvorschläge oder weitere Abgrenzungen – wie z.B. MSP (Minimum Sellable Product), MMP (Minimum Marketable Product) oder MLP (Minimum Learnable Product) – zu definieren.

Letztlich ist die Bezeichnung MVP aber am weitesten verbreitet und gut genug, wenn klar ist, was ein gutes MVP ausmacht.

Abbildung 3: Attribute eines MVP ¹

Ein MVP sollte nicht nur eines der Attribute Machbarkeit, Nützlichkeit, Nutzbarkeit und Attraktivität erfüllen, sondern alle (siehe Abbildung 3). Außerdem sollte es den Zweck erfüllen, die risikoreichsten Hypothesen zum Produkt/Geschäftsmodell zu validieren und idealerweise vom ersten Tag an nachweisen, dass Kunden bereit sind für das Produkt zu zahlen ² . In diesem Sinne umschreibt die deutsche Übersetzung “lebensfähig” für “viable” den Anspruch an ein MVP vermutlich am besten.

Die wichtigste Komponente eines MVPs ist allerdings die Zeit. “The only way to win is to learn faster than anyone else. – Eric Ries”³ Zeit ist der entscheidende Faktor, um ein Produkt erfolgreich vor der Konkurrenz an den Markt zu bringen.

Die Kunst ist daher bei der Wahl des MVP eben dem Kriterium des “geringsten Aufwands” zu genügen, um die Zeit, die bis zur Validierung oder Invalidierung von Hypothesen und damit zum Lernen vergeht, zu minimieren. Die folgenden MVP-Typen sind Beispiele für eine Reduktion des Aufwands durch den gezielten Verzicht auf die Entwicklung von Software.

Concierge MVP

Beim Concierge MVP wird statt eines fertigen Produktes mit automatisierten Prozessen ein Produkt oder Service angeboten, der vollständig manuell ist. Dabei durchläuft der Kunde des Produktes alle Schritte, die er auch in der fertigen Lösung durchlaufen würde. Aus Kundensicht wird also ein vollständig “funktionsfähiges” Produkt angeboten, das lediglich begrenzt skalierbar ist.

Beispiel

Das Düsseldorfer Startup pillbox ist 2016 aus dem ersten Düsseldorfer Startup Sprint hervorgegangen. Die Gründer hatten die Vision, die Sicherheit und Einnahme von Medikamenten durch eine neue Art der Verpackung (Schlauchverblisterung mit Box – siehe Abb. 4) und Wechselwirkungschecks maßgeblich zu verbessern.

Zusätzlich sollten den Kunden digitale Services angeboten werden, die ihnen die Beschaffung von Medikamenten bei der Apotheke nach der ersten Verschreibung oder bei Folgerezepten vollständig abnehmen sollte (siehe Abbildung 5).

Abbildung 4: Die Pillbox

Ein erstes, nutzbares  Softwareprodukt mit diesen Services würde potenziell verschiedene Stakeholder entlang der Wertschöpfungskette mit einer sehr heterogenen Landschaft an IT-Systemen einbinden müssen. Angefangen beim Endnutzer und dessen Smartphone oder anderem Endgerät über den Arzt mit unterschiedlichen Technologien für die Übermittlung der Rezepte und die Apotheke oder einen eigenen angestellten Apotheker bis hin zum Blisterzentrum und letztlich den Logistik-Dienstleistern für die Lieferung. Eine enorme Anfangsinvestition für ein Produkt dessen Bedarf völlig unklar ist.

Abbildung 5: pillbox Serviceangebot

Aus Sicht der Gründer waren die folgenden Annahmen im Geschäftsmodell am risikoreichsten:

• Würden Kunden einem Startup bei der Dosierung und Lieferung von Medikamenten trauen ?
• Wären Kunden bereit, für das Produkt inklusive der Services zu bezahlen ?

Um diese Annahmen schnell und kostengünstig zu validieren, entschieden sich die Gründer ein leichtgewichtiges Concierge MVP aufzusetzen.

Über die Kooperation mit einem Ärztezentrum war pillbox in der Lage, die ersten zwanzig Kunden zu akquirieren, die eine monatliche Gebühr für das Produkt bezahlen mussten. Diesen Kunden wurde der vollständige Service von der Abholung der Rezepte über die Einreichung bei einer Partnerapotheke und die Bestellung bei einem Blisterzentrum bis hin zur persönlichen Auslieferung durch die Gründer angeboten.

Pillbox war so in der Lage, die beiden risikoreichsten Annahmen im Geschäftsmodell zu validieren. Es sollte sich herausstellen, dass auch nach  3 Monaten, trotz der monatlichen Gebühr, alle Kunden dem Service treu geblieben sind. Durch den engen Kontakt mit den ersten Kunden konnten die Gründer zudem weitere wichtige Erfahrungen zu ihrem Produkt sammeln. Neben Erkenntnissen zum Onboarding der Nutzer und der Bestätigung darüber, dass über alle Zielgruppen hinweg die Kommunikation über eine App das bevorzugte Mittel ist, lernte das Team vor allem eine entscheidende Lektion: Das eigentliche Produkt war nicht die Box mit den verblisterten Medikamenten, sondern der Wert lag in den angebotenen Services. Die ersten Kunden waren begeistert davon, die Abhängigkeit von den Öffnungszeiten der Ärzte und Apotheken sowie der Vorrätigkeit der Medikamente zu minimieren bzw. loszuwerden. Das Verkaufsversprechen von pillbox, der Mehrwert für den die ersten Kunden bereit waren, Geld zu bezahlen, ist die Ersparnis eines der wertvollsten Güter – Zeit.

Auf Basis der neuen Erkenntnisse zum Wert des Produkts und insbesondere des Prozesses sind die Gründer nun außerdem in der Lage, ihr Produkt deutlich gezielter iterativ zu automatisieren und somit zu skalieren. Es existieren nun Erfahrungen darüber, an welchen Punkten der Wertschöpfungskette eine Automatisierung den größten Mehrwert generiert und wo es sich daher lohnt, damit anzufangen.

Die Gründer konnten also mit der Strategie eines Concierge MVP ihre Kernhypothesen validieren. Darüber hinaus hat der enge Kontakt mit beteiligten Stakeholdern und den ersten Kunden dem Team zu wichtigen qualitativen Erkenntnissen verholfen.

Fazit

Geschwindigkeit ist der Schlüssel, um ein Produkt erfolgreich auf den Markt zu bringen. Der Fokus liegt dabei in der Produktentwicklung auf einer geringen Time-To-Market. In einer Phase, in der jedoch nicht klar ist, ob überhaupt ein Markt für das Produkt existiert, verschiebt sich dieser Fokus. In diesem Fall geht es darum Zeit und Aufwand zu verkürzen, die man benötigt, um zu lernen, ob das Produkt einen Markt hat. Bei neuen, innovativen Produkten kann man daher also eher von einer Time-To-Learning sprechen, die es zu reduzieren gilt. Dazu sind folgende zwei Fragen zu beantworten:

• Was ist die risikoreichste Annahme über mein Produkt oder Geschäftsmodell?
• Was ist das kleinste Experiment, mit dem ich diese Annahme validieren kann?

Das MVP ist ein mächtiges Werkzeug, das Produktmanager nutzen können, um diese risikoreichsten Annahmen zu validieren und sollte daher elementarer Bestandteil des Werkzeugkoffers sein. Wir haben jedoch gesehen, dass die Antwort auf die Frage nach dem kleinsten Experiment bei weitem nicht immer “ein Softwareprodukt entwickeln” sein muss. Entscheidend ist hier, wie so oft, die Wahl des richtigen Werkzeugs für diesen Job. Dafür ist es unerlässlich, die Vielfalt der Handlungsoptionen für ein MVP zu kennen, um die richtige Wahl für den eigenen Kontext treffen zu können. Insbesondere durch die drei Varianten – Concierge, Wizard of Oz und Piecemeal (Informationen zu Letzteren gibt es im original Artikel ) – ist man in der Lage mit geringem Aufwand ein lebensfähiges Produkt auf den Markt zu bringen. Somit hat man für bestimmte Produkte eine echte Alternative für Experimente bevor man in die Entwicklung von Software investiert.

Auch in späteren Phasen der Produktentwicklung sollten die Lean-Startup-Prinzipien, insbesondere Build-Measure-Learn, angewendet werden. Das Konzept MVP sollte deshalb keinesfalls als einmaliges Ereignis im Lebenszyklus eines Produktes betrachtet werden. Die hier vorgestellten Muster können auch später, beispielsweise für Experimente zur Validierung einzelner Features, verwendet werden.

Ein spannendes Beispiel dazu stammt aus dem Buch “Sprint”⁴ , in dem das Prinzip des von Google Ventures entwickelten “Design Sprints” beschrieben wird.

Das amerikanische Startup Slack entwickelt einen erfolgreichen Messenger für Teams und Unternehmen. Im Zuge eines Design Sprints wollte das Team den Onboarding-Prozess verbessern, damit neue Nutzer sich schneller in Slack  zurechtfinden. Das Team entwickelte im Sprint die Idee, zu diesem Zweck einen Chatbot zu entwickeln, der die Nutzer in die Benutzung von Slack einführen und eine permanente Anlaufstelle für Rückfragen sein sollte. Um die Akzeptanz bei den Nutzern und die Effektivität des Bots in einem kleinen Experiment zu validieren, erprobte das Team die Idee mit neuen Nutzern, die mit einem Teammitglied kommunizierten, der sich als Bot ausgab. Auf diese Weise war das Team außerdem in der Lage erste Erkenntnisse darüber zu sammeln, wie intelligent der Bot sein musste, um vom Nutzer als hilfreich wahrgenommen zu werden. Inzwischen ist der Slack-Bot ein fast schon ikonischer Bestandteil des Messengers. Der hier beschrieben Test, den das Team durchgeführt hat ist im Wesentlichen ein Wizard of Oz MVP für ein einzelnes Feature.
Der kontinuierliche Einsatz des Konzepts MVP in der Produktentwicklung ist letztlich eine wertvolle Risikovermeidungsstrategie, die die dabei hilft permanent fundiertere Entscheidungen bei der Wahl der nächsten Entwicklungsschritte zu treffen.

Dieser Blog-Post ist erstmalig im Softwerker Spezial: Digitalisierung erschienen. 
Den Softwerker kostenlos abonnieren
Weitere Infos zu unserem Angebot finden Sie auf unserer Seite the black frame.com .

<sub>1. Humble, Molesky, O’Reilly: Lean Enterprise S. 77
2. Maurya, Ash: Running Lean”, Part II – Chapter 3
3. Ries, Eric: The Lean Startup, S. 111
4. Knapp, Zeratsky, Kowitz: Sprint, S. 175</sub>