»Machen wir ein MVP.« Was bedeutet das überhaupt, wie funktioniert’s und wann macht eine Anwendung Sinn? Mario Wimmer, Senior IT Project Manager Plan.Net Technology, erläutert dies im Gastbeitrag für PAGE …
Mario Wimmer, Senior IT Project Manager Plan.Net Technology
Die Zeiten ändern sich und mit ihnen Technologien, Märkte und Kunden. Mittlerweile haben wir wohl alle bemerkt, dass es in der großen Lotterie namens »Digitalisierung« für einige viel zu gewinnen, für andere viel zu verlieren und für alle viel zu lernen gibt. In diesem Kontext hat eine ganze Reihe von »agilen« und »leanen« Tools und Techniken das mittlere Management erobert. Eines dieser glänzenden, frischen Tools aus dem Silicon Valley ist das Minimum Viable Product oder kurz gesagt MVP.
Kaum eine Diskussion über die Entwicklung eines Produktes, die Durchführung eines Projektes oder die Lösung eines anderen hinreichend komplexen und unklaren Problems wird heute geführt, ohne dass jemand vorschlägt »doch einfach ein MVP zu machen«. Es scheint kaum ein Problem zu geben, das ein MVP-Ansatz nicht lösen kann: Wir kennen den Scope unseres Projektes nicht? Machen wir ein MVP. Wir haben keine Ahnung was der Kunde eigentlich will? Machen wir ein MVP. Wir haben absolut keine Zeit und kein Budget? Machen wir ein MVP.
Maximum Vexing Problem
Und damit könnte es eigentlich gut sein.
Mit einem MVP-Ansatz alleine ist sicher keines dieser Probleme gelöst, aber in eigentlich jedem Fall lässt sich daraus die eine oder andere wertvolle Einsicht gewinnen.
Wer möchte bestreiten, dass in einem unsicheren und unbeständigen Umfeld, mit vage definierten Problemen und noch vageren Lösungsansätzen, ein Ansatz der vielen kleinen Schritte sinnvoller scheint als ein großer (Fehl-)tritt?
In diesem Kontext ist das Konzept, ein Produkt zu entwickeln (oder ein beliebiges anderes Problem zu lösen), indem man schnell mögliche Ideen umsetzt, Hypothesen testet, Feedback sammelt und graduell die gefundene Lösung verbessert, recht naheliegend. Die Sache hat nur einen Haken: Damit sich Probleme iterativ in Luft auflösen, müssen alle Beteiligten das gleiche Verständnis dessen haben, was das Konzept eigentlich meint. Was leider oft nicht der Fall ist.
Minimum und Product
Wie bei vielen einfachen, einprägsamen Konzepten liegt der Teufel im Detail. Zerlegen wir das MVP in seine drei Teilbegriffe: Minimum, Viable und Product. Der erste und dritte davon sind allen Beteiligten (und deren Stakeholdern) meistens schnell und direkt klar:
Minimum, drückt aus, dass wir auf der Suche nach etwas kleinem, effizientem und effektivem sind. Wir wollen ein Maximum von X mit einem minimalen Input von Y (Zeit, Geld, Ressourcen) erreichen. Das ist der Punkt, der die meisten Nutzer (und deren Manager) initial für das Konzept begeistert: das Versprechen ein großes X für ein kleines Y zu erhalten.
Product, ist ebenfalls leicht zugänglich, wir lösen ein Problem nicht zu unserer persönlichen Unterhaltung, sondern versuchen etwas zu schaffen, was ein (End-)Kunde nutzen und kaufen wollen würde. Dementsprechend setzt genau dieser Kunde, diese Gruppe von Stakeholdern und ihr Feedback die Messlatte für unsere Bemühungen.
»V« wie »Viable«
Womit wir bei »viable« ankommen, dem Begriff mit dem die meisten Teams Probleme haben und dessen Verständnis über Erfolg oder Misserfolg des Ansatzes entscheidet. Um das Problem zu verdeutlichen, hilft es »viable« umformulieren: Eine Lösung ist »viable« wenn es ihr gelingt, unsere Erwartung von Erfolg zu erfüllen. Und genau diese »Erwartung von Erfolg« unterscheidet sich für gewöhnlich von Stakeholder zu Stakeholder. Ein geteiltes Verständnis dessen, was »viable« für ein Produkt oder Projekt bedeutet, entscheidet über Erfolg oder Scheitern eines Teams, das sich für MVP als Ansatz entscheidet.
Abhängig von der Ausbildung, der aktuellen Rolle, der subjektiven Wahrnehmung einer Situation und vieler anderer Variablen hat jeder Stakeholder womöglich ein radikal unterschiedliches Verständnis dessen, was »viable« meint.
Insofern ist der Schlüssel zu einem erfolgreichen MVP die frühzeitige Klärung und kontinuierliche Abstimmung dieser unterschiedlichen Erwartungen der einzelnen Stakeholder.
Making »Viable« more »Viable«
Eine Möglichkeit frühzeitig die gröbsten Missverständnisse auszuräumen, hat der Lean/Agile Coach Henrik Kniberg vorgeschlagen. Je nach Hauptziel des Teams und seiner Key Stakeholder wird »viable« durch drei weitere Begriffe ersetzt:
Minimum Testable Product – Jeder Versuch, bei dem sich (kleine) Hypothesen klassisch testen lassen. Den Anfang machen die Thesen, die den größten Gewinn in Bezug auf Wissen über Machbarkeit, Funktion, Value Propositions, Risiken oder Chancen bieten.
Minimum Useable Product – Jeder Versuch, der dem Nutzer einen (begrenzten) Nutzen bietet und der es ihm erlaubt zu einer möglichen Verbesserung des Produkts Feedback zu geben. Der Fokus liegt weiterhin auf den Dingen, die den größten Mehrwert in Bezug auf »Nutzen« oder »Feedback« versprechen.
Minimum Loveable Product – Jeder Versuch, den der Nutzer so gut findet, dass er es tatsächlich kaufen, dauerhaft nutzen oder anderen empfehlen würde. Im Idealfall ergibt sich das Minimum Loveable Product aus den durch Minimum Testable und Minimum Useable Products gewonnen Einsichten.
Diese Ersetzungen machen die vielen Facetten von »viable« explizit und helfen dabei, das Konzept MVP je nach Kontext zu schärfen. Damit eignen sie sich nicht nur, um mit vom Buzzword MVP begeisterten Stakeholder und Teams die Basis für erfolgreiche Produkte und Projekte zu erarbeiten, sondern auch um Teams in Not die dringend benötigte Klärung, Orientierung und Struktur zu geben. Last but not least bilden sie eine gute Basis für einen informierten Austausch mit Stakeholdern, die bereits negative Erfahrungen mit einem leichtfertigen Einsatz des MVP-Gedanken gemacht haben.
MVPraxis – wann wir MVPs anwenden
Bei Plan.Net nutzen wir MVP-basierte Ansätze in einer Vielzahl von Situationen: Beispielsweise in der Entwicklung anspruchsvoller Digitalprodukte, wie einer leanen Lösung zur Partnerintegration für einen weltweit tätigen Logistikdienstleister oder Location Based Offers und Services für die Apps eines der größten deutschen Loyalty-Programme. Hier half ein fokussiertes, iteratives Vorgehen dabei, parallel einen herausfordernden Technologie-Stack aus GPS, Bluetooth und NFC stabil zu implementieren und trotzdem flexibel auf neue Inputs zur Produktgestaltung reagieren zu können.
Generell sind MVPs sehr gut geeignet, wenn es darum geht, kreative UND technologische Anforderungen zu vereinen.
Situationen die häufig von widerstreitenden Prioritäten, hohem Druck und Unsicherheit geprägt sind.
Ein weiterer Fall aus der Praxis, in dem ein MVP zum Einsatz kam, war der Relaunch des Plattform-Portfolios eines großen Energieanbieters, bei dem es besonders herausfordernd war, die Roadmap mit einem großen Leistungsumfang zusammenzubringen. Aber auch in der Früherprobung neuer Technologie, wie bei der Entwicklung eines AR-Prototypen für ein großes Transportunternehmen, hilft ein MVP-Ansatz im Dschungel der digitalen Möglichkeiten, nicht den Überblick zu verlieren.
Beyond the buzzword
In diesem Sinn: Neue Herausforderungen brauchen neue Ideen. Wir brauchen neue Wege des Arbeitens, brauchen neue Werkzeuge und Varianten der Zusammenarbeit. Wir brauchen die Bereitschaft, gemeinsam Dinge auszuprobieren, gemeinsam Großes zu erreichen und manchmal knapp vorher gemeinsam zu scheitern. Was wir nicht brauchen, sind Buzzword-Blendgranaten, die mit maximaler Wirkung in Meetings gezündet werden, um dann bei allen Beteiligten nichts zu hinterlassen als ein schales Gefühl und Piepen im Ohr. Wir sollten also regelmäßig fragen, wie und wo uns »agile« und »leane« Ansätze helfen können, Probleme wirklich zu lösen und sie nicht nur mit hippen Begriffen verschleiern.
