MVP, Prototyp, Proof of Concept: was ist der Unterschied?

Drei Begriffe, drei verschiedene Fragen

Proof of Concept, Prototyp und MVP klingen nach demselben: irgendeine erste, unfertige Version von etwas Neuem. Im Sprachgebrauch werden sie auch so behandelt, austauschbar und unscharf. Daran hängt das ganze Problem. Die drei stehen nämlich nicht für drei Reifegrade auf einer Leiter, sondern für drei völlig verschiedene Fragen, die du in einem Vorhaben beantworten musst. Ein Proof of Concept fragt: geht das technisch überhaupt? Ein Prototyp fragt: stimmt die Form, verstehen Menschen die Bedienung? Ein MVP fragt: will jemand das benutzen und dafür bezahlen?

Hältst du diese drei Fragen sauber auseinander, weisst du in jeder Phase, was du gerade baust und was es dir beantwortet. Vermischst du sie, baust du oft das Aufwendigste von allem und stehst am Ende trotzdem ohne Antwort auf die Frage da, die dich eigentlich interessiert hat. Gehen wir die drei der Reihe nach durch.

Der Proof of Concept testet die technische Machbarkeit

Ein Proof of Concept (PoC) beantwortet eine einzige Ja-Nein-Frage: lässt sich eine bestimmte technische Idee überhaupt umsetzen? Er entsteht, wenn ein Vorhaben an einer Stelle hängt, bei der niemand im Team sicher sagen kann, ob die Technik mitspielt. Lassen sich diese zwei Altsysteme schnell genug synchronisieren? Liefert das Sprachmodell auf euren Dokumenten brauchbare Antworten? Reicht die Texterkennung für eure Belege? Das sind PoC-Fragen.

Wichtiger als das, was ein PoC kann, ist das, was er absichtlich weglässt. Keine vernünftige Oberfläche, keine Fehlerbehandlung, keine Anmeldung, oft nicht einmal eine Datenbank. Ein PoC darf ein Skript sein, das auf deinem Rechner läuft und Zeilen in die Konsole schreibt. Er muss nicht schön sein, nicht stabil, nicht wartbar. Er muss eine einzige Sache zeigen: dass der riskante technische Kern hält. Ist die Frage mit Ja oder Nein beantwortet, hat der PoC seinen Zweck erfüllt und darf weg.

Hier passiert die erste teure Verwechslung. PoC-Code ist Wegwerf-Code. Wer einen laufenden PoC sieht und sagt funktioniert doch, das bauen wir jetzt fertig, schleppt eine Codebasis weiter, die nie für den Betrieb gedacht war. Keine Tests, keine Sicherheit, keine Struktur, die mehr als einen Entwickler verträgt. Das rächt sich Monat für Monat. Ein PoC beweist, dass etwas geht. Wie es dann gebaut wird, dafür ist er keine Vorlage.

Der Prototyp testet die Form und die Bedienung

Ein Prototyp beantwortet eine andere Frage: stimmt die Form? Verstehen Menschen, wie das Produkt bedient wird, finden sie sich zurecht, fühlt sich der Ablauf richtig an? Beim Prototyp geht es um Gestaltung und Nutzerführung, nicht um Technik. Deshalb ist er oft gar nicht programmiert, sondern ein klickbares Modell aus einem Design-Werkzeug, das aussieht und sich anfühlt wie das fertige Produkt, dahinter aber leer ist.

Der Sinn: etwas in die Hände von Menschen geben, bevor es teuer wird. Setz fünf künftige Nutzer vor den Klick-Dummy und schau zu. Wo zögern sie? Welchen Knopf finden sie nicht? Wo erwarten sie etwas anderes, als da steht? Im Prototyp korrigierst du das fast gratis, indem du ein paar Elemente verschiebst und eine Schaltfläche umbenennst. Im fertig programmierten Produkt kostet dieselbe Korrektur ein Vielfaches, weil Code, Datenmodell und Tests daran hängen.

Über die Technik dahinter sagt ein Prototyp nichts, und über den Markt auch nicht. Er kann wunderschön und vollkommen verständlich sein und trotzdem ein Produkt zeigen, das technisch unmöglich oder für niemanden nützlich ist. Form geklärt heisst nicht Machbarkeit geklärt, und schon gar nicht Nachfrage geklärt. Darum ersetzt das eine Werkzeug das andere nie.

Das MVP testet den Markt- und Nutzerwert

Ein Minimum Viable Product (MVP) ist das einzige der drei, das echte Nutzer im echten Alltag bedient. Es beantwortet die teuerste Frage von allen: Will überhaupt jemand das benutzen, und ist es ihm genug wert, dafür zu bezahlen oder es regelmässig einzusetzen? Ein MVP ist ein echtes, funktionierendes Produkt, nur radikal auf den einen Kern reduziert, der den entscheidenden Nutzen stiftet. Was nicht zur Beantwortung dieser Frage beiträgt, kommt später.

Das Missverständnis steckt im Wort Minimum. Minimum heisst nicht halbfertig oder schlampig. Für den einen Anwendungsfall, den es abdeckt, muss ein MVP wirklich funktionieren: verlässlich, sicher, gut genug bedienbar, dass ein Mensch es freiwillig benutzt. Reduziert wird der Funktionsumfang, nicht die Qualität im Kern. Ein MVP, das beim ersten echten Login abstürzt, beantwortet keine Marktfrage, es erzeugt nur Frust und falsche Schlüsse. Wie eng du den Kern sinnvoll schneidest und welche Wege es dorthin gibt, dazu mehr in die besten Wege, ein MVP zu bauen.

