MVP, Prototyp oder Proof of Concept: Was Sie zuerst bauen sollten

Jeder testet ein anderes Risiko. Diese Tabelle stellt sie nebeneinander.

Ein Proof of Concept, kurz PoC, prüft, ob etwas technisch möglich ist. Meist ist es ein kleines Stück Code, das ein schwieriges Problem löst und alles andere ignoriert: kein Design, keine Accounts, kein Feinschliff.

Ein Beispiel: Ein Start-up, das Gesamtbeträge aus Fotos handschriftlicher Quittungen auslesen will, sollte zuerst testen, ob ein KI-Modell sie genau genug lesen kann. Wenn nicht, rettet kein Design der Welt das Produkt.

Die meisten Produkte brauchen keinen PoC. Besteht Ihre Idee aus bewährten Bausteinen wie Accounts, Zahlungen, Formularen und Dashboards, ist das technische Risiko gering, und ein PoC verzögert nur die eigentliche Frage.

Der Code eines PoC wird in der Regel weggeworfen. Er wurde geschrieben, um eine Frage schnell zu beantworten, nicht um ein Produkt zu tragen.

Ein Prototyp zeigt, wie das Produkt funktionieren wird, bevor jemand Produktionscode schreibt. Das kann eine Reihe von Skizzen sein oder eine klickbare, realistische Oberfläche, die sich fast wie das echte Produkt verhält.

Der Leitfaden der Nielsen Norman Group zu Prototypen mit niedriger und hoher Detailtreue erklärt die Abwägung gut. Einfache Skizzen sind schneller und laden zu ehrlicher Kritik ein; detailreiche Prototypen zeigen realistisches Verhalten, was zählt, wenn Sie bestimmte Abläufe testen.

Ein Prototyp ist außerdem das beste Werkzeug, um alle Beteiligten auf eine Linie zu bringen. AutoIntel, ein B2B-Tool für den deutschen Gebrauchtwagenmarkt, begann als interaktiver Prototyp mit Beispielinseraten. Der Kunde ging ihn mit seinem Team durch, und man einigte sich darauf, welche Felder und Filter zählen, bevor die Datenpipeline geplant wurde.

Ein MVP, ein Minimum Viable Product, ist die kleinste Version Ihres Produkts, die echte Nutzer wirklich verwenden können. Es hat funktionierende Accounts, echte Daten und, wo es darauf ankommt, echte Zahlungen.

Das Ziel ist Lernen, nicht der Launch um seiner selbst willen. In den Worten von Lean Startup bauen Sie ein MVP, um „den Lernprozess so schnell wie möglich zu beginnen“.

Ein MVP kann messen, was ein Prototyp nicht messen kann: ob Menschen wiederkommen und ob sie zahlen. Bei CarPixly, einem KI-Fotostudio für Autoinserate, kann sich jeder anmelden und das Studio kostenlos ausprobieren; bezahlt wird im Moment des Nutzens, beim Rendern. Ein solches Modell zeigt klar, wie viele Besucher zu zahlenden Nutzern werden.

Die meisten MVPs entstehen je nach Komplexität in 6 bis 14 Wochen. Unsere Leitfäden dazu, wie lange ein MVP dauert und was ein SaaS-MVP kostet, nennen die Spannen je Stufe.

Beginnen Sie mit der riskantesten Unbekannten. Stellen Sie diese Fragen der Reihe nach:

• Besteht eine echte Chance, dass es sich nicht bauen lässt? Zum Beispiel, weil es von einem KI-Modell, einem Hardwaresensor oder einer API abhängt, die Sie noch nicht getestet haben. Bauen Sie einen Proof of Concept.
• Ist unklar, ob Menschen die Lösung verstehen oder wollen? Bauen Sie einen Prototyp und testen Sie ihn mit Nutzern.
• Verstehen und wollen Menschen es, und offen ist nur, ob sie es nutzen oder dafür zahlen? Bauen Sie ein MVP.

Die meisten Start-ups landen bei der zweiten Frage. Die Technologie ist meist bewährt; unbewiesen ist, ob das Produkt für die Menschen, für die es gedacht ist, Sinn ergibt.

Nicht sicher, welches Risiko in Ihrer Idee das größte ist? Schicken Sie uns ein kurzes Briefing, und wir sagen Ihnen, mit welchem Schritt wir beginnen würden und warum.

Ein Prototyp nützt nur, wenn echte Menschen ihn ausprobieren. Die gute Nachricht: Sie brauchen weniger Testpersonen, als die meisten Gründer denken.

Jakob Nielsens Forschung hat gezeigt, dass Tests mit 5 Nutzern die meisten Usability-Probleme eines Designs aufdecken. Er rät zu mehreren kleinen Runden statt einer großen Studie.

Eine einfache Testrunde sieht so aus:

