MarktdenkerMinimum Viable Product: eine sinnvolle Markterprobung planen
Ein Minimum Viable Product, kurz MVP, soll dir helfen, eine unsichere Annahme über ein Produkt und seine Nutzer zu prüfen. Dafür entwickelst du eine möglichst kleine Erprobung, die zur offenen Frage passt. Entscheidend ist, was du daraus lernen kannst. Eric Ries beschreibt das MVP über validiertes Kundenlernen mit möglichst wenig Aufwand; eine kleine Funktionsliste allein erfüllt dieses Ziel noch nicht. Quelle: Ries, Originalbeitrag von 2009
Was ein MVP prüfen soll
Stell dir vor, dein Team plant eine neue Lösung und diskutiert bereits Automatisierung, Integrationen und Zusatzfunktionen. Noch offen ist, ob die vorgesehene Zielgruppe damit überhaupt eine wichtige Aufgabe besser erledigen kann. Genau diese Ungewissheit gibt dem ersten Test seinen Zweck.
„Minimum“ richtet sich dabei nach der Frage. Ein Test darf schlank sein, braucht aber genug Substanz, um einen verwertbaren Befund zu liefern. Ries betont ausdrücklich, dass die Wahl des passenden MVP Kontexturteil verlangt und Lernen selbst Arbeit verursacht. Schnell etwas zu veröffentlichen ersetzt diese Arbeit nicht. Quelle: Ries, Erläuterungen zur MVP-Definition
Auch der Begriff wird unterschiedlich verwendet. Manche Teams meinen mit MVP eine erste nutzbare Produktversion. Andere verwenden ihn für ein Lernartefakt, etwa ein Modell, das nur eine bestimmte Annahme prüft. Roman Pichler beschreibt diesen weiteren Gebrauch und dokumentiert zugleich die engere Bedeutung eines kleinen veröffentlichbaren Angebots. Kläre deshalb im Team, welche Frage und welche Leistung ihr mit dem Wort verbindet. Quelle: Pichler, MVP/MMP und Ergänzung von 2017
Für deinen Plan zählt die überprüfbare Verbindung: eine konkrete Annahme, eine passende Erprobung und ein Befund, aus dem eine nächste Entscheidung folgt.
PoC, Prototyp oder MVP: Welche Frage ist offen?
Die Namen allein helfen bei der Auswahl wenig. Beginne mit der Eigenschaft, über die du etwas erfahren willst. Die folgende Tabelle ist eine redaktionelle Auswahlhilfe; die Begriffe können sich in der Praxis überschneiden.
| Offene Frage | Passende Erprobung | Was danach weiter offenbleibt |
|---|---|---|
| Ist die kritische technische Funktion machbar? | Ein Proof of Concept, der genau diese Funktion untersucht | Ob Zielnutzer die Lösung brauchen oder bezahlen würden |
| Verstehen Nutzer den Ablauf und können sie eine Aufgabe darin bearbeiten? | Ein Prototyp mit den dafür erforderlichen Interaktionen | Ob das spätere Produkt zuverlässig im Alltag betrieben werden kann |
| Hilft das kleine Angebot einer bestimmten Nutzergruppe bei ihrer Aufgabe? | Eine begrenzte MVP-Erprobung mit passenden Nutzern und beobachtbarem Verhalten | Ob andere Gruppen, wirtschaftlicher Betrieb und größere Nutzung ebenfalls funktionieren |
NASA verortet Proof-of-Concept-Modelle in einer Skala technischer Reife. Das ist ein technischer Nachweisjob, kein unmittelbarer Nachweis von Marktnachfrage. Der britische Government Digital Service beschreibt Prototypen wiederum als Mittel, einzelne Annahmen zu testen, und unterscheidet sie ausdrücklich von produktionsreifer Umsetzung. Beide Quellen haben ihren eigenen Anwendungskontext. Quellen: NASA zur technischen Reife, GDS zur Alpha-Erprobung
Ein klickbarer Prototyp kann also zugleich Teil einer MVP-Erprobung sein, wenn er die konkrete Lernfrage beantwortet. Eine Landingpage mit Warteliste kann ein erstes Registrierungssignal liefern. Sie zeigt damit noch nicht, ob das eigentliche Produkt seine Aufgabe erfüllt. Halte für jedes Artefakt fest, welche Eigenschaft du tatsächlich beobachtest.
Die Erprobung von der Annahme her planen
Die folgende Arbeitshilfe übersetzt das Lernziel in einen Testplan. Sie ist eine eigene redaktionelle Zusammenstellung. Die Lean-Startup-Methodik verbindet Problemklärung, Bauen, Messen und Lernen; unsere Felder machen diese Verbindung für einen begrenzten Versuch überprüfbar. Quelle: Lean Startup, Methodik und Prinzipien
Nutzerproblem und kritische Annahme eingrenzen
Beschreibe zuerst eine bestimmte Nutzergruppe und eine konkrete Situation. „Wir brauchen ein Dashboard“ beschreibt bereits eine Lösung. „Projektleitungen verlieren vor der Wochenbesprechung den Überblick über offene Freigaben“ benennt ein Problem, das du untersuchen kannst.
Notiere auch, wie die Gruppe heute damit umgeht. Bestehende Listen, E-Mails oder persönliche Rückfragen gehören zum Vergleich. Eine neue Oberfläche hat nur dann einen sinnvollen Testzweck, wenn du erklären kannst, welchen Unterschied du beobachten möchtest.
Formuliere anschließend die unsichere Annahme als überprüfbare Erwartung. Beispielsweise: Eine Übersicht mit offenen Entscheidungen wird von Projektleitungen bei der Vorbereitung ihres nächsten Meetings tatsächlich verwendet. Das ist enger als die Behauptung, eine ganze Projektplattform werde am Markt gebraucht.
Wähle Personen, bei denen die beschriebene Situation vorkommt. Steve Blank richtet den kleinen ersten Funktionsumfang an passende frühe Kunden und einen eng begrenzten Problemnutzen. Daraus folgt für die Testplanung: Eine zufällig erreichbare Gruppe ist nicht automatisch die Gruppe, über die du eine Aussage treffen willst. Quelle: Blank, The Minimum Feature Set
Kernaufgabe und beobachtbares Signal festlegen
Schreibe auf, welche Aufgabe die Testpersonen ausführen sollen. Beschränke den Umfang anschließend auf das, was diese Aufgabe und die Beobachtung ermöglichen. Zusatzfunktionen, die dafür nichts beitragen, können auf einer separaten Liste bleiben.
Trenne verschiedene Signale. Lob für eine Idee, das Finden einer Information und die erneute Nutzung im Arbeitsalltag beantworten unterschiedliche Fragen. Frage nicht nur, ob jemand das Angebot gut findet. Beobachte, ob die vorgesehene Aufgabe gelingt, welche Hilfe nötig ist und ob die Person das Angebot für die nächste vergleichbare Situation erneut verwenden möchte.
Für eine nutzbare Erprobung müssen die benötigten Informationen und Abläufe verlässlich genug sein. Pichler stellt ausdrücklich klar, dass ein kleiner MVP-Umfang keine unsaubere Umsetzung verlangt. Lege deshalb den Testumfang und seine Grenzen offen: Welche Aufgabe funktioniert, welche Unterstützung ist vorgesehen und welche Leistung gehört erst zu einer späteren Version? Quelle: Pichler, Abschnitt „The Minimum Viable Product“
Entscheidung und Auswertung vorher vereinbaren
Lege vor dem Start fest, was ihr nach unterschiedlichen Beobachtungen tun wollt. Sonst lässt sich ein beliebiger Befund nachträglich als Erfolg erzählen.
Für die Planung reichen zunächst klare Bedingungen: Bei eigenständiger, wiederholter Nutzung wird die nächste offene Annahme geprüft. Bei Verständnisschwierigkeiten wird der Ablauf überarbeitet. Wenn das angenommene Problem für die angesprochenen Personen nicht relevant ist, werden Problem oder Zielgruppe neu untersucht.
Bestimme außerdem, was du dokumentierst: Ausgangssituation, gestellte Aufgabe, angebotene Hilfe, beobachtete Handlung und Rückmeldung. Trenne Beobachtung und Interpretation. „Die Person brauchte einen Hinweis, um die Freigabe zu finden“ ist genauer als „Die Oberfläche funktioniert nicht“.
Ein kleines Team kann dafür ein gemeinsames Testblatt verwenden. Die Kriterien sollen eine Entscheidung ermöglichen; ihre Anzahl oder ein bestimmter Zeitraum macht den Versuch noch nicht aussagekräftig.
Ein begrenztes Beispiel: Freigaben im Agenturprojekt
Das folgende Beispiel ist ein hypothetischer Testplan. Es beschreibt keine tatsächlich durchgeführte Erprobung und enthält keine Kundenresultate.
Eine Agentur überlegt, eine neue Freigabenlösung anzubieten. Für den ersten Versuch begrenzt sie die Aufgabe auf eine Übersicht der offenen Entscheidungen in einem Projekt. Statt sofort E-Mail-Import, Rechteverwaltung und automatische Erinnerungen zu bauen, könnte sie diese Übersicht zunächst manuell zusammenstellen.
Die Annahme lautet: Eine Projektleitung verwendet die Übersicht zur Vorbereitung der Besprechung und möchte sie für die nächste vergleichbare Situation erneut nutzen.
Zum Test gehört eine konkrete Aufgabe: Die Projektleitung soll erkennen, welche Entscheidung offen ist, wer sie treffen muss und welcher nächste Schritt ansteht. Die Agentur würde festhalten, ob dafür zusätzliche Erläuterungen nötig sind und welche Angaben fehlen. Eine anschließende Bitte um eine weitere Übersicht wäre ein anderes Signal als ein freundliches Urteil über das Layout.
Vor dem Start würde die Agentur festlegen: Bei verständlicher, erneut gewünschter Nutzung untersucht sie als Nächstes den Aufwand für die laufende Bereitstellung. Bei fehlenden oder missverständlichen Angaben überarbeitet sie die Übersicht. Wenn die angesprochenen Personen dieses Problem anders lösen und die Übersicht nicht benötigen, überprüft sie ihre Problemannahme.
Damit bleibt der Umfang nachvollziehbar. Der Versuch würde weder die automatische Datenverarbeitung noch die Zahlungsbereitschaft prüfen. Die manuelle Erfüllung könnte Informationen über die Teilaufgabe liefern, aber noch keine Aussage über den Aufwand eines skalierbaren Softwarebetriebs.
Nach dem Test: Was ist belegt, was bleibt offen?
Schreibe die Schlussfolgerung so eng wie den Befund. Ein Wartelisteneintrag ist zunächst ein beobachteter Eintrag. Eine erledigte Aufgabe zeigt etwas über die Nutzung unter den Testbedingungen. Keines dieser Signale bestätigt für sich ein vollständiges Geschäftsmodell.
Frage bei einem enttäuschenden Befund ebenfalls nach der Grenze. War das Problem für die Testgruppe relevant? Hat sie die Aufgabe verstanden? Fehlte eine Information oder war die Durchführung gestört? Das sind mögliche Erklärungen, die du prüfen kannst, keine nachträglich bewiesenen Ursachen.
Die nächste Entscheidung kann sein, den Umfang weiterzuentwickeln, die Annahme zu verändern oder den Versuch zu beenden. Wenn die Beobachtung mehrdeutig bleibt, formuliere eine kleinere Folgefrage. Die Lernschleife verlangt eine begründete nächste Richtung; sie ist kein Automatismus zum Markterfolg.
Auch Product-Market-Fit bleibt eine weitergehende Frage. Eine kleine Erprobung kann einen Baustein liefern, bestätigt aber noch nicht, dass Angebot, Nachfrage und wirtschaftliche Bereitstellung dauerhaft zusammenpassen. Die Lean-Startup-Methodik richtet die Experimente auf das Lernen über ein tragfähiges Geschäft aus. Ein einzelnes positives Signal deckt diesen gesamten Job nicht ab. Quelle: Lean Startup, „Work Smarter not Harder“ und „Validated Learning“
Für anschließende Fragen zu Angebot und unternehmerischer Planung findest du weitere Methoden im Business-Hub. Die Übersicht zu Business und Marketing erschließt weitere Leitfäden und Einordnungen.
FAQ
Kann ich einen MVP-Test für ein bestehendes Produkt planen?
Du kannst die Arbeitshilfe auf eine neue Funktion oder eine veränderte Nutzeraufgabe anwenden. Begrenze die Annahme auf diese Änderung und benenne, was das bestehende Produkt bereits übernimmt. Auch Ries diskutiert eine einzelne Funktion als Gegenstand einer frühen Erprobung. Übertrage das Ergebnis anschließend nur auf die tatsächlich getestete Frage. Quelle: Ries, Originalbeitrag
Was bedeutet dann Minimum Marketable Product?
Pichler beschreibt damit ein kleines Angebot, das für die ersten Nutzer marktfähig ist. Er weist zugleich darauf hin, dass andere den Begriff MVP in diesem Sinn gebrauchen. Vereinbare deshalb im Team, ob ihr über ein Lernartefakt oder über eine veröffentlichbare Version sprecht. Eine allgemein verbindliche Trennung lässt sich aus diesem unterschiedlichen Sprachgebrauch nicht ableiten. Quelle: Pichler, MMP und Postscript von 2017