Minimum Viable Product – ein Blog geht live

Minimum Viable Product (MVP) ist kein Begriff aus dem Scrum Framework. Dennoch hört und liest man MVP recht häufig im agilen Umfeld. Was genau ist ein Minimum Viable Product? Und wozu dient es?

Mia: Mir war der Begriff Minimum Viable Product (MVP) auch erst mal neu. Einer unserer Product Owner hat mir vom MVP erzählt, als ich anfing diesen Blog hier aufzubauen. Deshalb kann ich das MVP auch am besten am Beispiel Scrum@Sciosoft.de erklären.

Also: Was genau ist denn das Minimum Viable Product?

Mia: Wikipedia erklärt das recht griffig: „Ein Minimum Viable Product (MVP) … ist die erste minimal funktionsfähige Iteration eines Produkts, das entwickelt werden muss, um mit minimalem Aufwand den Kunden-, Markt- oder Funktionsbedarf zu decken und handlungsrelevantes Feedback zu gewährleisten.“
Wenn man in Geschäftsprozessen denkt ist das MVP also nichts anderes als der schmalste Durchstich durch den Prozess. Die finale Funktionsbreite ist lange noch nicht erreicht, aber als Anwender kann man den Prozess von Anfang bis Ende anwenden und als Anbieter ist man in der Lage Feedback vom Anwender dazu einzuholen.

Das Minimum Viable Product kommt eigentlich aus dem Konzept Lean Startup* von Eric Ries. Es soll Gründern helfen das Minimum an Produkt zu finden, mit dem sie an den Markt gehen können, um zu testen wie das Produkt bei den Kunden ankommt. Auf die richtigen Fragen hat uns unter anderem auch dieser Beitrag hier gebracht. Allen voran: „Was wollen wir mit dem Minimum Viable Product lernen und wie machen wir das?“
Beim Lean Startup gilt die Annahme, dass man vor Marktstart des Produkts nichts über die Kunden und deren Wünsche weiß. Das MVP dient also dazu, die zentralste Annahme zu überprüfen: Wird die Zielgruppe das Produkt kaufen? Diese Idee lässt sich 1:1 auf unseren Blog übertragen: Wird die Zielgruppe den Blog lesen? Und noch weiter: Wie sieht die Zielgruppe überhaupt aus?

Das kommt mir sehr bekannt vor. Ich kenne das aber als „Walking Skeleton“.

Mia: Im Grunde steckt hinter beiden Begriffen Minimum Viable Product und Walking Skeleton auch das Gleiche. Das Walking Skeleton wird beschrieben als die einfachste Umsetzung eines kompletten Funktionsbereiches eines Produkts. Das deckt sich also mit der MVP-Definition.
Es gibt aber noch eine weitere Definition des Walking Skeleton: Jeff Patton, von dem wir uns die Methode User Story Mapping abgeschaut haben, versteht unter dem Walking Skeleton einen zentralen Prozess, den er als Gruppierungskriterium für User Stories in User Story Maps verwendet. Da die User Story Map für uns sehr hilfreich war haben wir uns für das Minimum Viable Product als zentralen Begriff für unser minimales Produkt entschieden. Wir bilden den zentralen Prozess des MVP als Walking Skeleton in einer User Story Map ab. Wir nutzen also beide Begriffe.

Warum habt ihr Euch denn für eine User Story Map entschieden? Hätte ein Product Backlog nicht gereicht?

Mia: Wir arbeiten natürlich mit einem Product Backlog. Der Nachteil an so einem Anforderungsstapel ist aber, dass man keinen guten Überblick hat. Ein Backlog ist eben ein hierarchieloser Stapel. Ab einer gewissen Größe wird das Backlog sehr unübersichtlich, weil es nach Kundenwert und nicht nach Zusammenhängen sortiert ist. Deshalb haben wir neben dem Product Backlog eine so genannte User Story Map aufgebaut, um darin das MVP abzubilden.

Wie habt ihr dieses MVP definiert?

Mia: Wir haben eine recht simple Anleitung gefunden und sind dieser einfach gefolgt. In der Schritt-für-Schritt-Anleitung sind 5 Schritte beschrieben:

  1. Beschreibe das primäre Ziel des Produkts
  2. Definiere den zentralen Prozess
  3. Lege eine Funktionsliste für jeden Schritt des zentralen Prozesses an
  4. Priorisiere die Funktionslisten innerhalb der Prozess-Schritte
  5. Definiere das MVP

Ok. Und wie lautet Euer primäres Ziel für den Blog?

„Der Blog soll eine praxisbezogene Informations- und Austauschplattform für alle an Agilen Arbeitsweisen und Methoden Interessierte sein!“


Und dann habt ihr im zweiten Schritt den zentralen Prozess definiert, richtig?

Mia: Ja, richtig. Wir haben dabei drei Perspektiven unterschieden:

  • Die Prozess-Sicht aus Besucher-Perspektive
  • Unsere „Gründer“-Perspektive
  • Die Regel-Perspektive: Alle Dinge, die zwingend vorgeschrieben sind

Der zentrale Prozess bezieht sich ausschließlich auf die Schritte, die ein Besucher durchläuft. Wir sind beim Durchdenken des Prozesses auf folgende Schritte gekommen:

  1. Der Besucher landet auf unserem Blog
  2. Der Besucher findet Inhalte
  3. Der Besucher kann Inhalte lesen
  4. Der Besucher lernt die USP (Unique Selling Points) des Blogs kennen
  5. Der Besucher kann Inhalte kommentieren
  6. Der Besucher kann sich zukünftig über neue Inhalte informieren lassen

