xingtwittersharerefreshplay-buttonpicture as pdflogo--invertedlinkedinkununuinstagram icon blackShapeGroup 3 Copy 2Group 2 Copydepartment_productdepartment_datascienceuserclosebasic clockblogShapearrows slim right copy 3arrows slim right copy 3arrows slim right copy 3

Lean Product Management (Teil 1) - Wie definiert man einen MVP?

Fabian

Fabian |

06. May 2014 |

- min Lesezeit

Der MVP (Minimal Viable Product) ist der schnellstmögliche Weg ein Produkt zur Marktreife zu führen. Er umfasst nur die notwendigsten Funktionen, die zur Benutzung benötigt werden. Wir verraten euch mit welcher Frage Ihr die größten Probleme bei der MVP-Definition löst - und wie Ihr nach dem Live-Gang weiterarbeitet.

Lean Startup Methoden fokussieren meistens auf die Erstellung neuer Produkte. Zugrunde liegt jedoch der Gedanke der Risikominimierung. Und Risiken gibt es sowohl bei der Neu- als auch bei der Weiterentwicklung von Produkten. Im ersten Teil unsere Artikelserie zum Lean Product Management beschäftigten wir uns mit der Definition des MVPs und der Arbeit nach dem Launch des MVPs.

Feature Priorisierung: Wie definiert man ein Minimal Viable Product (MVP) und was kann man daraus lernen?

“Löst das Feature das Problem des Nutzers?” Diese Frage ist zentral bei der Definition des MVPs. Um diese Frage beantworten zu können, müssen die Lean Startup und Customer Development Hausaufgaben gemacht sein:

  • Der Lean Canvas ist erstellt.
  • Das Problem/Bedürfnis des Kunden ist anhand von Problem Interviews validiert.
  • Der Lösungsansatz wurde anhand von Solution Interviews genau definiert.

Damit und mit einer Reihe von Prototypen liegt in der Regel ein ziemlich gutes Verständnis über den Umfang des MVPs vor. Und trotzdem gibt es immer wieder Entscheidungen über kleinere Features, Design sowie Umfang und Nachhaltigkeit der Implementierung zu treffen.


Der MVP sollte das wichtigste Problem / Bedürfnis des Nutzers lösen. Dieses sollte durch Problem und Solution Interviews und mit Hilfe von Prototypen validiert sein. Und bei jedem Feature sollte man sich fragen, ob es zur Lösung dieses Problems / Bedürfnisses beiträgt!

Unsere Empfehlung


Was tun bei komplexeren Produkten?

Oft tut man sich, insbesondere in größeren Unternehmen, schwer damit nur ein einziges Problem / Bedürfnis zu lösen. Manchmal liegt es auch am gewählten Bedürfnis (z.B. Unterhaltung), dass eine einfache Wahl des wichtigsten Problems / Bedürfnisses nicht möglich ist. Hierbei kann der folgende Ansatz zu Priorisierung von streetsmartproductmanager helfen:

  1. Die Probleme / Bedürfnisse der Kunden priorisieren.
  2. Die Elemente der Lösung (Solution) den Problemen / Bedürfnissen zuordnen.
  3. Die einzelnen Features auf die Lösungselementen mappen. Damit erhält man eine grundlegende und überschaubare Priorisierung.
  4. Innerhalb der Lösungelemente muss man sich dann noch überlegen, ob das Feature wirklich für den MVP relevant ist oder später nachgeliefert werden kann.

Beispiel-Case:

Ein Bedürfnis des Nutzers ist es für seine Reiseplanung Spots und Inspiration aus unterschiedlichen Quellen zu sammeln und zu speichern. Zum Speichern muss er sich registrieren, damit ihm die Daten wieder zugeordnet werden können (und er sie auch auf anderen Devices abrufen kann).

  • Bedürfnis: Sammeln von Spots aus unterschiedlichen Quellen (wichtigstes Bedürfnis, MVP)
  • Lösung: Speichern von Spotlisten für den Nutzer (MVP)
  • Feature: Login / Registrierung (MVP)

Frage: Ist die Integration von Social Login über Facebook und Twitter nun auch ein MVP Feature oder nicht?

Mut zur Lücke

Nach unserer Erfahrung ist die MVP-Definition in nahezu allen Unternehmen und selbst bei unseren Produkten der schwierigste. Hier kann man erleben, wie schwer es uns Menschen fällt von unserem Grundbedürfnis nach Perfektion und Vollständigkeit abzusehen und bewusst unvollständige Produkte live zu nehmen. Es ist eine schwere Entscheidung und als Feedback hört man dann oft den Wunsch nach genau den Features, die man schweren Herzens nach hinten gestellt hat.

Aber hey, war das nicht genau der Grund, warum wir den MVP live genommen habe, um genau diese Art des Feedbacks zu bekommen? Um zu erfahren, welche Features wichtig sind und welche nicht? Umso besser, wenn man mit seiner Einschätzung richtig lag.

Und was kommt danach?


Der Tag an dem der MVP live geht ist nicht das Ende der Entwicklung - sondern der Beginn! Mit einem schlanken MVP hindert euch niemand daran, drei Tage später genau dieses meist nachgefragte Feature nachzuschieben und das Produkt weiterzuentwickeln.

Immer dran denken


Und schließlich ist der MVP die wichtige Grundlage für weiteres Lernen, denn ab dem MVP muss in zwei Richtungen gelernt werden:

  1. Weiterentwicklung (Product Discovery): Welche Funktionen sind als nächstes wichtig?
  2. Optimierung (Product Execution): Wie können die vorhandenen Funktionen verbessert werden, damit sie einfacher verständlich und häufiger genutzt werden?

Ausblick

In den nachfolgenden Artikeln erklären wir, wie man auch bei der Produktweiterentwicklung lean bleiben kann, welche Tools wir zur Priorisierung nutzen und wie wir eine flexible Roadmap erstellen.



Ähnliche Artikel

Ähnliche Artikel