Das Minimum Viable Product als Experiment

Das Minimum Viable Product (MVP) ist ein Kernelement in unseren Product-Owner- und ScrumMaster-Trainings. In jedem Training reflektiere ich mit den Teilnehmenden darüber, wie uns ein MVP in die Lage versetzt, zeitnahes Feedback einzuholen. Durch dieses Feedback minimieren wir die Gefahr, ein Produkt oder ein Service zu entwickeln, das an den Bedürfnissen und Wünschen unserer Kunden vorbei geht. Wir nutzen also das Minimum Viable Product, um Hypothesen zu testen. Das können wirtschaftliche, marktbezogene oder fachliche Hypothesen sein. Ein MVP ist im Grunde nichts anderes, als ein Experiment, das uns erlaubt, echtes Verhalten zu erforschen.

Meistens zeige ich folgenden Agile Sketch, der visualisiert, wie ein MVP aufgebaut ist. Unser Minimum Viable Product ist ein Durchstich durch alle Funktionalitätsgruppen, die unser Produkt ausmachen. Ähnlich einem Kuchenstück beinhaltet ein MVP alle „Schichten“ eines Produkts.

Oft beginnt dann ein Austausch darüber, wie ein MVP aussehen kann und wann es „gut genug“ ist, um an Kunden ausgeliefert zu werden. Lassen Sie uns die Antworten zu beiden Fragen erkunden.

Wie sieht ein Minimum Viable Product aus?

Ich möchte Ihnen im Folgenden einige Beispiele zeigen, die das Design von MVPs greifbarer machen:

Das Video-MVP

Viele von Ihnen kennen den File-Sharing-Anbieter Dropbox. Um sich von bestehenden Anbietern abheben zu können, musste sich Dropbox seinerzeit signifikanten technischen Herausforderungen stellen. Ein erstes MVP der Software zur Problemhypothesentestung hätte hohen Entwicklungsaufwand bedeutet, den sich das Unternehmen damals nicht leisten konnte. Also griff der CEO zu einer sehr simplen Lösung: Dropbox veröffentlichte ein Video, das simulierte, wie das Produkt später funktionieren würde. Quasi über Nacht registrierten sich 75.000 potentielle Kund:innen, um die Betaversion testen zu können. Dropbox hatte offenbar einen Schmerzpunkt der Kund:innen identifiziert.

Das Concierge-MVP

Eric Ries beschreibt in seinem Buch „The Lean Startup“ das Concierge-MVP. Im deutschsprachigen Raum wird unter einem Concierge-Service die persönliche Betreuung von Kund:innen verstanden. Gleiches gilt für ein Concierge-MVP: Hier wird der oder die Kund:in persönlich (wörtlich: von einer Person) zur Lösung seines oder ihres Problems begleitet. Ein zugängliches Beispiel ist ein Online-Coupon-Service. Stellen wir uns vor, dass dieser Service eine absolute Innovation ist (wie er es vor einigen Jahren war). Anstatt eine Software zu entwickeln und am Markt zu testen, sprechen wir einfach mit einem potentiellen Kunden. Entweder in persona, am Telefon oder per E-Mail. Wir fragen die Kundin, was sie kommende Woche einkaufen möchte und suchen dann die besten Rabatt-Coupons heraus.

Sie finden dieses Vorgehen ineffizient? Absolut! Es geht bei dieser Art des MVPs nicht darum, Produktfunktionalitäten zu testen. Wir wollen herausfinden, wer überhaupt unser Kunde ist und ob wir das richtige Problem lösen. Für diese Art Hypothesen-Testung eignet sich der persönliche Kontakt bestens. Natürlich ist dieses Vorgehen nicht skalierbar. Sobald wir unsere Kunden- und Problemhypothese validiert haben, müssen wir mit echten Produkt-MVPs fortfahren.

Das Papier-MVP

Vor allem zum Testen von Design-Hypothesen eignet sich auch das Papier-MVP. Ein von mir begleitetes Team hat mit einem solchen MVP gearbeitet, um Feedback zu verschiedenen Designs für das zu entwickelnde Software-Tool zu bekommen. Streng genommen handelt es sich bei dieser Variante des MVP eher um einen klassischen Prototyp, da hier nicht der oben beschriebene „Durchstich“ durch die Produktfunktionalitäten erfolgt, sondern der Fokus auf dem Design liegt.

Wie viel Qualität muss sein?

Eine zweite Frage, die von Trainingsteilnehmenden oft gestellt wird, ist die Frage nach der Qualität eines MVP. Vielen Teilnehmenden ist die Vorstellung, ein Produkt minderer Qualität auf den Markt zu bringen, ein Graus. Meine Gegenfrage lautet dann: Was ist denn eigentlich „Qualität“?

Wir können nur dann definieren, was Qualität bedeutet, wenn wir die Kundengruppe kennen, die das MVP ansprechen soll. Befinden wir uns in einem klassischen Scrum-Umfeld und arbeiten an etwas Innovativem, dann sind die Adressaten für unsere ersten MVP meist die sogenannten Early Adopters. Also diejenigen Nutzer:innen, die als erste Neuerungen ausprobieren möchten. In der Regel erhoffen sich Early Adopters einen Wissens-, Trend- oder Nutzenvorsprung. Minimum Viable Products, die diese Kundengruppe ansprechen sollen, dürfen gar nicht perfekt sein. Ein perfektes Produkt kann schließlich von jedem angenommen werden. Welchen Vorteil hätten also die Early Adopters? Ein sehr gutes Beispiel ist das erste Apple iPhone. Early Adopters haben sich um das iPhone gerissen, obwohl es aus heutiger Sicht sehr rudimentär war: ohne Copy-Paste-Funktion, ohne Highspeed Internet, ohne Unterstützung für Firmen-E-Mails.

Andersherum: Wenn unser Produkt mit der Zeit an Reife gewinnt und wir neue Marktsegmente abseits der Early Adopters erschließen wollen, müssen wir uns auf die veränderten Qualitätsansprüche des Mainstreams einstellen. Der Mainstream braucht zwingend eine gewisse Produktqualität, damit der entsprechende Kaufanreiz gesetzt wird.

Tauschen wir uns aus

Sie sehen also: Auch das Minimum Viable Product ist ein lebendes und dynamisches Artefakt.

Welche Erfahrungen haben Sie mit dem Einsatz von MVPs gemacht? Was sind die Herausforderungen, die Ihnen begegnen? Ich freue mich auf den Austausch mit Ihnen!

Quelle und weiterführende Literatur: „Lean Startup“ von Eric Ries.