MVPs (Minimal Viable Product) kennt man eher aus der Produktentwicklung speziell im Softwareumfeld. Dabei wird ein (Software-) Produkt mit den Basisfunktionalitäten hergestellt, welches dann live getestet und anhand des Feedbacks der Kunden weiterentwickelt wird. Als Beispiel wird eine App mit den wesentlichen Funktionen programmiert und gelaunched. Durch das Feedback der Nutzer wird in einem iterativen oder auch agilen Ansatz das Produkt, also die App, nach und nach funktional und auch hinsichtlich der Usability optimiert.
Ein solches Vorgehen sollte auch viel häufiger im Kundenservice Anwendung finden. MVP soll hier mehr als Synonym für ein Serviceprodukt, also für die Möglichkeit des Verprobens neuer Funktionalitäten, Prozesse und Vorgehensweisen, gesehen werden. Ziel ist es, den Mehrwert eines neuen Services genauer zu evaluieren und die Schwachstellen zu identifizieren. Aber um ein MVP einzusetzen, sind bestimmte Voraussetzungen zu schaffen, die im Nachfolgenden kurz beschrieben werden sollen.
Zuerst muss festgelegt werden, was genau getestet werden soll und welche Ergebnisse erzeugt werden sollen. Weiterhin muss definiert werden: „Was ist Erfolg?“, d.h. wann wird der MVP als Erfolg gewertet. Ganz konkret müssen die relevanten Kennzahlen identifiziert und Zielwerte festgelegt werden. Abhängig von den Zielen können diese Kennzahlen effizienzgetrieben sein, wie z.B. Reduktion von nicht werthaltigen Kundenkontakten, Steigerung der Lösungsquote oder Beschleunigung der Bearbeitungszeit, oder aus KPIs hinsichtlich Qualität oder Kundenzufriedenheit, wie beispielsweise CSAT oder NPS, bestehen.
Danach wird festgelegt, welche Funktionalitäten der MVP enthalten soll. Die Natur des MVP ist, dass man sich auf das Wesentliche fokussiert und nicht versucht einen 120-prozentigen Ansatz zu verfolgen. „Mut zu Neuem!“ oder „Mut zur Lücke!“ ist hier eher das Motto.
Weiterhin muss die Zielgruppe für den MVP definiert werden. Soll der MVP vollständig ausgerollt werden oder nur einem Teil der Kunden oder Nutzer zur Verfügung gestellt werden? Um den Mehrwert der Veränderungen im MVP zu dem bisherigen Status am besten anhand der oben genannten Kennzahlen und Zielwerte zu bewerten, sollte die Möglichkeit eines direkten A/B Tests, also des Vergleichs aus dem parallelen Betrieb von Status Quo und MVP, vorgesehen werden. Das heißt aber auch, dass der MVP nur einem Teil der Kunden zugänglich gemacht wird.
Eine grundlegende Voraussetzung für einen MVP ist Flexibilität. Flexibilität in der Technologie aber auch Flexibilität in der Organisation. Die Systemlandschaft muss es zulassen, dass schnell und relativ einfach Veränderungen in den Prozessen vorgenommen werden können. In der Organisation müssen die involvierten Personen in der Lage sein, das Feedback und auch die Kritik während des MVP auszuhalten und in positive Energie für die Weiterentwicklung und Optimierung umzuwandeln.
Last but not least geht es um die Vergleichbarkeit und Aussagekraft der Daten in den entsprechenden Reports sowie die Auswertbarkeit des Kundenfeedbacks. Die Daten müssen darstellen, ob der MVP ein Erfolg ist oder die Entwicklung sich zumindest auf dem richtigen Weg befindet.
Das Kundenfeedback muss sehr detailliert ausgewertet und für die nächste Iterationsstufe des MVP genutzt werden. Das Entwicklungsteam des MVP muss dabei offen sein für jedwede Kritik und Verbesserungsvorschläge. Also frei nach dem Motto „the customer is always right“.
Die Erfahrungen zeigen, dass heute weder die Organisationen noch die technische Infrastruktur in den meisten Unternehmen für einen solchen Ansatz vorbereitet sind. Veränderungen von Vorgehensweisen oder Serviceprodukten dauern sehr lange und kosten erhebliches Geld in der Umsetzung.
Aber statt immer nach dem „goldenen Ei“ zu suchen, in dem sehr intensive und zeitraubende Analysen durchgeführt werden, in der Hoffnung damit die beste Lösung zu ermitteln, können MVPs einen schnellen und sehr direkten Weg darstellen, um neue Services zu testen und das direkte Kundenfeedback zu erlangen.
-Sven Beiling (Associate Partner)
junokai