Zusammenfassung
Forschung muss zur sich entwickelnden Fidelity des Produkts passen: generative Forschung in der Ideenphase, formative Evaluation während des Prototyping, summative Evaluation vor dem Launch und kontinuierliches Feedback nach dem Launch. Das Fundament für effektive Forschung ist ein psychologisch sicheres Team, in dem Mitglieder hinterfragen, widersprechen und Fehler zugeben können. Generative Forschung zu überspringen ist der teuerste Fehler, den eine Organisation machen kann.
Einer der häufigsten Reibungspunkte in Organisationen dreht sich nicht um Budget oder Methoden, sondern um Timing.
Die einfache Antwort auf „Wann ist die beste Zeit für Forschung?" ist „immer". Die reale Antwort ist, dass es ein ständiger Kampf ist, weil es sich für viele Teams nie nach dem richtigen Zeitpunkt anfühlen wird.
Das interne Fundament: Ihr Team
Bevor wir besprechen, wie Sie Stakeholder navigieren, müssen wir mit der kritischsten Komponente Ihres Erfolgs beginnen: Ihrem unmittelbaren Team.
Die Qualität Ihrer Insights ist ein direktes Spiegelbild der Gesundheit der Zusammenarbeit in Ihrem Team. Sie können die rigorosesten Methoden und die schärfste Analyse haben, aber wenn Ihr internes Team in Silos arbeitet oder Vertrauen fehlt, wird Ihre Arbeit nie ihr volles Potenzial erreichen.
Psychologische Sicherheit
Das Ziel ist ein Umfeld zu schaffen, in dem Disziplinen wie Marktforschung, CX und UX Research kollaborative Partner sind, keine konkurrierenden Funktionen [1].
Im Forschungskontext bedeutet psychologische Sicherheit:
| Verhalten | Wie es aussieht |
|---|---|
| Mit Neugier hinterfragen | Eine Methodik in Frage stellen, ohne als inkompetent zu gelten |
| Respektvoll widersprechen | Dateninterpretation diskutieren, um zu robusteren Ergebnissen zu gelangen |
| Ohne Angst scheitern | Offen zugeben, wenn eine Studie nicht funktioniert oder eine Hypothese falsch war |
Ein Team, das sich intern psychologisch sicher fühlt, ist nach außen deutlich widerstandsfähiger. Es bietet das kollektive Selbstvertrauen, schwierige, objektive Wahrheiten zu vermitteln, die Stakeholder hören müssen.
Für einen tiefen Einblick in den Aufbau von Research-Kultur und Teamzusammenarbeit, siehe Research-Kultur aufbauen: Sicherheit & Zusammenarbeit.
Forschung auf die Produktreife abstimmen
Ihre Kernaufgabe ist es, Forschung von einem einzelnen, disruptiven Ereignis in eine kontinuierliche, wertschöpfende Schleife umzurahmen. Dafür müssen Sie Ihre Forschungsaktivitäten an die sich entwickelnde Fidelity des Produkts anpassen.
Phase 1: Idee und Konzept (Generative Research)
Wann: Bevor Sie irgendetwas bauen, wenn Sie mit abstrakten Ideen und Konzepten arbeiten.
Zweck: Bestimmen Sie, was gebaut werden soll, bevor Sie darüber nachdenken, wie es gebaut werden soll. Entrisiken Sie Ihre gesamte Strategie, indem Sie sicherstellen, dass Sie ein echtes Problem für eine echte Zielgruppe lösen.
Phase 2: Während des Prototyping (Formative Evaluation)
Wann: Wenn Ideen zu greifbaren Prototypen werden, in niedriger, mittlerer und hoher Fidelity.
Zweck: Probleme finden und beheben, solange sie noch günstig zu lösen sind. Ein UX Test sollte bei jeder größeren Iteration oder immer dann ausgelöst werden, wenn sich ein Cluster wichtiger Fragen ansammelt.
Heute kann ein Prototyp sein:
- Ein klickbares Figma- oder Adobe-XD-Design
- Eine teilweise funktionale codierte App
- Ein SDK oder Test-Build, verteilt über Plattformen wie TestFlight
Unabhängig vom Format ist dies die beste Zeit, um Probleme zu identifizieren und zu lösen, solange Änderungen kostengünstig sind.
Phase 3: Vor dem Launch (Summative Evaluation)
Wann: Kurz vor einem Release mit einem High-Fidelity-Prototyp oder MVP.
Zweck: Der finale Qualitätscheck. Allerdings müssen Sie die Erwartungen managen, was in dieser Phase möglich ist.
Phase 4: Nach dem Launch (Live-Produkt)
Wann: Sobald das Produkt auf dem Markt ist.
Zweck: Kontinuierliche Feedbackschleife bestehend aus:
- Passive Daten: Analytics und A/B Tests liefern quantitative Daten im großen Maßstab
- Aktive Forschung: UX Benchmarking, laufende qualitative Studien, um das „Warum" hinter den Zahlen zu verstehen
In dieser reifen Phase verschwimmen die Grenzen. Eine einzelne Session kann damit beginnen, einen bestehenden Workflow zu evaluieren, und mit generativen Fragen enden, um neue Feature-Ideen zu validieren.
Für den detaillierten Forschungsplan, den jede Fidelity-Stufe erfordert, siehe Der Forschungsplan: Ihr Blueprint für rigorose Studien.
Der Research-Timing-Lebenszyklus
| Phase | Research-Typ | Kernfrage | Kosten des Überspringens |
|---|---|---|---|
| Idee/Konzept | Generativ | „Was sollten wir bauen?" | Das Falsche bauen |
| Prototyping | Formativ | „Was funktioniert nicht?" | Teure Nacharbeit nach der Entwicklung |
| Pre-Launch | Summativ | „Wie gut performt es?" | Launch mit vermeidbaren Problemen |
| Post-Launch | Kontinuierlich | „Was passiert und warum?" | Blind für die reale Performance |
Die drei kritischen Momente für Research
Forschung ist kein einmaliges Ereignis; sie verändert sich, während das Produkt reift. Hier ist die Timeline, die jede*r PM verinnerlichen sollte:
START → Ideenphase (Generativ) Vor dem Code. Validieren Sie das Problem, nicht die Lösung. Fragen Sie nicht „Gefällt Ihnen diese Idee?" Fragen Sie „Wie lösen Sie das aktuell?" Das verhindert, Features zu bauen, die niemand will.
MITTE → Prototyping (Formativ) Während des Designs. Iteratives Usability Testing findet Reibung, solange sie günstig zu beheben ist. Eine Änderung in Figma kostet 50 €; dieselbe Änderung im Code kostet 5.000 €.
ENDE → Live-Produkt (Summativ) Nach dem Launch. Benchmarking und Analytics beantworten: Haben wir das Ziel erreicht? Nutzen Sie standardisierte Metriken (SUS, NPS), um Verbesserung über die Zeit zu tracken.
Umgang mit der „Nicht jetzt"-Antwort
Wenn Stakeholder beim Research-Timing abblocken, ist die Ursache meist Angst oder Druck:
„Es ist zu früh": Angst, dass negatives Feedback zu einem unpolierten Prototyp entmutigend wirkt.
Antwort: „Genau deshalb sollten wir jetzt testen. Wenn wir ein fundamentales Problem in dieser Phase finden, ist es viel günstiger zu beheben als nach Wochen der Entwicklung."
„Das wird uns ausbremsen": Druck, schnell voranzukommen.
Antwort: „Forschung wird kein Engpass sein. Denken Sie daran wie an einen Git Branch: Die Entwicklung läuft auf dem Main Branch weiter, während Forschung parallel läuft. Wenn wir fertig sind, mergen wir die Ergebnisse zurück."
Was das für die Praxis bedeutet
Forschung ist kein Gate, das passiert werden muss; sie ist ein kontinuierlicher Puls, der jede Phase der Produktentwicklung informiert.
Bauen Sie ein Teamfundament psychologischer Sicherheit, das ehrliche, rigorose Arbeit ermöglicht. Dann ordnen Sie Ihre Forschungsaktivitäten der Fidelity des Produkts zu: generativ am Anfang, formativ während der Entwicklung, summativ vor dem Launch und kontinuierlich danach.
Das Ziel ist nicht, Forschung für das Produktteam zu machen. Es ist, Forschung mit ihnen zu machen, während der gesamten Reise.
Für eine detaillierte phasenweise Timing-Anleitung, siehe Wann forschen: Ein Leitfaden für Produktteams.
Quellenverzeichnis
- [1]