Die gefundenen Schritte des zentralen Prozesses bilden die Spaltenüberschriften der User Story Map. Die Prozessabfolge wird von links nach rechts dargestellt. Das Walking Skeleton, also der zentrale Prozess, sah daher folgender Maßen aus:

Minimum Viable Produkt mit User Story Map
Walking Skeleton – der zentrale Prozess

Darüber hinaus gab es Fragen, die nicht direkt etwas mit dem zentralen Prozess zu tun haben:

  1. Wie finden wir heraus, ob der Blog gelesen wird und welche Themen genau die Blog-Besucher interessant finden?
  2. Welche Pflicht-Inhalte und -Funktionen gibt es?
  3. Wie optisch ansprechend muss der Blog für den Besucher sein?

Funktionen, die nicht zum zentralen Prozess gehören, haben wir ganz rechts abgebildet.

Die Überschriften der User Story Map sahen also so aus:

Minimum Viable Produkt mit User Story Map
Walking Skeleton mit weiteren Anforderungen

Was kam dann?

Mia: Dann haben wir alle Funktionen und Inhalte, mit denen wir die Prozess-Schritte abbilden konnten, in die jeweilige Spalte gehangen und in die passende Reihenfolge gebracht. Was zuerst umgesetzt werden sollte steht oben in der Spalte, wie im Product Backlog.

Minimum Viable Produkt mit User Story Map
User Story Map Scrum@Sciosoft.de

Im letzten Schritt haben wir die Funktionen markiert (rot umrandet), die wir unbedingt für den Start brauchten. Und Tata: Das Minimum Viable Product war sichtbar!

Jetzt waren die Funktionen definiert, mit denen wir an den Start gehen konnten. Weniger hätte nicht gereicht und mehr haben wir für den Start nicht benötigt.

Minimum Viable Produkt mit User Story Map
User Story Map Scrum@Sciosoft.de mit MVP

Warum war das MVP rückblickend denn so wichtig für Euch?

Mia: Der MVP-Gedanke hat uns sehr dabei geholfen uns zu fokussieren. Gerade in der Angangsphase. Wie bei den meisten neuen Produkten, die an den Markt gehen sollen, ist erst einmal sehr unklar, welche Funktionen und Inhalte am Markt benötigt werden. Naheliegend ist also erst einmal den Markt zu befragen, um die Bedürfnisse zu verstehen. Das geht am einfachsten in Form von Umfragen. Andererseits passt es in einem agilen Umfeld am besten so schnell es geht mit einem potentiell auslieferbaren Produkt an den Markt zu gehen und es ausprobieren zu lassen. Die Erfahrungen aus dem Ausprobieren sind Erkenntnisse darüber, was der Markt braucht. Wir haben uns für beides entschieden: Umfrage UND sofort den Blog als MVP an den Markt bringen.

Außerdem lief natürlich nicht alles nach Plan. Wir wurden sogar ein paar Mal böse überrascht, hatten uns aber einen fixen Zeitpunkt gesetzt für den Go-Live. Deshalb mussten wir inhaltlich bzw. funktional Abstriche machen. Dabei hat uns der MVP-Gedanke sehr geholfen zu entscheiden was wirklich gebraucht wird und was wir auch später implementieren konnten.

Und nicht weniger wichtig: Wir konnten anhand des MVPs in der User Story Map recht schnell erkennen, welche Funktionen einen Website-Baukasten out of the box mitbringen sollte. Die Entscheidung war recht schnell für WordPress gefallen, da hier insbesondere für Blogs viele Funktionen im Standard mit ausgeliefert werden. Und was es nicht gibt kann man mit Hilfe von Plugins dranbauen ohne wirklich Entwickeln zu müssen.
Die Funktionen Menü, Seiten und Beiträge und eine Kommentarfunktion waren damit schon einmal im Standard erschlagen. Für alle übrigen Funktionen des MVPs konnten wir Plugins finden oder die Anforderungen als Inhalte (Seiten) abbilden. Das Minimum Viable Product stand innerhalb weniger Tage. Der Blog Scrum@Sciosoft.de konnte schnell an den Start gebracht werden und Feedback generieren.

Vielen Dank Mia für die Hintergründe und Informationen. Und jetzt seid Ihr dran: Welche Erfahrungen mit MVPs und Walking Skeletons habt Ihr?

Super Artikel? Dann teile ihn mit Deinen Freunden und Kontakten
Share on xing
Xing
Share on linkedin
Linkedin
Share on facebook
Facebook
Share on twitter
Twitter
Share on pinterest
Pinterest
Share on email
Email
Share on whatsapp
Whatsapp

Eine Antwort auf „Minimum Viable Product – ein Blog geht live“

  1. Vielen Dank für diesen informativen Blogartikel über das MVP. Ich finde ein MVP ist eine entscheidende Phase in der Produktentwicklung, und es ist großartig, dass ihr das Konzept habt.

    Ich kann auch eine weitere Ressource empfehlen. Auf der Website von Flyacts findet ihr einen ausführlichen MVP-Guide, der detaillierte Informationen und praktische Einblicke in die MVP-Entwicklung bietet: https://www.flyacts.com/guide-zur-mvp-entwicklung

    Beste Grüße

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert