In letzter Zeit höre ich öfter Leute von ihrem “MVP” (minimum viable product) reden, und wenn ich dann etwas tiefer bohre, stellt sich heraus, dass die Vorstellungen von “MVP” ziemlich vage sind. Das Konzept MVP kommt aus der Lean-Startup-Bewegung und ist ein nützliches Werkzeug, um die Unsicherheit bei der Entwicklung eines neuen Angebotes zu verringern.

Mittlerweile droht auch dieser Begriff immer mehr verwässert zu werden. Hier kommt also meine Liste von Gründen, warum etwas nicht MVP genannt werden sollte.

Es ist kein MVP, wenn kein Kontakt des Produktes mit echten Endanwendern geplant ist. Wenn Sie es nur Ihren Geldgebern zeigen, oder eine Pressemeldung darüber schreiben wollen, nennen Sie’s einfach “Prototyp”, oder “Proof of Concept”, oder “Meilenstein 1”.

Es ist kein MVP, wenn die Endanwender es nicht im Ernst einsetzen sollen. Landing Pages und PowerPoint-Folien zählen nicht. Auch Software, die nur vorgeführt wird, zählt nicht. Erst, wenn ein echtes Problem von Endanwendern gelöst wird, ist ein Produkt “viable”, also brauchbar oder lebensfähig.

Es ist kein MVP, wenn Sie kein Geld dafür nehmen wollen. Das Feedback der potenziellen Kunden wird viel zu gnädig ausfallen, wenn es nichts kostet. Bei unternehmensinterner Software nimmt man natürlich meist kein Geld, also braucht man eine entsprechende Gegenleistung: zum Beispiel, sich in das MVP einzuarbeiten und es statt bestehender Software für diesen einen kleinen Ausschnitt eines Geschäftsprozesses einzusetzen. Wer keinen Nutzen im MVP sieht, wird diesen Aufwand scheuen und es Ihnen klar sagen.

Es ist kein MVP, wenn Lernen nicht (oder nicht mehr) das Hauptziel ist. Wenn Sie zum Beispiel mit einer Vorab-Version Marktanteile erobern wollen, nennen Sie es einfach Version 1.0. Die Leute wissen dann schon, dass es nicht ausgereift ist – wer Zuverlässigkeit will, wird dann noch etwas warten. Auch wenn das MVP Geld kosten soll, der Umsatz ist nicht das Ziel. Er dient nur dazu, das Feedback der potenziellen Kunden zu validieren.

Es ist kein MVP, wenn das Feedback zum MVP Ihren Plan nicht umwerfen kann. Ein MVP dient in erster Linie zur Gewinnung von Information. Wenn es keine fundamentalen Überraschungen mehr geben kann (oder darf), bauen Sie nur das, was Sie sowieso vorhatten. Das muss nicht verkehrt sein, es ist dann eben nur kein MVP.

Es ist kein MVP, wenn Sie nicht vorhaben, mehrere MVPs zu bauen. Es klappt nur selten im ersten Anlauf, daher muss man das Angebot und die Implementation iterieren, und mit abgewandelten MVPs wieder vor dieselben oder andere Kunden treten.

Es ist kein MVP, wenn Sie den Funktionsumfang und die Implementation nicht mindestens einmal radikal vereinfacht haben. Das “minimal” in MVP ist kleiner, als man zuerst denkt. Ich kenne jemanden, der hat eine neue lokale Jobbörse monatelang als öffentliches Google Spreadsheet betrieben. Der Gründer ist studierter Informatiker, es lag also nicht an mangelnden Programmierfähigkeiten. Vielmehr hat er sich am Anfang auf die entscheidenden Fragen konzentriert: Kann man überhaupt genügend Jobsuchende und zahlungswillige potenzielle Arbeitgeber finden? Die “richtige” Job-Website mit komfortabler Suchfunktion kam dann wesentlich später dran, nachdem er das passende Geschäftsmodell gefunden und validiert hatte.

Matthias Berth