Wir alle kennen klassisches Projektmanagement, das sich auf genau definierte Projektpläne stützt und bei dem das perfekt entwickelte Produkt am Ende produktiv gestellt werden soll.
Natürlich versuchen sich alle Teammitglieder an diese Projektpläne zu halten und empfinden sie oft als Zwang. Vielleicht erkennen Mitarbeiter bereits während des Projektverlaufes, dass manche Schritte umständlich oder aufgrund mittlerweile neu gewonnener Erfahrungen, so eigentlich nicht mehr stimmig sind und geändert werden müssten. Da aber viele Schritte gleichzeitig gemacht werden, verliert man schnell den Überblick über die Vielzahl der Vorgänge und der Projektplan wird wie vereinbart abgearbeitet.
„Everybody has a plan, until they get punched in the face.“– Mike Tyson (Michael Gerard „Mike“ Tyson ist ein ehemaliger Boxer. Mit einem Alter von 20 Jahren und 144 Tagen war er 1986 der bislang jüngste Boxer, der einen Weltmeistertitel im Schwergewicht erringen konnte.)
Mit MVP – Minimum Viable Product betrachten wir eine Vorgehensweise, mit der wir uns stückchenweise dem Leistungsumfang eines Zielproduktes nähern. Ziel ist die Vermeidung von Aufwendungen aufgrund von Vermutungen und Einschätzungen zum benötigten Leistungsumfang. Meist wird bereits bei Projektstart festgelegt welche Ressourcen wo eingesetzt werden. Diese Planung ist dann “Gesetz” und wird unter Umständen im Projektverlauf nicht nochmals hinterfragt. Dabei treffen wir oft zu Projektstart die meisten Entscheidungen, obwohl wir doch noch am wenigsten Projekterfahrungen haben.
MVP heißt, nach guter Anfangsrecherche mit unserem Auftraggeber entwickeln wir ein Produkt, was im ersten Schritt die wichtigste und brennendste Kernfunktion erfüllt, sodass unser Kunde das zunächst einfache Produkt schnell nutzen und testen kann. Durch die Abfrage von Kunden- und Nutzer-Feedbacks können wir dann an Hand der Anforderungen am System und Produkt zielgerichteter weiterentwickeln, da wir ja immer mehr Erfahrungen sammeln.
MVP eignet sich also z. B. dann,
- wenn wir etwas völlig Neues erschaffen wollen, wie z. B. der Hausbau auf dem Mond und somit natürlich noch keine oder wenig Erfahrungswerte und nur ein begrenztes Maß an Geld, Zeit und Ressourcen zur Verfügung haben.
- wenn wir etwas Bekanntes ablösen und eine sehr hohe Anzahl von Features in einem System vorhalten wollen, deren direkten Einfluss auf gemeinsam definierte Ziele wie z. B. Conversionrate nur aufgrund einer Ersteinschätzung beruhen.
Ein Hausbau auf dem Mond ist natürlich ein fiktives und absurdes Beispiel, aber auch im Kleinen ist es wirklich nicht immer einfach: Ist es der richtige Weg alle Features von 1-15 umzusetzen, um das Bestellverhalten aufgrund unserer reinen Vermutungen zu verbessern?
Im übertragenen Sinne stellt sich also die Frage, ob ich mit meinem Auto tatsächlich nicht in den Urlaub fahren kann, nur weil der elektrische Scheibenheber noch nicht eingebaut ist, obwohl ich die Scheibe mit einer Kurbel schon jetzt bedienen kann. Vielleicht entscheide ich mich während der Fahrt aufgrund meiner neu gewonnen Erkenntnisse, dass ich eine Klimaanlage möchte und der elektrische Scheibenheber nicht mehr benötigt wird und ich investiere das Geld lieber gleich in die Klimaanlage.
Hier geht es uns vor allem um einen Denkansatz und nicht um ein neues Gesetz, das dann genauso sklavisch verfolgt wird:
(Quelle: Grafik verwendet von Henrik Kniberg, Crisp´s Blog https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)
The version of a new product which allows a team to collect the maximum amount of validates learning about customers with the least effort.– Eric Ries (Eric Ries ist ein Silicon-Valley-Entrepreneur und Autor. Er gilt als Begründer der Lean-Startup-Methode.)
Machen wir uns frei von Annahmen und setzen auf datenbasierte Erkenntnisse, denn das Prinzip ist einfach und enorm effektiv. Zur besseren Nachvollziehbarkeit, hier ein Überblick über eine mögliche Vorgehensweise. Hier ein Beispiel:
- Anforderungs- und Problemdefinition des gewünschten Produktes
- Fokussierung auf die “tatsächlichen” Kernziele des Produktes
- Design einer User–Interface mit der maximalen Ausprägung und vollem Leistungsumfang
- Priorisierung der ersten umzusetzenden Funktionen die im Minimum wichtig sind, um das Kernziel zu erreichen
- Implementierung der User Interface mit den gewünschten Kernfunktionen
- Analyse der eingehenden Feedbacks und des Nutzerverhaltens
- Wiederholte Überprüfung bereits benannter Features auf Sinnhaftigkeit und die Definition neuer Features
- … und weiter geht´s zur nächsten Entwicklungsschleife…
Durch das Kundenfeedback können wir schnell und einfach klären in welche Richtung das Produkt Schritt für Schritt weiterentwickelt werden soll. Nach dem Prinzip Bauen – Messen – Lernen fließen neue Iterationen in die Entwicklung ein und wir bilden eine Expertise in einem neuen Feld. So können alle Projektteilnehmer lernen – jeden Tag!
Das Feedback aus frühem Nutzerverhalten kann also ein Produkt kraftvoll vorantreiben.
Falls wir aufgrund unserer Erfahrungen den Weg zur Zielerreichung bereits kennen und das schon hundertmal gemacht haben, brauche wir natürlich keine Versuchsreihe zu starten die uns zu Ergebnissen führt, welche uns schon bekannt sind. Wenn wir aber sehen, dass der alte Weg für dieses Projekt einfach nicht funktioniert, sind wir bereit dazu mit einem neuen Denkansatz an eine gegebene Aufgabenstellung heranzugehen. Wir sollten also nicht schon im Vorfeld Zeit und Geld investieren, für Entwicklungen zu denen wir zu wenig Erfahrungswerte haben. Lieber konzentrieren wir uns auf das Sammeln von Erfahrungen, um so unsere Ressourcen da einzusetzen, wo wir sie auch tatsächlich brauchen. Klar, wir können jetzt einen Haufen Buzzwords verwenden die in der Regel in den meisten Artikeln stehen: agile Methoden einsetzen, den Return of Invest erhöhen, Scrum und Design Thinking… usw. Aber Scherz bei Seite, darum dreht es sich natürlich nicht.
Wir wollen ein Produkt so individuell auf die Bedürfnisse des Marktes, des Nutzers und der Kunden anpassen wie möglich – und das schnell und möglichst ohne Umwege.