Die MVP-Produkt-Discovery-Phase: Was Sie Ist und Warum Sie Zuerst Kommt

Der wichtigste Einzelfaktor dafür, ob ein MVP im Budget bleibt, ist nicht die Geschwindigkeit des Entwicklungsteams. Es ist, ob Discovery stattgefunden hat, bevor die Entwicklung begann, oder in einen Kickoff-Call gequetscht wurde, weil die Gründerin unbedingt Code sehen wollte. Discovery ist unglamourös — sie produziert Dokumente, keine Demo —, und genau deshalb ist sie die Phase, die am ehesten überstürzt wird, und genau deshalb ist das Überstürzen die teuerste verfügbare Abkürzung in einem MVP-Build.

Dieser Leitfaden behandelt, was eine echte Discovery-Phase hervorbringt, wie lange sie dauern sollte, und was mit den Kosten und dem Zeitrahmen eines Builds passiert, wenn sie übersprungen wird.

Was Discovery Tatsächlich Ist

Discovery ist der strukturierte Prozess, der eine validierte Idee in einen baubaren Umfang verwandelt: für wen das Produkt ist, welche Aufgabe es erfüllt, wie das Datenmodell aussieht und was das Team im ersten Release bauen wird und was nicht. Sie liegt zwischen Ideenvalidierung und Entwicklung — nachdem Sie wissen, dass Menschen das Produkt wollen, bevor jemand Anwendungscode schreibt.

Sie bringt typischerweise vier konkrete Deliverables hervor:

1. Ein Problem-Statement-Dokument — eine Seite, die das Problem benennt, wer es hat und warum bestehende Lösungen versagen
2. User-Journey-Maps — der tatsächliche Schritt-für-Schritt-Pfad, den eine Nutzerin durch den Kern-Workflow des Produkts nimmt
3. Ein festgelegtes Scope-Dokument — die konkrete Feature-Liste für v1, mit allem anderen explizit auf v2 verschoben
4. Wireframes oder ein klickbarer Prototyp — mit niedriger Detailtreue, aber genug, um eine Nutzerin durch den Ablauf zu führen, bevor eine Zeile Produktivcode existiert

Wenn ein "Discovery"-Engagement nur ein Angebot oder ein Gantt-Diagramm hervorbringt, ist es keine Discovery — es ist ein Verkaufsdokument.

Warum Discovery Vor Design und Entwicklung Kommt

Design und Entwicklung sind teuer, noch einmal zu machen. Dokumente und Wireframes sind billig, noch einmal zu machen. Discovery existiert, um die teuren Entscheidungen — was das Produkt tut, für wen es ist, welche Daten es braucht — in die billige Phase zu zwingen, bevor eine Designerin fünf Bildschirme um eine Annahme herum gebaut hat, die sich als falsch herausstellt.

Teams, die Discovery überspringen, überspringen nicht die Entscheidungen. Sie treffen sie nur implizit, eine nach der anderen, während der Entwicklung — was bedeutet, dass das Engineering-Team Produktentscheidungen unter Termindruck trifft, und jede falsche kostet einen Neubau statt einer neuen Skizze.

Was Eine Strukturierte Discovery-Phase Abdeckt

Stakeholder- und Nutzerinterviews

Wenn Ideenvalidierung (siehe unseren Leitfaden zur Validierung einer SaaS-Idee) noch nicht stattgefunden hat, passiert sie hier in der Discovery. Wenn sie schon stattgefunden hat, geht Discovery eine Ebene tiefer — sie kartiert den konkreten Workflow, den das Produkt unterstützen muss, statt nur zu bestätigen, dass das Problem existiert. Und wenn Sie noch zwischen einem Wegwerf-Technikexperiment und einer echten Discovery-Phase entscheiden, behandelt PoC vs. MVP diese Weggabelung.

User-Journey-Mapping

Eine User-Journey-Map ist der Schritt-für-Schritt-Pfad von "Nutzerin hat das Problem" zu "Nutzerinnenproblem wird von Ihrem Produkt gelöst", inklusive jedem Entscheidungspunkt, jeder Stelle, an der sie abspringen könnte, und jeder Information, die sie an jedem Schritt braucht. Das ist es, was aus einer Feature-Liste einen tatsächlichen Produktablauf macht.

Datenmodell und Technisches Scoping

Welche Entitäten muss das Produkt erfassen, und wie stehen sie zueinander in Beziehung? Eine Discovery-Phase sollte mindestens einen ersten Entwurf eines Datenmodells hervorbringen — Accounts, Nutzerinnen, die Kernobjekte, die das Produkt verwaltet —, weil diese Entscheidung fast jede darauffolgende technische Wahl prägt, einschließlich der Multi-Tenancy- und Architekturentscheidungen, die in unserem Tech-Stack-Leitfaden behandelt werden.

Das Festgelegte Scope-Dokument

