How to Run Software Product Discovery in Fintech Without Breaking Compliance

You're a UX researcher at a fintech startup. Legal just rejected your plan to record customer interviews because the conversations might reference account balances, and that triggers PII handling requirements under your SOC 2 controls. Your PM needs discovery insights by end of month. The compliance team is not budging. This is the reality of software product discovery in regulated financial services, and it demands a different playbook than what works at a consumer app. Mastering software product discovery under these constraints is what separates effective fintech UX teams from frustrated ones.

The Problem: Discovery Friction in Regulated Environments

Fintech UX researchers face constraints that most product discovery guides ignore. Customer data is classified. Screen recordings may capture sensitive transactions. Even scheduling a user interview requires legal review if the participant is a banking customer covered by Gramm-Leach-Bliley Act protections. These constraints don't make discovery impossible; they make sloppy discovery dangerous. For a broader overview of the discipline, see our guide on how to do product discovery.

Step 1: Build a Compliance-Approved Research Protocol

Before your first interview, create a research protocol document and submit it to your compliance officer. Include: data handling procedures (where recordings are stored, retention period, access controls), participant consent language (reviewed by legal), and a list of prohibited discussion topics (specific account balances, transaction details, personal financial information). Getting this approved once creates a reusable template for all future software product discovery sprints. This step maps directly to the discovery phase of product development where foundational processes get established.

Step 2: Recruit Through Compliant Channels

Don't pull participant lists from your production database. Instead, use one of these three approaches:

• Opt-in research panels. Add a "Participate in Research" toggle to your app settings. Users who opt in have given explicit consent, simplifying legal review.
• Third-party recruitment. Platforms like UserTesting, Respondent, or User Interviews recruit participants who match your criteria without exposing your customer data.
• Internal dogfooding. Interview your own operations, compliance, and support teams. They use the product daily and can identify friction points without any PII risk.

Step 3: Conduct Insight-Rich Sessions Without Screen Recording

When recording is restricted, adapt your methods:

• Think-aloud protocols with note-takers. Have two researchers present: one helping, one capturing verbatim quotes and behavioral observations in real time using Dovetail or a shared Google Doc.
• Task-based usability tests on synthetic data. Build a staging environment with realistic but fabricated financial data. Participants interact with the product naturally while no real PII is on screen.
• Card sorting and tree testing. Use OptimalSort or Maze to test information architecture remotely. These methods generate structured data without capturing any financial information.

Step 4: Synthesize Using the Atomic UX Research Model

Tag each insight at the atomic level: one observation, one interpretation, one recommendation. Store these atoms in a research repository (Dovetail, Notion, or EnjoyHQ) tagged by user segment, product area, and discovery sprint. Atomic research compounds over time. By your third sprint, you will have a searchable database of evidence that makes prioritization arguments dramatically more persuasive. Tracking key metrics for discovery alongside your atomic insights gives you both qualitative depth and quantitative rigor.

Step 5: Present Findings with a Compliance Narrative

When presenting discovery findings to stakeholders, frame insights without quoting identifying details. Instead of "Customer Jane at Apex Financial said she can't find the wire transfer confirmation," write "A compliance officer at a mid-size wealth management firm reported difficulty locating transaction confirmation screens." This anonymization is not just best practice; it's a SOC 2 requirement for many fintech companies.

Step 6: Connect Insights to Delivery Through Opportunity Scoring

Score each validated opportunity on three dimensions: user impact (1-5), compliance risk of the proposed solution (Low/Medium/High), and engineering effort (T-shirt size). Present these scores to your PM as a prioritized backlog. Compliance risk as a scoring dimension is unique to fintech and ensures you never greenlight a solution that legal will later block. For SaaS companies, these scored opportunities are the stepping stones toward achieving product market fit for SaaS.

Pro Tips

• Rotate your staging data quarterly so it stays realistic without becoming stale.
• Invite a compliance representative to one session per sprint. Their firsthand exposure to user struggles builds empathy and accelerates future approvals.
• Document every protocol decision. If an auditor asks why you handled research data a certain way, your documentation is your defense.

Common Mistakes to Avoid

1. Running discovery without legal pre-approval. One recorded session with visible PII can trigger an incident report.
2. Using production data in usability tests. Always use synthetic or anonymized datasets.
3. Presenting raw quotes with identifying details. Anonymize everything before it leaves the research team.

Conclusion

Software product discovery in fintech requires more preparation than in unregulated industries, but it produces more defensible results. Build your compliance protocol once, recruit through approved channels, adapt your methods for restricted environments, and present findings with anonymized evidence. Adopting continuous product discovery practices ensures these habits compound over time. UX researchers who master this software product discovery workflow become indispensable to fintech teams that need to move fast without triggering regulatory risk.