MVP, MMF, PSI, WTF? Teil eins: Das MVP verstehen
Wenn ich mit neuen Product Ownern arbeite, stelle ich häufig fest, dass wir uns in einem Meer von TLAs (Three Letter Acronyms) verfangen, wenn es an der Zeit ist, ihr Backlog an Ideen in veröffentlichbare Wertinkremente zu verwandeln.
Die Idee, die Arbeit aufzuschlüsseln – unsere großen, geplanten Produktveröffentlichungen in kleinere Wertinkremente aufzuschlüsseln – ist der Punkt, an dem viele neue Product Owner Schwierigkeiten haben. Wie können wir diese Produkt-Roadmap in etwas umwandeln, das meine Scrum-Teams tatsächlich in einer kurzen, regelmäßigen Kadenz liefern können? Wie kann ich diese riesige Liste von sehr wichtigen Funktionen (Very Important Features, VIFs) in ein iteratives Set von Gelegenheiten verwandeln, um zu lernen, Wert zu liefern und unseren Kunden tatsächlich etwas in die Hand zu geben? Mit anderen Worten….
„Was ist unser MVP?“
„Ist das unser MMF?“
„Können wir dieses PSI als MVP freigeben, oder brauchen wir noch mehr Geschichten, bevor wir ein MMF haben?“
Auch….was??
Was bedeuten diese TLAs? Wie unterscheiden sie sich voneinander? Wie sind sie verwandt? Warum sollte ich mich dafür interessieren?
Anfangend mit MVP (Minimum Viable Product) wird diese dreiteilige Serie Anfängern helfen zu verstehen, was diese TLAs bedeuten. Wie unterscheiden sie sich voneinander? Wie hängen sie zusammen? Warum sollte ich mich dafür interessieren? Sie wird auch dazu beitragen, diejenigen, die schon eine Weile agil arbeiten, daran zu erinnern, warum diese Konzepte die Dreh- und Angelpunkte der Agilität sind.
Wer gerade erst anfängt, Scrum kennenzulernen, kann sich an den Scrum Guide wenden… und lernt schnell, dass der Scrum Guide nichts darüber aussagt, wie man ein Produkt in eine Sammlung von kleinen, freigebbaren Wertinkrementen verwandelt.
Der Mangel an Informationen zu diesem wichtigen Thema kann für neue Product Owner wirklich frustrierend sein. Ich hoffe, dass der Rest dieses Artikels die MVP’s klären wird, und es gibt immer Certified Scrum Product Owner Kurse, die Sie für weitere Informationen besuchen können. Lassen Sie uns erst einmal in das Minimum Viable Product eintauchen.
Das MVP
Sie haben recherchiert, Sie haben Kundenfokusgruppen durch ein paar Runden Buy a Feature geführt und Sie haben einige Entscheidungen darüber getroffen, wie Ihre nächste Version aussehen könnte. Sie haben sogar Ihr Marketingteam eingeschaltet und arbeiten an Ideen, wie Sie für Aufsehen sorgen können – Anzeigen in Fachzeitschriften, beworbene Tweets, Facebook-Posts…
Aber es gibt immer noch einige quälende Fragen zu einigen der Funktionen, an denen Sie arbeiten. Sie haben darüber nachgedacht, Sie haben sie analysiert, aber da ist diese Stimme in Ihrem Kopf, die immer wieder fragt: „Aber woher wissen Sie das?“
Hier kommt das MVP ins Spiel – nicht Steph Curry, sondern das (vielleicht falsch benannte) Minimum Viable Product.
Das Lean-Startup-Rätsel
In seinem Buch „The Lean Startup“ definiert Eric Reis den Begriff „Minimum Viable Product“ verwirrend neu, wie er 2015 in einem Interview erklärt. Kurz gesagt:
„Einige Vorbehalte gleich vorweg. Bei MVP geht es trotz des Namens nicht darum, minimale Produkte zu schaffen. Zweitens bedeutet die Verwendung der Wörter Maximum und Minimum in der Definition, dass sie definitiv nicht formelhaft ist.“
Wenn also die Welt des Product Ownership und die agile Gemeinschaft das Minimum Viable Product neu definiert hat, so dass es weder darum geht, das Minimum noch Produkte zu schaffen, was ist es dann?
Alles über das Lernen
Diese nagende Stimme in Ihrem Hinterkopf, die sich fragt, ob es einen Weg aus der Analyse-Lähmung gibt, in der Sie stecken, und die versucht, einen Weg zu finden, die Antworten auf einige Ihrer Fragen tatsächlich zu kennen, anstatt sich selbst in ein tieferes Gefühl der falschen Sicherheit zu analysieren? Hier kommt das Minimum Viable Product (MVP) ins Spiel.
Während es bei einem PSI (Potentially Shippable Increment) darum geht, die Möglichkeit zu schaffen, potenziell etwas Wertvolles zu liefern, und beim MMF (Minimum Marketable Feature) darum, diese wertvollen Teile zu einer Sammlung von Funktionen zu kombinieren, die Kundenprobleme lösen, geht es beim MVP darum, das Minimum an Arbeit zu leisten, das Ihr Team leisten kann, um eine validierte Lernschleife zu schließen.
In der Lean-Startup-Methode der Produktentdeckung ist eine der wichtigsten Gewohnheiten, die man sich aneignen muss, die Gewohnheit, Hypothesen zu validieren und Experimente durchzuführen. In traditionell eher risikoscheuen Unternehmen führt der Glaube, dass das Risiko vor der Markteinführung aus dem Produkt herausanalysiert werden muss, zu langen Vorlaufzeiten und frustrierenderweise zu datenbasierten Annahmen über die Wünsche und Bedürfnisse der Kunden. Wenn wir wirklich gut in der statistischen Analyse sind, und wenn wir wirklich gute Daten über einen statistisch signifikanten Teil unserer Kunden haben, können wir eine ziemlich gute Arbeit leisten, um eine fundierte Vermutung darüber zu formulieren, was unsere Kunden wollen.
Aber am Ende des Tages ist das immer noch eine Vermutung.
Wenn wir MVPs erstellen, bauen wir absichtlich gerade genug Funktionalität, um unseren Kunden die richtigen Fragen zu stellen – würden Sie dieses Produkt kaufen? Machen diese Symbole Sinn? Frustriert Sie dieser Arbeitsablauf oder hilft er Ihnen, Ihr nächstes Lieblingsrestaurant zu finden?
Zu diesem Zeitpunkt sehen wir uns Papierprototypen, Website-Wireframes, UI-Mock-ups an; wir gehen über die Straße zum Einkaufszentrum, um unsere Entwürfe den Leuten zu zeigen, die uns am nächsten sind, nur um schnell zu überprüfen, ob wir auf dem richtigen Weg sind.
Die Magie bei der Erstellung eines guten MVP liegt jedoch nicht in den Werkzeugen oder Techniken, sondern in der Disziplin, wenn man Daten aus einer Website-Heatmap analysieren will, um herauszufinden, welches Farbschema am besten funktioniert, stattdessen ein paar Stifte und Papier zu nehmen, ein paar Low-Fidelity-Lösungen zu skizzieren und jemanden zu fragen: „Welche davon gefällt Ihnen besser?“