Das mit Abstand wertvollste Artefakt, das Discovery hervorbringt: eine schriftliche, konkrete Liste dessen, was in v1 ausgeliefert wird, geprüft und freigegeben von wer auch immer den Build bezahlt. "Festgelegt" bedeutet, dass Änderungen daran einen bewussten Prozess durchlaufen, keine Slack-Nachricht mitten im Sprint. Für das Framework, das diese Liste wirklich minimal hält, siehe MVP Features: Need vs Want (derzeit auf Englisch verfügbar).

Wireframes und Ein Klickbarer Prototyp

Wireframes mit niedriger Detailtreue — keine ausgefeilten Designs —, die eine echte Nutzerin durchklicken kann, bevor die Entwicklung beginnt. Das ist der billigstmögliche Punkt, um zu entdecken, dass ein Kernablauf verwirrend ist, weil das Reparieren eines Wireframes eine Stunde dauert und das Reparieren eines gebauten Features Tage.

Wie Eine Schlechte Discovery-Phase Aussieht

Nicht jedes "Discovery"-Engagement ist echte Discovery. Ein paar Warnsignale, dass es eine Formalität ist statt eines echten Prozesses:

• Das Ergebnis ist ein Angebot, kein Scope-Dokument. Wenn das, was Sie am Ende erhalten, ein Verkaufspitch für die Entwicklungsphase ist statt einer konkreten, überprüfbaren Feature-Liste, hat die eigentliche Scoping-Arbeit noch nicht stattgefunden.
• Keine Interviews mit echten Nutzerinnen, nur Gespräche mit der Gründerin über ihre Vision. Discovery, die die Menschen überspringt, die das Produkt tatsächlich nutzen werden, ist Discovery nur dem Namen nach.
• Wireframes, die eigentlich nur Mockups der bestehenden Idee der Gründerin sind, erstellt ohne zu testen, ob der Ablauf für jemanden Sinn ergibt, der ihn zum ersten Mal sieht.
• Ein Scope-Dokument ohne explizite "nicht in v1"-Liste. Ein festgelegter Umfang ist nicht nur, was drin ist — es ist ebenso klar ein schriftliches Protokoll dessen, was bewusst verschoben wurde, damit "können wir das nicht einfach noch hinzufügen" mitten im Build etwas Konkretes hat, gegen das es abgewogen wird.
• Es wird in einen einzigen Kickoff-Call gepresst. Echte Discovery braucht echte Gespräche, verteilt über mehrere Tage, keinen zweistündigen Termin mit einer nachträglich ausgefüllten Vorlage.

Wie Lange Discovery Dauern Sollte

Für ein fokussiertes SaaS-MVP läuft Discovery typischerweise 1-2 Wochen — sie speist direkt ein MVP, das in etwa 1 Woche steht, und danach die V1 in ca. 12 Wochen, wie in MVP in 1 Woche, V1 in 12 Wochen: Der Komplette Prozess (derzeit auf Englisch verfügbar) behandelt. Länger als das, und Discovery riskiert, selbst zu einer Form von Scope Creep zu werden, bei der das Team immer weiter recherchiert statt auszuliefern. Kürzer als das, und es ist keine Discovery — es ist ein Kickoff-Call mit angehängter Dokumentvorlage.

Was Das Überspringen Von Discovery Tatsächlich Kostet

Teams, die Discovery überspringen oder komprimieren, sparen die Zeit nicht — sie geben sie später aus, zu einem schlechteren Wechselkurs:

• Scope-Streitigkeiten mitten im Build, weil es nie ein freigegebenes Dokument gab, auf das man verweisen konnte
• Neu gebaute Bildschirme, weil sich das Datenmodell änderte, nachdem eine Designerin bereits um das falsche herum gebaut hatte
• Ein verwirrtes v1, weil die User Journey angenommen statt kartiert wurde, und der "offensichtliche" Ablauf für echte Nutzerinnen nicht offensichtlich war
• Eine Gründerin, die während der QA Produktentscheidungen debuggt, weil sie nie explizit während der Discovery getroffen wurden — sie wurden implizit getroffen, unter Termindruck, von wem auch immer diese Woche gerade dieses Feature baute

Die Wichtigsten Erkenntnisse

• Discovery verwandelt eine validierte Idee in einen baubaren Umfang: Problem-Statement, User Journeys, ein festgelegtes Scope-Dokument und Wireframes
• Sie existiert, um teure Entscheidungen in die billige Phase zu zwingen — Dokumente und Wireframes sind weit billiger neu zu machen als gebaute Features
• 1-2 Wochen ist das realistische Fenster für ein fokussiertes SaaS-MVP; länger riskiert, selbst zu Scope Creep zu werden
• Sie zu überspringen spart keine Zeit — es verschiebt dieselben Entscheidungen in die Entwicklung, wo sie mehr kosten, wenn sie falsch getroffen werden

Für den vollständigen Build-Prozess, in den Discovery mündet — Kosten, Tech-Stack und Teammodell — siehe unseren SaaS-MVP-Entwicklungsleitfaden. Bereit, Ihre richtig zu scopen? Unser Discovery-Prozess ist genau darum herum aufgebaut. Buchen Sie eine kostenlose Discovery-Beratung.