Gründer fragen uns oft nach einem MVP, obwohl sie zuerst einen Proof of Concept oder einen Prototyp brauchen. Die drei beantworten unterschiedliche Fragen, und wer das Falsche baut, verschwendet den teuersten Teil eines Projekts: Zeit. Dieser Leitfaden erklärt, was jedes davon prüft, wer es sieht, was hineingehört und wie Sie entscheiden, womit Sie anfangen.
Die kurze Antwort
- Proof of Concept (PoC): beantwortet die Frage „Lässt sich das bauen?“. Er prüft ein einzelnes technisches Risiko, meist intern, und wird danach verworfen.
- Prototyp: beantwortet die Frage „Verstehen die Leute das, und wollen sie es?“. Er zeigt, wie das Produkt funktioniert, oft ohne echten Code dahinter, und wird in Nutzertests und gegenüber Investoren eingesetzt.
- MVP (Minimum Viable Product): beantwortet die Frage „Nutzen die Leute es, und zahlen sie dafür?“. Es ist eine echte, funktionierende erste Version, die echte Kunden verwenden.
Die meisten Produkte brauchen vor dem Launch höchstens zwei davon. Viele brauchen nur ein MVP.
Im direkten Vergleich
| Proof of Concept | Prototyp | MVP | |
|---|---|---|---|
| Welche Frage er beantwortet | Ist es technisch machbar? | Verstehen Nutzer es, und wollen sie es? | Nutzen die Leute es, und zahlen sie? |
| Wer ihn sieht | Das Team, manchmal ein Investor | Testnutzer, Stakeholder, Investoren | Echte Kunden |
| Was es ist | Ein Skript, ein Spike oder eine kleine interne Demo | Klickbare Screens, von Skizzen bis zu High-Fidelity-Designs | Ein funktionierendes Produkt mit wenigen Funktionen |
| Echte Daten und Konten | Manchmal, für einen eng begrenzten Fall | Nein, oder Beispieldaten | Ja |
| Codequalität | Wegwerfcode | Meist kein Produktionscode | Produktionscode, der weiterwächst |
| Wie es weitergeht | Wird verworfen, die Erkenntnis bleibt | Wird zur Designvorlage für die Entwicklung | Wird zu Version 1 des Produkts |
| Typisches Ergebnis | Ein Ja oder Nein zu einem Risiko | Testergebnisse und ein Design, auf das sich das Team einigt | Nutzungsdaten, Feedback und erster Umsatz |
Proof of Concept: zuerst den riskanten Teil prüfen
Ein PoC (auf Deutsch etwa „Machbarkeitsnachweis“) lohnt sich, wenn ein Teil der Idee möglicherweise gar nicht funktioniert. Beispiele:
- Eine KI-Funktion soll die richtigen Felder aus unsauberen Lieferantenrechnungen auslesen. Bevor Sie irgendetwas anderes tun, schicken Sie echte Rechnungen durch ein Modell und messen, wie oft es richtig liegt.
- Ein Produkt hängt von einem ERP-System oder einer Drittanbieter-API ab, die die benötigten Daten vielleicht nicht bereitstellt. Weisen Sie nach, dass Sie die nötigen Datensätze lesen und schreiben können.
- Eine Echtzeitfunktion muss eine bestimmte Zahl gleichzeitiger Nutzer verkraften. Testen Sie den Kern unter Last, bevor Sie Screens entwerfen.
Halten Sie einen PoC eng: eine Frage, ein schriftlich festgehaltenes Erfolgskriterium und echte Eingabedaten. Wenn Sie anfangen, einen Login-Screen einzubauen, ist es kein PoC mehr.
Beruht die Idee auf KI, ist der PoC meist ein Evaluationsset: echte Beispiele mit den erwarteten Antworten, automatisch bewertet. Wie Sie eines aufsetzen, beschreibt unser Leitfaden zur Entwicklung eines KI-MVP.
Prototyp: das Nutzungserlebnis testen, bevor Sie für Code bezahlen
Ein Prototyp zeigt, wie das Produkt funktionieren wird, damit Sie es vor Beginn der Entwicklung mit Menschen testen können. Die Nielsen Norman Group unterscheidet Low-Fidelity-Prototypen wie Papierskizzen von High-Fidelity-Prototypen, die dem fertigen Produkt in Aussehen und Verhalten nahekommen. Beide sind in unterschiedlichen Phasen nützlich.
Bauen Sie einen Prototyp, wenn:
- der Workflow neu ist oder mehrere Schritte hat, in denen sich Nutzer verlieren können.
- Sie sich mit Mitgründern, Stakeholdern oder einem Kunden darauf einigen müssen, was das Produkt tut.
- Sie Kapital einwerben und das Produkt zeigen müssen, statt es zu beschreiben.
Ein guter Prototyp deckt den Hauptpfad vom Start bis zum nützlichen Ergebnis ab, mit realistischen Inhalten. Testen Sie ihn mit etwa fünf Personen aus Ihrer Zielgruppe, achten Sie darauf, wo sie zögern, und ändern Sie das Design, bevor Code geschrieben wird. Einen Screen in Figma zu ändern dauert Minuten, ihn nach der Umsetzung zu ändern dauert Tage.
Was ein Prototyp Ihnen nicht sagen kann: ob die Leute wiederkommen, ob sie zahlen und ob das Produkt mit echten Daten standhält.
MVP: das kleinste echte Produkt
The Lean Startup beschreibt das MVP als den Weg, so schnell wie möglich mit dem Lernen zu beginnen. In der Praxis ist es die kleinste Version des Produkts, mit der ein echter Kunde seine Hauptaufgabe erledigen kann und für die er idealerweise bezahlt.
Ein MVP ist kein grober Prototyp mit nachgerüstetem Login. Es ist echte Software:
- Echte Konten und echte Daten, sicher gespeichert.
- Ein Kern-Workflow, der durchgängig funktioniert.
- Bei einem Abo-Produkt Abrechnung und Trennung zwischen Kunden vom ersten Tag an. Warum, erklärt unser Leitfaden zum SaaS-MVP.
- Code, auf dem die nächsten Versionen aufbauen, statt ihn wegzuwerfen.
Minimal ist der Umfang, nicht die Qualität. Streichen Sie Funktionen, nicht Fundamente.
So wählen Sie den ersten Schritt
Beantworten Sie diese Fragen der Reihe nach:
- Gibt es einen Teil, der technisch unmöglich sein könnte? Wenn ja, beginnen Sie mit einem Proof of Concept nur für diesen Teil.
- Ist der Workflow neu, oder müssen sich mehrere Personen darauf einigen? Wenn ja, bauen Sie einen Prototyp und testen Sie ihn mit Nutzern.
- Wissen Sie bereits, dass Nutzer das wollen, etwa durch eine Warteliste, Vorbestellungen, einen bestehenden Kunden oder eigene Erfahrung? Wenn ja, gehen Sie direkt zum MVP.
| Situation | Beginnen Sie mit |
|---|---|
| Die KI soll eine Aufgabe erledigen, die Sie noch kein Modell zuverlässig haben lösen sehen | Proof of Concept mit Evaluationsset |
| Ein neuer Workflow für nicht-technische Nutzer | Prototyp, dann MVP |
| Sie ersetzen einen Tabellenprozess, den Sie gut kennen | MVP |
| Eine Integration, bei der Sie nicht sicher sind, ob das andere System sie unterstützt | Proof of Concept für die Integration |
| Eine Pre-Seed-Runde ohne bestehendes Produkt | Prototyp |
| Ein bestehender Kunde wartet darauf, es zu nutzen | MVP |
Häufige Fehler
- Einen Prototyp MVP nennen. Klickbare Screens zeigen nicht, ob Menschen ein Produkt weiter nutzen.
- Den PoC aufpolieren. Ein Proof of Concept, der zum Produkt heranwächst, trägt seine Abkürzungen in die Produktion.
- Bei einem komplexen Workflow den Prototyp überspringen. Designprobleme, die erst nach der Umsetzung auffallen, sind am teuersten zu beheben.
- Ein MVP mit zehn Funktionen. Jede zusätzliche Funktion verzögert das erste echte Feedback.
- Kein schriftliches Erfolgskriterium. Ohne eines sieht jedes Ergebnis wie ein Grund aus, weiterzumachen.
Ein sinnvoller Weg für die meisten Produkte
- Discovery: Halten Sie fest, wer der Nutzer ist, welche Aufgabe er hat, welche Annahme am riskantesten ist und woran Sie erkennen, dass es funktioniert hat.
- Bei einem technischen Risiko ein kurzer Proof of Concept zu genau diesem Risiko.
- Bei einem neuen Workflow ein Prototyp, getestet mit echten Nutzern.
- Das MVP, begrenzt auf die eine Aufgabe, mit echten Konten und Daten.
- Launch für eine kleine Gruppe, messen und entscheiden, was als Nächstes gebaut wird.
Das Service Manual der britischen Regierung beschreibt eine ähnliche Abfolge: eine Discovery-Phase, um das Problem zu verstehen, eine Alpha-Phase, um verschiedene Lösungen auszuprobieren, und eine Beta-Phase, um einen echten Service zu bauen und mit Nutzern zu testen.
Brauchen Sie Hilfe bei der Entscheidung?
Wir helfen Gründern und Produktteams zu entscheiden, was sie zuerst bauen, und bauen es dann: Proofs of Concept für KI- und Integrationsrisiken, Prototypen in Figma sowie SaaS- und KI-MVPs in TypeScript. Beschreiben Sie uns Ihre Idee auf unserer Seite zur MVP-Entwicklung, oder sehen Sie sich an, wie wir SaaS-Produkte und UI/UX-Designs umsetzen.
