MVP: So funktioniert agile Entwicklung im E-Commerce

Check-in, Produktliste, Check-out ‒ das eher simple Strickmuster früherer Onlineshops wird aktuellen Anforderungen längst nicht mehr gerecht. Als zentrale Schnittstelle einer unternehmensweiten Digitalisierungsstrategie haben sich Shops inzwischen zu komplexen Plattformen entwickelt. 

Diese Komplexität hat Einfluss auf die Produktentwicklung. Und zwar ganz wesentlich, sind wir von dmf überzeugt. Mit einem dickeren Lastenheft ist es dabei nicht getan. Auch wenn der Begriff inzwischen für alles Mögliche herhalten muss, setzen wir von dmf bewusst auf das agile Arbeiten in der Softwareentwicklung. 

In sogenannten Sprints entsteht ein Shop schrittweise, anstatt in einem einmaligen großen Wurf. Jede Version beinhaltet neue Funktionen, ist fehlerfrei und nutzbar. Die allererste lauffähige Version ist das sogenannte “MVP”. 

Kleiner Einsatz, große Wirkung

MVP steht für „Minimum viable Product“ – manche nennen es auch „Minimal Viable Product“. Wörtlich übersetzt, sprechen wir von einem „minimal brauchbaren oder existenzfähigen Produkt“. Gemeint ist damit die kleinste Lösung einer Produktidee, die für sich stehend funktionsfähig ist und Feedback generieren kann. 

Das Ganze ist nicht neu. Bereits 2001 im Silicon Valley entstanden, erfuhr der Ansatz eine rasche Verbreitung über Ländergrenzen hinweg. Zurecht, meinen wir. Denn im Grunde hat ein MVP nur Gewinner:innen. 

Während in tradierter Vorgehensweise möglichst alle Bedürfnisse der Kund:innen erfüllt werden sollen und ein Produkt entwickelt wird, das nicht nur viel zu teuer ist, sondern am Ende sogar an sich verändernden Erwartungen vorbei arbeitet, konzentrieren wir uns beim Minimum Viable Product auf die wesentlichen Kernfunktionen und bringen es zeitnah in den Einsatz. 

Darin liegt der große Vorteil eines MVP. Es werden ständig Ergebnisse produziert, die gemeinsam gesehen, getestet und optimiert werden können. Kund:innen sind bei jedem Schritt mit im Boot. Der frustrierende Blindflug und teure Fehlentwicklungen lassen sich damit vermeiden. 

Stets besteht die Möglichkeit, das grundlegende Konzept zu optimieren und an neue Erkenntnisse anzupassen. Das ist gerade im E-Commerce wichtig, denn die Ansprüche und Anforderungen der Endkund:innen verändern sich ständig. Was zum Projektstart vielleicht noch angesagt war, kann nach ein paar Monaten bereits ein alter Hut sein.

Die hohe Umsetzungsgeschwindigkeit spart nicht nur finanzielle Ressourcen, sondern macht auch uns Entwickler:innen viel mehr Spaß. 

Bauen. Messen. Lernen.

Es geht bei der Entwicklung eines MVP nicht um ein fertiges Produkt, sondern vielmehr um die Validierung einer Idee. Hauptziel ist das Einholen von Nutzerfeedback an einem möglichst frühen Zeitpunkt. 

Dafür wird zu Beginn eine Annahme getroffen. Zum Beispiel: Der Shop soll nur mit Schwarz-Weiß-Fotos arbeiten. Auf der Basis gehen die Entwickler:innen an die Arbeit. Ist das MVP fertig, erfolgt der Release und die erste Vermarktung: Möglicherweise werden mit einem kleinen Budget Facebook- oder Google-Anzeigen geschaltet, um die ersten Nutzer:innen zu generieren ‒ die Tester:innen des MVP.

In der Measure-Phase werden alle Schritte, beispielsweise Klicks, Verweildauer, Ausstiegsseiten, der Nutzer:innen gemessen. Anhand der Messergebnisse kann dann ermittelt werden, ob das MVP ankommt und ob die Nutzer:innen die Features wie erwartet nutzen. Aufgrund dessen lassen sich neue Annahmen treffen, mit denen die nächste Iteration des MVP gebaut wird, die genau die gleichen Phasen durchläuft. 

Händler:innen werden so in die Lage versetzt, ihre Annahme schnell am Markt zu testen. Bewahrheiten sich Hypothesen nicht, werden sie aussortiert. Positive Hypothesen lassen sich valide weiterverfolgen. Schritt für Schritt  und ganz nah am Kunden entsteht so ein Produkt, das stetig neue Features erhält. 

Annahme bilden: Die User Story

Annahmen entstehen nicht aus einer Laune heraus oder morgens unter der Dusche. Vielmehr sind sie Ergebnis eines gemeinsamen kreativen Prozesses. Ein zentraler Bestandteil sind sogenannte User Stories. Der Name sagt es schon: In der Entwicklung stehen jene im Mittelpunkt, für die wir entwickeln ‒ die Nutzer:innen des Produktes.

User Stories beinhalten die Features, die Endbenutzer:innen brauchen, und Informationen, wie diese ausgestaltet sein sollen. Anders als es die Bezeichnung User Story vermuten lässt, geht es nicht darum, eine längere Geschichte zu schreiben, sondern in wenigen Sätzen festzuhalten, was die Anforderung ist. Dabei sind diese drei Leitfragen eine gute Orientierung:

• Für welchen Kunden- bzw. Endbenutzer-Typ wird entwickelt?

• Was wünscht sich dieser User-Typus an Features?

• Welchen Nutzen erhofft sich der User davon?

Ein Beispiel: „User X möchte eine Vergleichsfunktion verschiedener Produkte haben, um sich im Kaufprozess besser entscheiden zu können.“ Damit wäre die grobe Schlagrichtung für das Entwicklerteam klar: Es braucht ein Tool, das diesen Vergleich ermöglicht. Welche Produktarten miteinander vergleichbar sein sollen und welche Vergleichsparameter konkret angedacht werden, klärt das Team idealerweise mit dem oder der Auftraggeber:in sowie möglichen Test-User:innen.

Als benutzerorientierte Zielmarken sorgen User Stories für die notwendige Orientierung in der täglichen Programmierarbeit. Sie visualisieren den konkreten Wert, den jeder einzelne  Entwicklungsschritt erzeugt. Sind alle Aufgaben einer Story erledigt, ist die Story erfüllt. Sind alle Storys erfüllt, so ist das MVP fertig.

Demut hilft

Eine entscheidende Voraussetzung für die Entwicklung eines MVP ist das richtige Mindset. Auch wenn Shopbetreiber:innen eine Menge Ideen im Kopf haben und sich mit ihrem Produkt bereits an der Zielfahne stehen sehen, ist es wichtig, einen Schritt zurückzutreten und diejenigen zu Wort kommen zu lassen, die tatsächlich über den Erfolg des Produktes entscheiden: die User:innen. Es hilft, sich davon zu verabschieden, dass die eigene Wahrnehmung das Maß aller Dinge ist. Es braucht Mut, um die eigenen Ideen auf den Prüfstand zu stellen und sich auch der möglichen Tatsache zu stellen, dass die eigene Idee vielleicht nicht so gut ist wie gedacht. Noch nicht.