• Geben Sie jeder Person eine realistische Aufgabe, etwa „buchen Sie einen Termin für nächsten Dienstag“.
• Beobachten Sie, was sie tut, ohne zu helfen oder zu erklären.
• Notieren Sie, wo sie zögert, etwas falsch versteht oder aufgibt.
• Beheben Sie die schlimmsten Probleme und testen Sie die nächste Version mit neuen Personen.

Fragen Sie auch nach dem heutigen Verhalten: wie die Menschen das Problem jetzt lösen und was es sie kostet. Das verrät mehr über die Nachfrage als die Frage, ob sie Ihr Produkt „nutzen würden“.

Ein Prototyp aus Skizzen ist ein Lernwerkzeug und wird später neu gezeichnet. Ein detailreicher Prototyp aus echten Komponenten ist etwas anderes: Seine Abläufe, Screens und sein Designsystem werden zum Ausgangspunkt des MVP.

Deshalb gestalten wir mit wiederverwendbaren Komponenten, vom ersten Screen an. Ist der Prototyp getestet und freigegeben, beginnt die Entwicklung mit denselben Komponenten, statt ein Bild neu zu interpretieren.

Beim Proof of Concept ist es umgekehrt. Sein Code beantwortet eine Frage und wird im MVP meist sauber neu geschrieben, weil er nie dafür gedacht war, echte Nutzer zu tragen.

Jeder Schritt sollte mit einer klaren Antwort enden, nicht mit einem Gefühl. Halten Sie vor dem Start schriftlich fest, was „Erfolg“ bedeutet, damit sich das Ergebnis später nicht in das umdeuten lässt, was Sie sich erhofft haben.

• Ein Proof of Concept ist erfolgreich, wenn der schwierige Teil mit realistischen Daten funktioniert, in der Genauigkeit oder Geschwindigkeit, die das Produkt braucht. „Es klappt mit drei Testdateien“ reicht nicht, wenn Nutzer Tausende schicken werden.
• Ein Prototyp ist erfolgreich, wenn die meisten Testnutzer die Hauptaufgabe ohne Hilfe erledigen und das Problem, das er löst, in eigenen Worten beschreiben.
• Ein MVP ist erfolgreich, wenn echte Nutzer ohne Erinnerung wiederkommen oder zahlen, und zwar so häufig, dass sich die nächste Investition lohnt.

Scheitert ein Schritt, ist auch das nützlich. Ein gescheiterter Proof of Concept erspart Ihnen eine teure Entwicklung. Ein verwirrender Prototyp sagt Ihnen, dass Sie den Ablauf ändern sollten, solange Änderungen noch günstig sind.

Setzen Sie außerdem für jeden Schritt ein Zeitlimit. Ein Prototyp, an dem nach Monaten noch gefeilt wird, ist kein Test mehr, sondern ein Produkt, das noch niemand nutzen kann.

Manchmal ja. Wenn Sie die Idee schon getestet haben, zum Beispiel mit einer manuellen Version des Dienstes, wissen Sie vielleicht genug, um direkt ein MVP zu bauen.

Ein Beispiel: Eine Gründerin, die seit Monaten Kunden von Hand mit Nachhilfelehrern zusammenbringt, mit Tabellen und Nachrichten, kennt die Abläufe und die Fragen der Menschen bereits. Ein Prototyp würde vor allem bestätigen, was sie schon weiß.

Das Überspringen ist sinnvoll, wenn drei Dinge zutreffen: Die Technologie ist bewährt, Sie haben echte Menschen durch den Prozess gehen sehen, und Sie wissen, welchen Teil des Prozesses die Software zuerst übernehmen soll. Fehlt einer dieser Punkte, ist ein Prototyp immer noch der günstigere Weg, es herauszufinden.

Dieselben Fehler tauchen immer wieder auf:

• Einen Prototyp MVP nennen. Klicks in einem Prototyp zeigen Verständnis, nicht Nutzung oder Zahlungsbereitschaft. Verwechseln Sie das eine nicht mit dem anderen.
• Einen Proof of Concept zum Produkt aufpolieren. Code, der eine einzige Frage beantworten sollte, wird zur wackligen Basis für alles, was darauf aufbaut.
• Den Prototyp überspringen. Wer ein MVP baut, bevor die Abläufe getestet sind, bezahlt Entwickler dafür, Designprobleme zu entdecken.
• Zu viel ins MVP packen. Jede zusätzliche Funktion verschiebt den Moment, in dem Sie erfahren, ob der Kern funktioniert.
• Mit Freunden testen. Wer Sie mag, lobt die Idee. Testen Sie mit Menschen, die das Problem haben und keinen Grund, nett zu sein.

Bereit, Ihren ersten Schritt zu wählen? Erzählen Sie uns von Ihrer Idee, und wir helfen Ihnen bei der Entscheidung zwischen Proof of Concept, Prototyp und MVP.