Sind MVPs überhaupt etwas für uns?

Der Begriff „Minimum Viable Product“ (MVP) hat sich weit über die Start-up-Community hinaus verbreitet, nachdem er in Eric Riess‘ „The Lean Start-up“ etabliert wurde.
Das bedeutet allerdings nicht, dass er ohne Kritik ist – es gibt Skeptiker, Kritiker und Befürworter in großen sowie kleinen Unternehmen.

Was ist also mit dem MVP los?

Aus unseren Gesprächen mit Hunderten von Produktmenschen in unseren Kursen und in unseren Produktmanagement-Assessments wissen wir, dass es sehr unterschiedliche Ansichten darüber gibt, was der Begriff eigentlich bedeutet.

Die Befürworter von MVP schätzen die Absicht hinter dem Ansatz – nämlich den Kunden so schnell wie möglich ein Produkt zu liefern, damit Sie von ihnen ein echtes Feedback darüber erhalten (sowohl zur Nutzung selbst, und ob Sie bereit wären dafür zu zahlen).
Diese Erkenntnis war damals ein Durchbruch und die Logik unbestechlich – trotzdem müssen wir uns die Frage stellen, warum es sogar Menschen gibt, die MVPs eine leidenschaftliche Abneigung entgegenbringen.

Was ist ein MVP für Sie?

Ein häufiges Problem ist, dass sich die meisten Menschen auf den „minimalen“ Teil des Begriffs konzentrieren und den „viable“, also lebens- und wachstumsfähigen Teil vernachlässigen. Davon abgesehen gibt es aber auch noch weitere Schwierigkeiten mit dem Begriff.

Eine zentrale Herausforderung, auf die wir uns konzentrieren werden, ist, dass das, was in einem Markt als schnell (minimal), wertvoll und nützlich (lebensfähig) gilt, in einem anderen als riskant, wertlos und unterbewertend gewertet werden kann. Diese Verwirrung führt zu Unsicherheit darüber, ob man als Unternehmen überhaupt darauf abzielen sollte, MVPs zu liefern, und wenn ja, wie schnell sie wirklich bei der Bereitstellung sein können.

Lassen Sie uns zwei verschiedene Unternehmen vergleichen, um den Hintergrund dieser Verwirrung zu beleuchten:
Eines der Unternehmen ist ein neues SaaS-Anbieter, der eine Anwendung bereitstellt, mit der Verbraucher persönliche To-Do-Listen und Erinnerungen verwalten können. Das andere ist ein etablierter Anbieter einer Buchhaltungs-Software, die normalerweise „hinter der Firewall“ (d.h. auf der Infrastruktur des Kunden) eingesetzt wird. Dieser Anbieter möchte mit seinem Produkt ebenfalls auf eine Cloud-basierte Variante umsteigen.

Das Consumer SaaS-Unternehmen möchte seine Bemühungen darauf konzentrieren, den potentiellen Kunden schnell zu vermitteln, was seine minimale Anwendung bieten sollte, um seine Annahmen über den Nutzen des Produkts zu validieren. Sie liefern es, vermarkten es, erhalten Feedback und iterieren das Produkt durch inkrementelle Entwicklungen. Sie liefern ein Produkt, das ziemlich zuverlässig ist. Die Funktionalität mag limitiert sein, aber es tut, was für den Zielmarkt nützlich ist. Die App ist für ihre Kunden nicht überlebensnotwendig, so dass kleinere Probleme der frühen Releases durch die Nutzer toleriert werden können.

Das etablierte Unternehmen mit der Buchhaltungs-Software möchte ebenfalls Geschwindigkeit bei der Lieferung von wertvollem Produkten an seine Kunden aufnehmen. Ihre Kunden nutzen das Produkt jedoch, um ihre Unternehmensfinanzen zu verwalten, ihren Kunden Rechnungen zu stellen und Lieferanten zu bezahlen. Seine Funktion ist entscheidend für den laufenden Betrieb! Aus diesem Grund werden die Key-User des Kunden umfassend geschult. Obwohl sie ein hochwertiges Produkt verlangen, das beim ersten Mal funktioniert, wollen sie Risiken gering halten und haben in der Vergangenheit umfangreiche Tests mit jedem neuen Release durchgeführt, um das Risiko für ihre Organisation zu minimieren. Der Lieferant hat bei diesen Kunden seinen guten Ruf zu schützen, und so ist auch ihm die Bereitstellung eines schon beim ersten Release hochwertigen und stabilen Produktes wichtig.

Welche Art von Release funktioniert für Sie?

Es ist offensichtlich, dass diese Unternehmen unterschiedliche Herangehensweisen an MVPs benötigen, damit sie in ihren Märkten funktionieren. Das nachstehende Diagramm kann bei der Überlegung helfen, was für Sie und Ihre Kunden „viable“ – also lebensfähig und machbar – ist.
Wir haben es einfach gehalten und dafür 4 Merkmale betrachtet, die Unternehmen für sich bewerten müssen:

  1. Die erforderliche Produktqualität,
  2. der interne Freigabeprozess das Produktes,
  3. der Produktabnahmeprozess des Kunden und
  4. der von Ihnen verfolgte Entwicklungsansatz.

