Das Konzept des Minimum Viable Product (MVP) dürfte mittlerweile den meisten Menschen bekannt sein, die sich mit der Entwicklung digitaler Produkte beschäftigen. Die grundsätzliche Idee ist schließlich auch einleuchtend. Anstatt viel Zeit und Geld in ein umfangreiches Produkt zu investieren, versuchen wir möglichst früh mit einer reduzierten Lösung herauszufinden, ob wir damit überhaupt einen relevanten Nutzen erzeugen können. Wir entwickeln also zunächst nur das, was notwendig ist, um wichtige Annahmen zu überprüfen und Erkenntnisse darüber zu gewinnen, ob und wie unser Produkt für die Nutzer:innen einen Mehrwert erzeugt. Auf dieser Grundlage entscheiden wir dann, ob und in welche Richtung wir weiterentwickeln.
Soweit zumindest die Theorie.
In meiner Arbeit erlebe ich aber immer wieder, dass insbesondere größere Organisationen Schwierigkeiten haben, dieses eigentlich recht einfache Konzept konsequent umzusetzen. Dabei liegt es aus meiner Sicht oft gar nicht daran, dass die beteiligten Menschen nicht verstanden hätten, was ein MVP ist. Vielmehr stehen ihnen die organisatorischen Rahmenbedingungen im Weg. Vor allem der Wettbewerb um begrenzte Umsetzungskapazitäten und ein mangelndes Vertrauen in die Möglichkeit, nach einem ersten Schritt tatsächlich weiterarbeiten zu können.
Das Problem mit der nächsten Gelegenheit
In größeren Organisationen, und hier meine insbesondere Konzerne, gibt es in der Regel zahlreiche Stakeholder, die unterschiedliche Interessen verfolgen und ihre jeweiligen Themen voranbringen möchten. Das ist zunächst einmal nachvollziehbar. Schließlich haben diese Menschen eigene Verantwortungsbereiche, Ziele und Erwartungen, denen sie gerecht werden müssen. Gleichzeitig sind die Umsetzungskapazitäten aber fast immer begrenzt. Es gibt mehr Ideen, Anforderungen und Vorhaben als Menschen, die diese umsetzen könnten. Die Folge ist ein mehr oder weniger ausgeprägter Wettbewerb um die verfügbaren Kapazitäten der Produktentwicklung.
Wer mit seinem Thema zum Zuge kommt, kann sich zunächst glücklich schätzen. Schließlich hat man es geschafft, die eigene Initiative gegenüber anderen Vorhaben durchzusetzen und die notwendigen Ressourcen für die Umsetzung zu bekommen. Nun wäre das eigentlich der ideale Zeitpunkt, um mit einem MVP zu beginnen. Wir könnten uns auf einen kleinen, aber wertstiftenden Ausschnitt konzentrieren, diesen möglichst früh mit echten Nutzer:innen erproben und anschließend auf Grundlage der gewonnenen Erkenntnisse weiterarbeiten. Allerdings gibt es dabei ein Problem: Wer weiß schon, wann man das nächste Mal Umsetzungskapazitäten bekommt?
Wenn die Weiterentwicklung anschließend wieder mit zahlreichen anderen Initiativen konkurrieren muss, kann es Monate dauern, bis erneut Kapazitäten zur Verfügung stehen. Vielleicht wird das Produkt auch überhaupt nicht weiterentwickelt, weil sich zwischenzeitlich andere Themen durchgesetzt haben. Aus Sicht der Stakeholder entsteht dadurch ein nachvollziehbarer Anreiz, möglichst viele Anforderungen bereits bei der ersten Umsetzung unterzubringen. Schließlich möchte man die Gelegenheit nutzen, solange sie sich bietet.
Wenn das Vertrauen in den nächsten Schritt fehlt
Ich glaube allerdings, dass es nicht allein um die objektive Knappheit von Ressourcen geht. Mindestens ebenso wichtig ist das Vertrauen darauf, dass eine Organisation mit den Erkenntnissen aus einem MVP anschließend auch etwas anfangen wird. Wer ein bewusst reduziertes Produkt verantwortet, geht ehrlicherweise auch ein Risiko ein. Die erste Version wird noch nicht alles können, was sich Nutzer:innen oder Stakeholder:innen wünschen. Vielleicht werden auch wirtschaftliche Kennzahlen zunächst hinter den Erwartungen zurückbleiben. Genau deshalb möchten wir ja früh lernen. Wenn aber unklar ist, ob diese Erkenntnisse überhaupt zu einer zweiten Iteration führen dürfen, wird das kleine MVP plötzlich zum politischen Risiko.
Das fehlende Vertrauen kann dabei auf unterschiedlichen Ebenen entstehen. Stakeholder:innen zweifeln möglicherweise daran, dass ihnen die Organisation später noch einmal Kapazitäten zugesteht. Produktverantwortliche können befürchten, dass ein vorläufig unvollständiges Produkt als Misserfolg bewertet wird. Und Führungskräfte sind womöglich selbst unsicher, ob sich eine weitere Investition nach einer ersten, noch wenig eindrucksvollen Version rechtfertigen lässt.
Dann geht es nicht unbedingt darum, dass sich einzelne Menschen gegenseitig misstrauen. Es fehlt vor allem die Verlässlichkeit der organisatorischen Zusagen: Wird das, was wir aus dem MVP lernen, tatsächlich berücksichtigt? Bekommen wir die Gelegenheit, darauf zu reagieren, oder entscheidet beim nächsten Ressourcenwettbewerb ohnehin wieder die lauteste Stimme?
Unter solchen Bedingungen ist es für die Beteiligten durchaus vernünftig, lieber gleich einen größeren Umfang zu fordern. Nicht unbedingt, weil sie die Idee eines MVP ablehnen, sondern weil sie nicht darauf vertrauen können, dass dessen Lernschleife wirklich stattfinden wird.
Lieber etwas mehr, damit es sich auch lohnt
Dazu kommt noch, dass gerade in Organisationen, in denen über die Fortführung von Initiativen anhand von Business Cases, Zielerreichung oder anderen wirtschaftlichen Erwartungen entschieden wird, ein stark reduziertes Produkt riskant erscheinen kann. Was passiert, wenn wir mit unserem MVP noch nicht den erhofften wirtschaftlichen Erfolg erzielen? Was, wenn Nutzer:innen noch nicht begeistert sind oder wichtige Funktionen vermissen? Möglicherweise wird das als Zeichen dafür interpretiert, dass die Produktidee nicht funktioniert. Dabei wäre es durchaus möglich, dass wir bereits wertvolle Erkenntnisse gewonnen haben und auf dieser Grundlage eine sinnvolle Weiterentwicklung vornehmen könnten.
Aus dieser Perspektive ist es nachvollziehbar, dass Stakeholder:innen lieber etwas mehr entwickeln lassen möchten. Vielleicht noch diese eine Funktion, die für eine bestimmte Nutzergruppe wichtig sein könnte, oder jene Erweiterung, die den Nutzen des Produktes deutlicher machen soll. Und wenn wir ohnehin gerade dabei sind, könnten wir doch auch gleich die Anforderungen eines weiteren Fachbereichs berücksichtigen.
Am Ende entsteht ein Produkt, das zwar weiterhin als MVP bezeichnet wird, tatsächlich aber schon ziemlich nah an einer umfangreichen ersten Produktversion liegt. Das muss nicht zwangsläufig ein schlechtes Produkt sein. Vielleicht erfüllt es sogar viele Anforderungen und wird von seinen Nutzer:innen geschätzt. Nur haben wir damit einen wesentlichen Vorteil des MVP-Konzeptes aufgegeben, nämlich die Möglichkeit, mit möglichst geringem Aufwand möglichst früh zu lernen.
Ein MVP, das eigentlich keines ist
Besonders interessant finde ich, was anschließend mit dem Begriff MVP passiert. In der Organisation wird weiterhin davon gesprochen, dass ein MVP entwickelt werden soll. In Projektanträgen, Präsentationen und Abstimmungen taucht der Begriff auf, obwohl längst eine umfangreiche erste Produktversion geplant wird. Das MVP wird damit gewissermaßen Teil der Schauseite der Organisation. Wir sprechen über ein modernes Konzept der Produktentwicklung, ohne die dafür notwendigen Bedingungen tatsächlich zu schaffen.
Natürlich lässt sich darüber streiten, wann ein MVP aufhört, ein MVP zu sein. Ein Minimum Viable Product muss nicht zwangsläufig klein im Sinne von wenigen Funktionen sein. Entscheidend ist vielmehr, dass wir möglichst früh mit vertretbarem Aufwand relevante Annahmen überprüfen und daraus lernen. Wenn wir allerdings zahlreiche Funktionen umsetzen, weil wir befürchten, später keine Gelegenheit mehr dazu zu bekommen, hat das nur noch wenig mit diesem Gedanken zu tun.
Das führt auch zu sprachlichen Missverständnissen. Wer neu in eine solche Organisation kommt und den Begriff MVP aus einem anderen Kontext kennt, wird sich möglicherweise wundern, was dort alles als Minimum Viable Product bezeichnet wird. Erst mit der Zeit versteht man, dass MVP in dieser Organisation eigentlich nur ein anderes Wort für die erste Version eines Produktes ist. Ich halte das durchaus für problematisch. Schließlich sind Begriffe in der Zusammenarbeit nicht ganz unwichtig. Wenn wir dasselbe Wort verwenden, aber unterschiedliche Vorstellungen damit verbinden, erschwert das die Verständigung über unsere Produktentwicklung.
Das Problem lässt sich nicht im Product Backlog lösen
Natürlich könnten wir jetzt versuchen, die beteiligten Stakeholder:innen noch einmal über das MVP-Konzept aufzuklären. Wir könnten Workshops durchführen, den Umfang des Produktes konsequenter priorisieren oder Product Owner:innen darin unterstützen, Anforderungen häufiger abzulehnen. Das kann alles hilfreich sein.
Allerdings würde es aus meiner Sicht am eigentlichen Problem vorbeigehen, wenn die Organisation ihre Umsetzungskapazitäten weiterhin so verteilt, dass eine schnelle Weiterentwicklung nach einem MVP kaum möglich ist und wenn niemand darauf vertrauen kann, dass ein experimenteller erster Schritt tatsächlich als Lernschritt verstanden wird.
Solange Stakeholder befürchten müssen, nach einer ersten kleinen Umsetzung wieder für längere Zeit auf Kapazitäten verzichten zu müssen, haben sie gute Gründe, möglichst viel in diese erste Umsetzung hineinzupacken. Wir dürfen uns dann nicht wundern, wenn sie genau das tun.
Wenn wir möchten, dass Produktteams tatsächlich mit MVPs arbeiten, sollten wir deshalb nicht nur kleinere erste Versionen zulassen. Wir müssen auch den nächsten Schritt ermöglichen. Beispielsweise könnten wir Kapazitäten für eine anschließende Überarbeitung bewusst vorsehen, statt jede Iteration erneut in einen vollständigen Wettbewerb um Ressourcen zu schicken und wir sollten vorab klären, nach welchen Erkenntnissen wir entscheiden wollen, ob sich die Weiterentwicklung lohnt.
Das heißt nicht, dass wir einmal bewilligte Budgets unbegrenzt fortschreiben sollten. Ganz im Gegenteil. Gerade ein MVP soll helfen, frühzeitig zu erkennen, wenn sich eine weitere Investition nicht lohnt. Aber zwischen einer begründeten Entscheidung gegen die Weiterentwicklung und dem schlichten Verlust der Umsetzungskapazität besteht ein erheblicher Unterschied.
Vielleicht sollten wir einfach aufhören, es MVP zu nennen
Ich glaube, dass es durchaus gute Gründe geben kann, eine umfangreichere erste Produktversion zu entwickeln. Nicht jede Organisation muss für jedes Vorhaben zwangsläufig mit einem MVP beginnen. Auch regulatorische Anforderungen, technische Abhängigkeiten oder die Erwartungen einer bestimmten Zielgruppe können einen größeren initialen Funktionsumfang notwendig machen.
Problematisch finde ich es allerdings, wenn wir behaupten, mit MVPs zu arbeiten, obwohl unsere Organisation gar nicht darauf ausgerichtet ist, die dabei entstehenden Erkenntnisse zeitnah zu nutzen, denn solange die Verteilung von Umsetzungskapazitäten vor allem durch einen politischen Wettbewerb zwischen unterschiedlichen Interessen geprägt ist und das Vertrauen in eine mögliche nächste Iteration fehlt, wird es für viele Produktteams schwierig bleiben, tatsächlich klein anzufangen und schnell zu lernen. Ein MVP ist schließlich nicht einfach eine kleinere Version eines Produktes. Es ist vor allem eine Möglichkeit, die Unsicherheit bei der Produktentwicklung durch frühes Lernen zu reduzieren.
Und ganz ehrlich: Wenn wir dieses Lernen organisatorisch nicht ermöglichen, können wir es eigentlich auch direkt lassen, unsere umfangreichen ersten Produktversionen als MVP zu bezeichnen. Dann sollten wir doch lieber von der Version 1 sprechen.