Die meisten gescheiterten Produkte sind nicht in der Entwicklung gescheitert. Sie sind in dem Moment gescheitert, in dem die Idee akzeptiert wurde, ohne getestet zu werden; die Entwicklung hat dieses Scheitern nur Monate später teuer und sichtbar gemacht.
Die drei Annahmen, auf denen jede Idee ruht
Problemannahme: Ist das wirklich schmerzhaft?
Nicht "wäre das nett zu haben", sondern ob es jemanden heute real Zeit, Geld oder Risiko kostet, und zwar oft genug, dass er sein Verhalten ändern würde, um es zu beheben.
Lösungsannahme: Löst genau dieser Ansatz das Problem?
Ein reales Problem kann trotzdem die falsche vorgeschlagene Lösung haben. Discovery testet die Lösung, nicht nur den Schmerz.
Viabilitätsannahme: Wird das jemand tatsächlich adoptieren oder dafür bezahlen?
Interesse ist keine Adoption. Menschen sagen oft, sie würden etwas nutzen, und ändern dann kein Verhalten, sobald es verfügbar ist.
Discovery-Methoden nach Evidenzstärke geordnet
| Methode | Evidenzstärke | Geschwindigkeit | Am besten für |
|---|---|---|---|
| Meinungsumfragen | Schwach | Schnell | Nur frühe Problem-Einordnung, nie ein Go/No-Go-Signal |
| Kundeninterviews über vergangenes Verhalten | Mittel | Schnell | Bestätigen, dass das Problem real und häufig ist |
| Klickbarer Prototyp-Test | Mittel | Mittel | Testen, ob ein vorgeschlagener Ablauf sinnvoll ist |
| Concierge- oder manueller Pilot | Stark | Mittel | Zahlungs- oder Adoptionsbereitschaft testen, bevor irgendetwas gebaut wird |
| Funktionierendes MVP mit echten Nutzungsdaten | Am stärksten | Langsam | Retention und gewohnheitsmäßige Nutzung bestätigen, nicht nur Erstnutzung |
Ein schlanker Discovery-Prozess
Schreiben Sie die Annahme auf, die Ihnen am meisten Sorgen macht
Nicht die ganze Idee, sondern die eine Annahme, die die Idee killt, wenn sie falsch ist. Testen Sie diese zuerst.
Sprechen Sie mit 8 bis 12 Personen, die das Problem kürzlich erlebt haben
Fragen Sie nach konkretem vergangenem Verhalten, nicht nach hypothetischem zukünftigem Verhalten. "Erzählen Sie mir vom letzten Mal, als das passiert ist" schlägt "würden Sie ein Tool nutzen, das X macht".
Fahren Sie eine manuelle oder Concierge-Version, bevor Sie irgendetwas bauen
Liefern Sie das Ergebnis von Hand, auch ineffizient, an eine Handvoll echter Nutzer. Wenn niemand die manuelle Version will, wird die automatisierte Version das nicht beheben.
Legen Sie im Voraus ein Abbruchkriterium fest
Entscheiden Sie, welches Ergebnis Sie stoppen lassen würde, bevor Sie die Ergebnisse sehen. Ohne das wird eine uneindeutige Datenlage immer als "vielversprechend" interpretiert.
Pros
- +Fängt fatale Problem- oder Lösungs-Fehlpassungen ab, bevor Engineering-Kosten entstehen
- +Liefert echte Nutzersprache und Constraints, die den Scope verbessern, sobald der Bau beginnt
- +Erzwingt eine konkrete, falsifizierbare Aussage statt einer vagen Produktvision
Cons
- −Kann ohne Abbruchkriterium oder Deadline endlos zum Verzögern genutzt werden
- −Schwache Methoden (Umfragen, Meinungen) können falsches Vertrauen erzeugen, wenn sie als starke Evidenz behandelt werden
- −Manche Probleme erfordern wirklich ein funktionierendes Produkt, um sie richtig zu testen; Discovery hat Grenzen
Discovery beweist nicht, dass eine Idee richtig ist. Es ist der günstigste Weg, herauszufinden, dass sie falsch ist, bevor es der teure Weg tut.
Sobald eine Idee Discovery übersteht, lautet die nächste Frage meist Build vs. Buy vs. Assemble, gefolgt vom Scoping der ersten Version eng genug, um während des Bauens weiter zu testen.
FAQ
FAQ
Was ist Product Discovery?+
Product Discovery ist der Prozess, zu testen, ob ein Problem real ist, ob eine vorgeschlagene Lösung es tatsächlich löst und ob jemand dafür bezahlen oder sie adoptieren wird, bevor Engineering-Zeit in den Bau investiert wird.
Wie lange sollte Product Discovery dauern?+
Die meisten Discovery-Vorhaben sollten Tage bis wenige Wochen dauern, nicht Monate. Dauert Discovery länger als ein kleiner Build brauchen würde, ist meist der Prozess selbst zum Problem geworden.
Brauche ich Discovery auch, wenn die Idee offensichtlich erscheint?+
Ja. Scheinbar offensichtliche Ideen scheitern ständig an der Validierung, meist weil das angenommene Problem nicht so schmerzhaft, häufig oder ungelöst ist, wie das Team glaubte. Ein kurzer Discovery-Durchgang ist eine günstige Versicherung gegen einen teuren Build.
Verwandte Ressourcen
Product-Market-Fit: Woran Sie erkennen, dass Sie ihn wirklich haben
Product-Market-Fit wird weit häufiger behauptet, als er real ist. Eine konkrete Definition, die Signale, die ihn tatsächlich anzeigen, und die Signale, die häufig damit verwechselt werden.
BusinessWann braucht ein Unternehmen individuelle Software? Ein Entscheidungsframework
Individuelle Software ist teuer zu bauen und teuer, zum falschen Zeitpunkt darauf zu verzichten. Ein konkretes Framework, um zu entscheiden, ob Ihr Unternehmen Standardtools wirklich entwachsen ist.
BusinessSaaS MVP — Build-vs-Buy-Entscheidungsrahmen für 2026
Ein praktischer Rahmen, um zu entscheiden, ob Sie einen individuellen SaaS-MVP bauen, No-Code-Tools kombinieren oder bestehende Software kaufen — mit Trade-offs zu Kosten, Risiko und Geschwindigkeit.
Newsletter
Produktnotizen, kein Rauschen.
Gelegentliche Frameworks zu Portalen, SaaS-MVPs und Automatisierung.