Für jedes Merkmal haben wir Beschreibungen hinzugefügt, in denen Sie ihre Situation vielleicht wiedererkennen.

Wenn die Beschreibungen auf der linken Seite zu Ihrer Situation passen, dann wird ein ‚light-weight‘ MVP wahrscheinlich für Sie funktionieren. Wenn die Beschreibungen auf der rechten Seite eher zu ihnen passen, dann ist ein ‚heavy-weight‘ MVP etwas, das Sie versuchen sollten anzustreben.

Was meinen wir mit „light-weight“ MVPs und „heavy-weight“ MVPs?
Ein leichtgewichtiges – light-weight – MVP ist eines, für das Sie mit wöchentlichen oder monatlichen Releases arbeiten können, und bei dem Sie mit kleinen inkrementellen Funktionen sichtbare Fortschritte machen und wertvolles Feedback einholen können. Es kommt der ursprünglichen Definition des MVPs am nächsten.

Ein schwergewichtiges – heavy-weight – MVP kann mehrere Monate zwischen Releases erfordern und ermöglicht trotzdem einen frühen Markteintritt.

Natürlich ist der Einwurf zulässig, dass ein heavy-weight MVP kein echtes Minimum Viable Product ist! Dem Modell von Eric Ries für schnelle, inkrementelle Veröffentlichungen steht es ziemlich entgegen. Aber manche Märkte erfordern erhebliche Produktinvestitionen für das, was für Sie und Ihre Kunden minimal und rentabel ist.

Wenn ihre Situation durch die linke Seite der Tabelle repräsentiert ist, dann kommen Ihre Produkt wahrscheinlich zu relativ niedrigen Kosten auf den Markt und sind für Ihre Kunden nicht geschäftskritisch – also unabdingbar für den täglichen Betrieb notwendig. Eines meiner (etwas absurden) Online-Lesezeichen ist „Ians Schnürsenkelseite“, die eine Anleitung zu den besten Knoten für verschiedene Arten von Schnürsenkeln bietet. Die Website bietet ziemlich eingeschränkte Funktionalität, erinnert sogar eher an das Web 1.0, wird allerdings regelmäßig aktualisiert und wenn sie mal nicht erreichbar sein sollte, bricht für die Besucher nicht die Welt zusammen.

Wenn Sie auf der rechten Seite stehen, dann wäre die Nichterreichbarkeit ihres Services oder funktionale Ausfälle eine mittlere Katastrophe. So zum Beispiel bei Produkten, die für die Verwaltung oder Steuerung von Geldwerten, Sicherheit oder Gesundheit zuständig sind. Viele unserer Kunden sind Pharmaunternehmen, Banken und Telekommunikationsunternehmen – sollte diesen Unternehmen bei der Verwaltung von Geld oder der Bereitstellung von lebenswichtigen Informationen für die Krankenhaus-IT ein Fehler unterlaufen, wären die direkten Kosten und der Reputationsschaden inakzeptabel. Kunden, die diese Arten von Produkten verwenden, sind naturgemäß eher risikoscheu.

Ist es also in Ordnung, bei einzelnen Produkten eine langsamere Release-Frequenz zu planen?

Unabhängig davon, was der Begriff „MVP“ derzeit für Sie und Ihre Kunden bedeutet, steht der Druck, schneller noch größeren Nutzwert zu liefern, im Vordergrund und dieser Druck wird nur noch zunehmen. Es ist ein bisschen wie im Zitat von Jeff Bezos (Amazon-CEO), das ich mit den Worten „Ich weiß nicht, welche Produkte die Kunden in 10 Jahren wollen werden. Was ich weiß, ist, dass sie mehr Auswahl, und günstiger und schneller einkaufen wollen. “ übersetzen würde.

Während wir (und wahrscheinlich auch Sie) nicht über die Ressourcen eines Amazons verfügen, müssen Sie die Wahrheit ins Auge blicken, dass die Verbesserung Ihrer Liefergeschwindigkeit und der Geschwindigkeit in der Sie Markterkenntnisse in Produkte und Services umsetzen immer wichtiger werden und vielleicht in Zukunft eines der wichtigsten Unterscheidungsmerkmale sein werden.

Einige der Attribute in der Tabelle können durch interne Investitionen in Systeme, Werkzeuge oder Prozesse oder durch die Zusammenarbeit mit Kunden bei der Verschiebung ihrer Position geändert werden.

Marktkenntnisse und die partnerschaftliche Zusammenarbeit mit Ihren Kunden sind entscheidend – die Kunden und Sie müssen auf dem gleichen Pfad unterwegs sein. Das bedeutet schnelles Prototyping zur Validierung der Funktionalität. Aber es ist mehr als das, es bedeutet auch, mit ihnen darüber zu sprechen, wie es geliefert wird, und mit ihnen ein Release-Modell abzustimmen, das für Sie und für Ihre (potenziellen) Kunden funktioniert.
Was Sie tun können, ist über die richtigen Werkzeuge, Prozesse und Ansätze nachzudenken, die Ihnen dabei helfen, im Diagramm auf die linke Seite zu kommen.
Stehen Sie vor dieser Herausforderung und wenn ja, was tun Sie dagegen?