Product Discovery in Regulated Environments: A Lean 3-Step Process

Discovery in regulated environments has a problem: Standard methods don't work.

Teresa Torres' Continuous Discovery relies on weekly customer interviews and iterative learning. In unregulated markets, that works. In Gematik, BaFin, or OZG projects, it doesn't – because every iteration means compliance effort.

At the same time, "no discovery" isn't an option. Building before the problem is clear wastes months.

This article shows a lean 3-step process that makes discovery practical in regulated environments.

The Problem with Standard Discovery

In unregulated markets:

• You build a feature, test it, iterate
• Feedback cycles take days
• Pivots are cheap

In regulated environments:

• Every feature goes through compliance review
• Feedback cycles take weeks to months
• Pivots cost certification effort

Consequence: Discovery must be completed before the build – not parallel to it.

The 3-Step Process

Step 1: Problem Definition (2-3 Days)

A poor problem definition is the most common reason for failed features. In regulated environments, it's fatal – because you can't just "iterate again."

Poor problem definition:

"Users have problems with ePA integration."

Good problem definition:

"65% of pharmacists abandon the ePA query because the process requires more than 3 clicks and provides no feedback on whether the connection is established."

Criteria for good problem definitions:

• Precise: One sentence, no interpretation needed
• Measurable: Contains numbers or clear criteria
• Customer-oriented: Formulated from user perspective
• Solution-neutral: Describes the problem, not the solution

Data sources in regulated environments:

• Support tickets and hotline logs
• Usage data from the live system
• Stakeholder interviews (doctors, pharmacists, case workers)
• Feedback from training and onboarding sessions

Time investment: 2-3 days. No more. Anyone who needs longer has too little focus or too little data.

---

Step 2: Develop and Prioritize Hypotheses (3-5 Days)

A hypothesis is a testable assumption. It connects problem and solution.

Structure:

"If [action], then [expected result], measured by [metric]."

Example:

"If we reduce the ePA query to one click and display a connection status, then the abandonment rate drops from 65% to below 30%, measured by completion rate in the live system."

Prioritization with focus matrix:

In regulated environments, an additional factor applies: Evaluate compliance effort. A feature with low dev effort can have high certification effort.

Questions for prioritization:

• How large is the impact on the core metric?
• How high is the development effort?
• Which compliance reviews are required?
• Can we validate before implementation?

---

Step 3: Test Hypotheses (1-2 Weeks)

Testing doesn't mean: Build the feature and roll it out. Testing means: Validate before you invest compliance effort.

Testing methods in regulated environments:

Example from a Gematik project:

Hypothesis: Pharmacists abandon because they don't know if the ePA connection is established.

Test: Click dummy with connection status display, tested with 8 pharmacists.

Result: 7 of 8 confirmed that the status would solve their main problem.

Next step: Specify feature, start compliance review.

After the test: Evaluate and iterate

Questions after each test:

• Was the hypothesis confirmed?
• What did we learn?
• What's the next step?

If confirmed: Plan implementation, start compliance process. If not confirmed: Formulate new hypothesis or redefine problem.

---

Why This Approach Works

Comparison with Continuous Discovery:

Continuous Discovery isn't wrong – but it's not practical for regulated environments. The 3-step process delivers validated decisions before compliance effort arises.

Suitable for:

• Teams in Gematik, BaFin, or OZG projects
• Product managers under time pressure
• Organizations without established discovery culture

---

Summary

Total: 2-3 weeks instead of months-long discovery cycles.

In regulated environments, what matters isn't how often you iterate. What matters is knowing what you're building before you build – and why.