Was ist ein Minimum Viable Product?

Beim Übergang von 0->1 ist es laut technischer Weisheit wichtig, mit einem MVP zu beginnen. Schließlich können Sie durch den Aufbau eines MVP frühzeitig Feedback erhalten, Kunden früher erreichen und unbekannte Unbekannte aufdecken. Ich stimme diesem Argument zu – meiner Erfahrung nach ist es sehr einfach, viel Zeit damit zu verbringen, an Dingen zu arbeiten, die am Ende keine Rolle spielen, und MVPs mildern diese Bedenken. Aber was ist ein MVP? Erkennen Sie einen, wenn Sie einen sehen? Ein mit Erfahrung gewachsener Geschmack? Lassen Sie es uns aufschlüsseln.

Warum ein MVP erstellen?

Lassen Sie uns zunächst noch einmal zusammenfassen, warum wir MVPs erstellen wollen.

Beim Ingenieurwesen geht es im Wesentlichen darum, Systeme unter bestimmten Bedingungen zu bauen. Das oberste Ziel eines MVP besteht darin, mit einem kleinen Bruchteil des Aufwands letztendlich einen erheblichen Teil der Wertschöpfung zu liefern. Dadurch erhalten Sie frühzeitig Feedback, das Ihnen bei der Priorisierung der restlichen Arbeit hilft. Oftmals ermöglicht es Ihnen, große Teile der Arbeit wegzulassen und sich auf das Wesentliche zu konzentrieren.

Meiner Erfahrung nach habe ich auch festgestellt, dass diese Denkweise einen enormen kulturellen und erfahrungsbezogenen Vorteil für das Team von Ingenieuren hat, die an dem Projekt arbeiten. Die Einschränkungen zwingen Sie dazu, an dem zu arbeiten, was wichtig ist. Es ist befriedigend, Fortschritte vorzeigen zu können. Darüber hinaus vermeiden Sie den Bau von Teilen, die letztendlich nicht so nützlich sind. Es empfiehlt sich, sich nicht zu emotional an Ihren Code zu binden, da Sie ihn sonst möglicherweise wegwerfen müssen. Trotzdem fühlt es sich immer noch verdammt gut an, zu sehen, dass der Großteil Ihrer Arbeit sinnvoll genutzt wird, und es ist traurig, etwas loslassen zu müssen, das Sie überentwickelt haben.

Was ist ein MVP?

Es überrascht nicht, dass es schwieriger ist, einen MVP zu definieren, als zu beschreiben, warum Sie einen wollen. Schauen wir uns die Akronymerweiterung an. Ein MVP ist ein Produkt mit minimaler Komplexität, brauchbarem Nutzen und einem Produkt, das von jemandem verwendet werden sollte, der Ihr Publikum repräsentiert.

Diese Ziele widersprechen sich manchmal. Wie gehen wir also wirklich damit um?

Ein MVP bedeutet NICHT ein kaputtes Erlebnis. Obwohl die Komplexität minimal sein sollte, sollte sie in dem, was sie zu tun versucht, vollständig sein. Es muss nicht versuchen, alles zu tun (das sollte es auch nicht), aber es sollte in dem, was es zu tun versucht, vollständig sein. Die ganze Kunst eines MVP besteht darin, Abkürzungen zu finden, um die Komplexität zu reduzieren und gleichzeitig die Lebensfähigkeit aufrechtzuerhalten.

Dabei ist die Reduzierung des Umfangs ein wesentlicher Bestandteil. Beispielsweise möchte ein MVP von S3 zur Verwendung auf einer einfachen Website möglicherweise get, putund delete. Es braucht wahrscheinlich keine vorsignierten URLs, mehrteilige Uploads und es hat besser noch keine komplexen ACLs.

Allerdings liegt es an Ihnen als Ingenieur und Produktdesigner, auszuwählen, welche Teile die grundlegenden Teile sind, die Sie liefern möchten. Wenn Ihr Produkt ohne ACLs nicht realisierbar ist, wählen Sie einen Mindestsatz an ACLs aus, stellen Sie diese völlig ohne Komplexität bereit und beschränken Sie den Umfang auf den Rest.

Schließlich muss ein MVP an jemanden gehen. Vielleicht geht es an ein paar Early Adopters. Vielleicht geht es an Ihre Freunde oder Ihren Chef. Vielleicht veröffentlichen Sie es mit einem „Beta“-Haftungsausschluss für alle. Das ist alles großartig, aber JEMAND sollte es nutzen, bevor Sie weiter daran arbeiten.

Wie sieht ein erfolgreicher MVP aus?

Es gibt einige erfolgreiche Post-MVP-Szenarien.

• Die Leute lieben es und sehnen sich nach mehr. Bauen Sie weitere Funktionen!
• Die Leute lieben es so wie es ist. Lass es so wie es ist. Bewahren Sie Ihre Feature-Ideen für einen späteren Zeitpunkt auf, an dem sie sich als nützlich erweisen werden. Zumindest wird es ein lustiges Artefakt sein, das man in ein oder zwei Jahren mit Nostalgie betrachten kann. Im besten Fall ist es Ihre Roadmap.
• Die Leute sind nicht begeistert. Iterieren (oder wegwerfen)!

Schleudern Sie weiter Code!