Der Prototyp scheitert vor dem ersten Nutzer

In mehreren Vibe-Coding-Workshops haben wir Prototypen erlebt, die technisch funktionierten und trotzdem keinen Nutzer erreichten. Bereits das eigene Team war mit dem Ergebnis unzufrieden. In diesen Fällen lagen die entscheidenden Lücken beim Problemverständnis, bei der Funktionsweise des Angebots oder beim Userflow.

Häufig stand die Lösung schon fest: eine App, ein Portal, eine bestimmte Funktion. Welche Situation sich für welchen Menschen verbessern sollte und wie das im Alltag funktionieren würde, war deutlich weniger klar.

Die folgenden Beobachtungen verdichten wiederkehrende Muster aus mehreren Schulungen. Sie beschreiben keinen einzelnen Teilnehmerfall.

Fehlende Entscheidungen werden beim Bauen nachgeholt

Ein Prompt kann eine Oberfläche genau beschreiben und trotzdem wesentliche Produktfragen offenlassen. Woher kommen die angezeigten Inhalte? Wer hält sie aktuell? Was passiert nach dem Klick? Woran erkennt der Nutzer, dass sein Anliegen erledigt ist?

Beim Bauen werden solche Lücken zu Entscheidungen. Beispieldaten füllen eine Liste. Ein Button führt zu einer Bestätigung. Eine zusätzliche Funktion überbrückt eine ungeklärte Stelle. So entsteht ein Ablauf, der auf dem Bildschirm plausibel aussieht, dessen Voraussetzungen aber niemand geprüft hat.

Mit jedem weiteren Prompt kann sich die App von der ursprünglichen Absicht entfernen. Das Team repariert einzelne Screens, obwohl es die Logik des Angebots ändern müsste.

Ob die Idee am Markt trägt, ist damit noch offen. Zunächst muss klar werden, was der Prototyp überhaupt prüfen soll. Dabei helfen drei kurze Arbeitsdokumente:

Problem → Betriebslogik → Userflow → Prototyp

Jedes Dokument hält die Entscheidungen und Annahmen fest, die der nächste Schritt braucht. Dafür genügen Stichpunkte und eine Skizze. Die Dateien dürfen sich beim Bauen und Testen ändern.

Das Problem unabhängig von der App beschreiben

In problem-statement.md steht, für wen welches Problem in welcher Situation entsteht. Dazu gehören der heutige Umgang damit, seine Schwächen und die Folgen für den Nutzer.

Ein brauchbarer Start ist dieser Satz:

Wenn [Person] in [Situation] gerät, muss sie [Aufgabe] erledigen. Heute nutzt sie dafür [Vorgehen]. Dabei entsteht [konkreter Aufwand oder Nachteil].

„Es fehlt eine Plattform“ reicht dafür nicht. Eine Plattform ist bereits eine Lösungsentscheidung. Vielleicht lässt sich das Problem mit einer besseren Information, einem anderen Prozess oder einem bestehenden Produkt lösen.

Im Build-with-Vibe-Kurs nutzen wir dafür einen Kontext-Prompt in ChatGPT oder Claude. Er verdichtet einen Brain Dump und vorhandenes Material zu Problem Statement, Persona und Value Proposition. Er soll Widersprüche markieren und fehlende Informationen als Annahmen kennzeichnen.

Halte das Problem zunächst in problem-statement.md fest. Interviewnotizen, Support-Anfragen oder beobachtete Arbeitsabläufe gehören als Belege dazu, soweit sie vorliegen. Eine von der KI formulierte Persona bleibt eine Arbeitshypothese. Erfundenen Nutzerzitaten fehlt jeder Beweiswert.

Für offene Fragen zu bestehenden Angeboten kann etwa Deep Research in ChatGPT Quellen zusammentragen. Prüfe die Originalquellen. Ein recherchierter Marktüberblick zeigt Alternativen; ob deine Zielgruppe das Problem tatsächlich erlebt, musst du an ihr untersuchen.

Prüfpunkt: Kannst du das Problem verständlich beschreiben, ohne die geplante App zu nennen?

Die Betriebslogik hinter den Screens klären

Zwischen Problem und Userflow fehlt häufig eine weitere Beschreibung: Wie soll das Angebot überhaupt funktionieren?

Für diesen Check ergänzen wir die Kursartefakte um operating-model.md. Problem Statement und User Flows sind bereits Teil des Kurses.

Mit Betriebslogik ist hier gemeint, wie der versprochene Nutzen zustande kommt. Ein Ergebnis kann sofort vorliegen oder erst nach einer Bearbeitung. Daten können automatisch entstehen oder müssen von jemandem gepflegt werden. Eine Oberfläche muss diese Unterschiede abbilden.

Nutze ChatGPT oder Claude als Interviewpartner. Gib Problem Statement und bisherige Produktidee mit und lass dir die offenen Abhängigkeiten erklären. Der folgende Prompt ergänzt die Interviewtechnik aus dem Kurs:

