Product Discovery in regulierten Umgebungen: Ein schlanker 3-Schritte-Prozess

Discovery in regulierten Umgebungen hat ein Problem: Die Standardmethoden funktionieren nicht.

Teresa Torres' Continuous Discovery setzt auf wöchentliche Kundeninterviews und iteratives Lernen. In unregulierten Märkten funktioniert das. In Gematik-, BaFin- oder OZG-Projekten nicht – weil jede Iteration Compliance-Aufwand bedeutet.

Gleichzeitig ist "keine Discovery" keine Option. Wer baut, bevor das Problem klar ist, verschwendet Monate.

Dieser Artikel zeigt einen schlanken 3-Schritte-Prozess, der Discovery in regulierten Umgebungen praktikabel macht.

Das Problem mit Standard-Discovery

In unregulierten Märkten:

• Du baust ein Feature, testest es, iterierst
• Feedback-Zyklen dauern Tage
• Pivots sind billig

In regulierten Umgebungen:

• Jedes Feature durchläuft Compliance-Prüfung
• Feedback-Zyklen dauern Wochen bis Monate
• Pivots kosten Zertifizierungsaufwand

Konsequenz: Discovery muss vor dem Build abgeschlossen sein – nicht parallel dazu.

Der 3-Schritte-Prozess

Schritt 1: Problemdefinition (2-3 Tage)

Eine schlechte Problemdefinition ist der häufigste Grund für gescheiterte Features. In regulierten Umgebungen ist sie fatal – weil du nicht einfach "nochmal iterieren" kannst.

Schlechte Problemdefinition:

"Nutzer haben Probleme mit der ePA-Integration."

Gute Problemdefinition:

"65% der Apotheker brechen die ePA-Abfrage ab, weil der Prozess mehr als 3 Klicks erfordert und keine Rückmeldung gibt, ob die Verbindung steht."

Kriterien für gute Problemdefinitionen:

• Präzise: Ein Satz, keine Interpretation nötig
• Messbar: Enthält Zahlen oder klare Kriterien
• Kundenorientiert: Aus Nutzerperspektive formuliert
• Lösungsneutral: Beschreibt das Problem, nicht die Lösung

Datenquellen in regulierten Umgebungen:

• Support-Tickets und Hotline-Protokolle
• Nutzungsdaten aus dem Live-System
• Stakeholder-Interviews (Ärzte, Apotheker, Sachbearbeiter)
• Feedback aus Schulungen und Onboardings

Zeitinvestition: 2-3 Tage. Nicht mehr. Wer länger braucht, hat zu wenig Fokus oder zu wenig Daten.

---

Schritt 2: Hypothesen entwickeln und priorisieren (3-5 Tage)

Eine Hypothese ist eine testbare Annahme. Sie verbindet Problem und Lösung.

Struktur:

"Wenn [Aktion], dann [erwartetes Ergebnis], gemessen an [Metrik]."

Beispiel:

"Wenn wir die ePA-Abfrage auf einen Klick reduzieren und einen Verbindungsstatus anzeigen, dann sinkt die Abbruchrate von 65% auf unter 30%, gemessen an der Completion Rate im Live-System."

Priorisierung mit Fokusmatrix:

In regulierten Umgebungen gilt zusätzlich: Compliance-Aufwand bewerten. Ein Feature mit niedrigem Dev-Aufwand kann hohen Zertifizierungsaufwand haben.

Fragen zur Priorisierung:

• Wie groß ist der Impact auf die Kernmetrik?
• Wie hoch ist der Entwicklungsaufwand?
• Welche Compliance-Prüfungen sind erforderlich?
• Können wir vor der Implementierung validieren?

---

Schritt 3: Hypothesen testen (1-2 Wochen)

Testen heißt nicht: Feature bauen und ausrollen. Testen heißt: Validieren, bevor du Compliance-Aufwand investierst.

Testmethoden in regulierten Umgebungen:

Beispiel aus einem Gematik-Projekt:

Hypothese: Apotheker brechen ab, weil sie nicht wissen, ob die ePA-Verbindung steht.

Test: Klick-Dummy mit Verbindungsstatus-Anzeige, getestet mit 8 Apothekern.

Ergebnis: 7 von 8 bestätigten, dass der Status ihr Hauptproblem lösen würde.

Nächster Schritt: Feature spezifizieren, Compliance-Prüfung starten.

Nach dem Test: Bewerten und iterieren

Fragen nach jedem Test:

• Wurde die Hypothese bestätigt?
• Was haben wir gelernt?
• Was ist der nächste Schritt?

Wenn bestätigt: Implementierung planen, Compliance-Prozess starten. Wenn nicht bestätigt: Neue Hypothese formulieren oder Problem neu definieren.

---

Warum dieser Ansatz funktioniert

Vergleich mit Continuous Discovery:

Continuous Discovery ist nicht falsch – aber für regulierte Umgebungen nicht praktikabel. Der 3-Schritte-Prozess liefert validierte Entscheidungen, bevor Compliance-Aufwand entsteht.

Für wen geeignet:

• Teams in Gematik-, BaFin- oder OZG-Projekten
• Produktmanager unter Zeitdruck
• Organisationen ohne etablierte Discovery-Kultur

---

Zusammenfassung

Gesamt: 2-3 Wochen statt monatelanger Discovery-Zyklen.

In regulierten Umgebungen zählt nicht, wie oft du iterierst. Es zählt, dass du vor dem Build weißt, was du baust – und warum.