Produkt-Discovery

Discovery ist ein Werkzeugkasten von Techniken, von denen jede eine andere Art von Frage beantwortet. Kundeninterviews (zum Verständnis von Problemen und Motivationen): 60-minütige Einzelgespräche, die sich auf den aktuellen Workflow des Kunden konzentrieren – nicht auf Feature-Feedback. Der Interviewer bittet den Kunden, zu erklären, wie er eine bestimmte Aufgabe heute erledigt, und fragt nach Schmerzpunkten, Workarounds und Momenten der Verwirrung oder Frustration. Optimale Kadenz: Jeder PM führt 2–4 Interviews pro Woche auf kontinuierlicher Basis durch. Usability-Tests (zur Validierung von Designs): Beobachten Sie 5–8 Teilnehmer, die versuchen, eine bestimmte Aufgabe mit einem Prototyp oder einem Live-Produkt zu erledigen – der Test deckt Usability-Probleme auf, die Analysen nicht erkennen können (Benutzer, die wissen, dass „etwas nicht stimmt“, es aber nicht artikulieren können). Konzepttests (zur Validierung von Lösungen vor dem Bau): Präsentieren Sie 10–15 Kunden eine schriftliche oder als Mockup dargestellte vorgeschlagene Lösung und messen Sie deren Verständnis, Attraktivität und vorhergesagte Verhaltensänderung. Prototypentests: Erstellen Sie den Prototyp mit der geringsten Wiedergabetreue, der das Testen der riskantesten Annahme ermöglicht, und beobachten Sie, wie echte Benutzer damit interagieren. Fake-Door-Tests: Erstellen Sie ein UI-Element (Schaltfläche, Menüpunkt) für eine Funktion, die noch nicht existiert, messen Sie die Klickrate und sammeln Sie E-Mails von interessierten Benutzern – dies beweist die Nachfrage vor jeglichem Entwicklungsaufwand.

Continuous Discovery, populär gemacht von Teresa Torres, ist die Praxis, kleine, häufige Discovery-Aktivitäten fortlaufend durchzuführen – anstatt großer periodischer Forschungsphasen mit langen Pausen dazwischen. Das traditionelle Modell: Ein Produktteam unterbricht die gesamte Entwicklung für eine 4–6-wöchige „Discovery-Phase“, führt umfangreiche Forschung durch, präsentiert Ergebnisse und tritt dann in eine längere Delivery-Periode ohne neue Discovery ein. Das Problem: Die Welt ändert sich, Kundenprioritäten verschieben sich, und die Annahmen aus der Discovery-Phase veralten während der langen Delivery-Periode. Continuous Discovery ersetzt vierteljährliche Big-Bang-Forschung durch wöchentliche oder zweiwöchentliche Discovery-Aktivitäten mit kleinem Umfang: Jeder PM führt jede Woche 2 Kundeninterviews durch, nicht als Projekt, sondern als professioneller Rhythmus wie ihr wöchentliches Planungstreffen. Die Erkenntnisse aus diesen regelmäßigen Kontaktpunkten werden im Forschungs-Repository des Teams (Dovetail, Notion) protokolliert, und Muster entstehen organisch, ohne dass eine formale Synthesephase erforderlich ist. Teams, die mit Continuous Discovery arbeiten, treffen durchweg bessere Produktentscheidungen, weil sie einen aktuellen, spezifischen Kundenkontext haben, anstatt Forschungserkenntnisse, die 3–6 Monate alt sind.

Assumption Mapping ist eine strukturierte Technik zur Identifizierung und Priorisierung der Annahmen, die einer Produktentscheidung zugrunde liegen, und zur anschließenden Gestaltung der minimalen Experimente, die erforderlich sind, um die riskantesten Annahmen vor der Entwicklungszusage zu validieren oder zu invalidieren. Der Prozess: Für jede bedeutende Produktinitiative listet das Team alle Annahmen auf, die für den Erfolg der Initiative zutreffen müssen. Beispielannahmen für einen neuen Onboarding-Flow: „Neue Benutzer sind durch den aktuellen Setup-Assistenten verwirrt“ (stimmt das tatsächlich, und ist Verwirrung die Hauptursache für eine geringe Aktivierung?); „Ein geführter Tour-Format reduziert die Aktivierungszeit“ (haben wir geführte Touren im Vergleich zum aktuellen Assistenten getestet?); „Benutzer, die in Woche 1 aktivieren, haben eine höhere 6-monatige Bindung“ (gibt es tatsächlich eine kausale Beziehung, nicht nur eine Korrelation?). Jede Annahme wird dann auf einer 2×2-Matrix dargestellt: Achse 1 ist die Sicherheit (wie sicher sind wir, dass diese Annahme wahr ist?); Achse 2 ist die Wichtigkeit (wie entscheidend ist es, dass diese Annahme für den Erfolg der Initiative zutrifft?). Annahmen mit hoher Wichtigkeit + geringer Sicherheit sind die Discovery-Prioritäten – das Team entwirft den minimalen Test (Benutzerinterview, Prototypentest oder Fake Door), der die Annahme von geringer Sicherheit zu hoher Sicherheit verschiebt, bevor die vollständige Entwicklung zugesagt wird.