Prüfe die Betriebslogik meiner Produktidee. Welche Inputs braucht der Kernnutzen, wer liefert sie, und was passiert, wenn sie fehlen? Stelle mir die wichtigste offene Frage zuerst, immer nur eine auf einmal. Markiere Widersprüche. Trenne belegte Fakten, getroffene Entscheidungen und ungetestete Annahmen. Erfinde keine Datenquellen oder Beteiligten. Verdichte meine Antworten anschließend in operating-model.md. Schlage einen kleinen Test für die folgenreichste unsichere Annahme vor. Schreibe noch keinen Code.

Diese Kurzvorlage kannst du direkt in operating-model.md kopieren. Stichpunkte reichen; markiere offene Antworten als Annahmen.

Kernnutzen: [Ergebnis für den Nutzer]
Inputs und Herkunft: [Was brauchen wir, woher kommt es?]
Verantwortung: [Wer liefert, bearbeitet und pflegt die Inputs?]
Voraussetzung und Ausfall: [Was muss verfügbar sein, was passiert sonst?]
Folgenreichste offene Annahme: [Was würde unseren Plan verändern?]
Nächster Test: [Kleinster geeigneter Test dieser Annahme]
Zugang: [Benötigte Person oder Quelle und wie wir sie erreichen]
Testgrenze: [Was ist echt, was simuliert, was prüfen wir damit nicht?]
Beobachtung und Entscheidung: [Welches Ergebnis führt zu welchem nächsten Schritt?]

Prüfpunkt: Kannst du erklären, wie der Nutzer zu seinem Ergebnis kommt, einschließlich der Arbeit hinter der Oberfläche?

Den Weg bis zum ersten Nutzen durchgehen

user-flows.md beschreibt, was der Nutzer Schritt für Schritt tut und was das Produkt jeweils zurückgibt. Eine Liste von Screens genügt dafür nicht: „Startseite, Übersicht, Detailseite“ erklärt noch keinen Ablauf.

Beginne mit einem zentralen Weg. Halte den Einstieg, die nötige Eingabe, die Kernaktion und den sichtbaren Erfolg fest. Beschreibe pro Screen eine primäre Nutzeraktion. Ergänze den Ausfallfall aus der Betriebslogik, der das Nutzenversprechen am ehesten brechen würde.

Im Kurs erzeugt der User-Flow-Prompt aus Persona, abgegrenztem Funktionsumfang und Designrichtung zunächst einen kleinen Hauptablauf. Gib für diesen Check auch operating-model.md mit, damit der Flow die Voraussetzungen und Arbeitsschritte berücksichtigt. Der relevante Ausfallfall kommt ausdrücklich hinzu. So bleibt sichtbar, ob ein Nutzer beispielsweise weiterarbeiten kann, wenn eine notwendige Information fehlt.

Optional übersetzt Google Stitch den beschriebenen Flow in Screens, die sich zu einem klickbaren Ablauf verbinden lassen. Das hilft, Übergänge zu prüfen. Ein überzeugender Screen bestätigt allerdings weder eine Datenquelle noch die Verfügbarkeit eines Beteiligten.

Prüfpunkt: Kannst du den Weg vom Einstieg bis zum ersten Nutzen durchgehen, ohne einen fehlenden Schritt mündlich dazuzuerfinden?

Bauen, sobald der nächste Test klar ist

Die drei Artefakte müssen vor dem ersten Build-Prompt keine Gewissheit liefern. Sie sollen erkennen lassen, was du weißt, was du entschieden hast und was du noch testen musst. Prompts zur Klärung gehören ausdrücklich zur Vorbereitung.

Manche Lücken werden erst im Prototyp sichtbar. Dann gehst du zum betroffenen Dokument zurück, korrigierst die Annahme und passt den Flow an. Auch eine frühe technische Probe ist sinnvoll, wenn gerade die Machbarkeit unklar ist.

Wähle den nächsten Test nach der Unsicherheit. Wenn das Konzept von einer ungeklärten Datenquelle abhängt, kann zuerst ein Gespräch mit dem Anbieter nötig sein. Wenn der Ablauf unklar ist, baue genau diesen Ablauf und beobachte Nutzer dabei.

Für diesen Build kannst du die Dokumente an Lovable oder v0 übergeben. Beide dokumentieren, wie Kontext und klarer Umfang die Umsetzung steuern. Gib zusätzlich an, welche Daten simuliert sind und welches Verhalten der Test zeigen soll.

Eine Reaktion auf Beispieldaten kann etwas über die Verständlichkeit des Flows zeigen. Sie beweist nicht, dass du später genügend echte Daten beschaffen kannst. Ebenso ist eine intern gelungene Demo noch kein Beleg für Nachfrage.

Bei Strive nennen wir funktionale Software, mit der wir solche Verhaltensfragen prüfen, einen Behavioral Prototype. Er dient einer konkreten Lernfrage. Ein MVP folgt in unserer Methode, wenn wir Geschäftsannahmen im Markt prüfen.

Nimm deine aktuelle Produktidee und gehe die drei Prüfpunkte durch. Markiere die offene Annahme, deren Widerlegung deinen Plan am stärksten verändern würde. Damit hast du einen konkreten Ausgangspunkt für den nächsten Test.

Wenn dein Team dabei Unterstützung braucht, bringen wir mit dir Problem, Betriebslogik und Userflow in einen testbaren Behavioral Prototype.

Erstgespräch buchen