Weil ein MVP echte Nutzer trifft, braucht es das, was PoC und Prototyp weglassen dürfen: einen Betrieb. Es muss laufen, überwacht werden, Fehler verkraften, aktualisiert werden. Daher ist die Versuchung gross, ein MVP mit einem PoC zu verwechseln, beide funktionieren ja irgendwie. Aber ein PoC funktioniert auf einem Entwicklerrechner unter Idealbedingungen. Ein MVP funktioniert in der Hand eines Fremden um drei Uhr nachmittags mit echten Daten und schlechtem WLAN. Das ist ein gewaltiger Unterschied im Aufwand, und genau den bezahlst du, wenn du beides gleichsetzt.

Wann du was brauchst

Die drei Werkzeuge sind keine Pflichtstationen, die du der Reihe nach abarbeitest. Du nimmst, was deine grösste offene Frage gerade verlangt. Die Regel ist simpel: kümmere dich zuerst um das grösste Risiko.

Ist dein grösstes Risiko technisch, weil dein Vorhaben mit einer Technik steht und fällt, deren Machbarkeit unklar ist, beginnst du mit einem PoC. Du willst nicht ein halbes Jahr ein Produkt bauen, um am Ende festzustellen, dass der technische Kern nie tragfähig war.

Ist dein grösstes Risiko die Bedienung, weil der Ablauf komplex ist und du nicht sicher bist, ob Menschen ihn verstehen, beginnst du mit einem Prototyp. Du klärst die Form, bevor du sie in teuren Code giesst.

Ist dein grösstes Risiko der Markt, weil die Technik bekannt und die Bedienung naheliegend ist, du aber nicht weisst, ob die Sache jemand will, baust du direkt ein MVP. Ein PoC oder Prototyp würde hier nur Zeit kosten und die eigentliche Frage, die Nachfrage, nicht einmal berühren.

Oft kombinierst du. Ein riskantes Vorhaben startet mit einem kleinen PoC für den technischen Kern, klärt dann mit einem Prototyp die Bedienung und geht schliesslich als MVP an echte Nutzer. Entscheidend ist nur, dass du in jedem Schritt weisst, welche Frage du gerade beantwortest, statt aus Versehen ein Werkzeug auf eine Frage anzusetzen, für die es nie gedacht war. Wenn du grundsätzlich abwägst, ob sich ein eigenes Produkt für dich rechnet, hilft lohnt sich eigenes SaaS fuer KMU bei der Einordnung.

Was die Verwechslung kostet

Die teuerste Verwechslung in der Praxis: einen PoC zum Produkt erklären. Der technische Beweis steht, alle sind euphorisch, und statt sauber neu zu bauen, wird der Wegwerf-Code zum Fundament. Eine Weile geht das gut. Dann häufen sich die Fehler, jede neue Funktion dauert länger als die letzte, niemand traut sich mehr, etwas anzufassen. Die fehlende Sorgfalt bezahlst du nicht einmal, sondern in jedem Monat danach. Dieses Muster sehen wir in warum SaaS-Projekte scheitern immer wieder.

Die zweite Verwechslung läuft andersherum: aus einem MVP einen vergoldeten Prototyp machen. Monatelang wird an Funktionen, Sonderfällen und Politur gefeilt, bevor je ein echter Nutzer das Produkt gesehen hat. Am Tag des Starts zeigt sich dann, dass die Grundannahme falsch war und der Markt etwas anderes will. Die ganze Politur galt einem Produkt, das so niemand braucht. Als echtes MVP behandelt hätte dieselbe Idee die Marktfrage in einem Bruchteil der Zeit beantwortet, statt als Prestigeobjekt zu reifen.

Der Schaden hat in beiden Fällen dieselbe Form: du bekommst am Ende eine saubere Antwort auf eine Frage, die du nie stellen wolltest. Der PoC-als-Produkt beweist wieder und wieder, dass die Technik geht, während die Marktfrage offenbleibt. Der vergoldete Prototyp klärt die Form bis ins letzte Detail, während die Nachfrage ungeprüft bleibt. Verschwendung entsteht nicht durch zu wenig Arbeit, sondern durch Arbeit an der falschen Frage.

Warum der Blick auf den Betrieb die Begriffe scharf macht

Wirklich scharf wird die Grenze zwischen den drei Begriffen erst, wenn du nicht nur ans Bauen denkst, sondern ans Betreiben. PoC und Prototyp dürfen sterben, sobald ihre Frage beantwortet ist. Ein MVP ist der erste Tag eines Produkts, das ab dann läuft, gepflegt und weiterentwickelt wird. Wer das nicht im Kopf hat, schneidet das MVP entweder zu dünn, sodass es im echten Betrieb sofort umfällt, oder zu dick, sodass es nie zum Markttest kommt.

Wir bei Wertstifter halten diese Linie scharf, weil wir unsere eigenen Produkte nicht nur bauen, sondern selbst betreiben. Wortfreunde und Reazon haben beide als bewusst kleiner Kern begonnen und stehen seither im täglichen Einsatz. Aus diesem Doppel von Bauen und Betreiben wissen wir, wo ein zu dünn geschnittenes MVP im Alltag bricht und wo ein vergoldeter Prototyp Geld verbrennt, das nie zurückkommt. Reine Agenturen, die nach dem Start aussteigen, bekommen diesen Unterschied selten zu spüren. Willst du diese Linie für dein eigenes Vorhaben ziehen, ist das genau die Arbeit, die in unsere SaaS-Produktentwicklung gehört.

Merk dir die drei Fragen, dann verwechselst du die Begriffe nie wieder. Der Proof of Concept klärt, ob es technisch geht. Der Prototyp klärt, ob die Form stimmt. Das MVP klärt, ob es jemand will. Drei Fragen, drei Werkzeuge, und die Disziplin, in jedem Moment zu wissen, welche davon gerade dran ist.