Case Study - Establishing Research Infrastructure for a Product Team in the Dark

How I set up the discovery foundation process model, measurement framework, and synthesis approach, so a newly formed product team could move from reactive to strategic.

Client: Operational services company powered by internal platforms and tools
Service: Enterprise UX Research & Discovery Infrastructure

Overview

A newly formed product team was responsible for improving a business-critical operational review process. They had high-level KPIs, operational user complaints, and tool backlogs, but couldn't prioritize confidently because the process's complexity made it impossible to identify bottlenecks and their importance.

My role: Establish the discovery infrastructure so the team could move from reactive to strategic.

Abstracted view of a globe with indicators showing the positions of the offices and the amounts of users per office

Operational users across offices: 150+
Internal and external tools in use: 30+
Revenue managed per cycle: $10M+

The Gap

The team had pieces, but no one connecting them.

Who	What they owned	What they couldn't do
High-Level Stakeholders	Strategic direction, investment decisions	Connect strategy to operational reality
Product Team	Individual tool backlogs	See cross-tool patterns or process impact
BI Analysts	Outcomes (throughput, revenue)	Tie numbers to specific steps and tools
Operations	Process knowledge and deficiencies	Translate to product priorities

Process diagram showing the end-to-end workflow with phases — Before structured discovery, knowledge lived in dense docs, overlapping PRDs, and edge-case-heavy diagrams that worked as reference but failed as a shared mental model.

What I Established

Three steps that turned fragmented insight into a decision-ready system.

1. The Process Model

A shared baseline for understanding how the work actually flows end to end.

Problem: Previous attempts stayed at the high-detail level and could not surface the underlying logic of the process.
Decision: Establish a core, logic-based process map to serve as a shared baseline for understanding the system and aligning all subsequent research.
Output: A baseline process model showing the logic of the work and where tools fit. What looked like many processes was one core flow adapted to different constraints.

This model was built through JTBD interviews and shadowing with experienced users, combined with thematic analysis of technical documentation and training material.

2. The Measurement Framework

A way to surface where the real pain points lie from users’ perspectives.

Problem: The process model explained how the work functioned, but not where breakdowns were concentrated or how widespread they were.
Decision: Use two separate surveys, one focused on process phases and one on tools, to surface patterns of friction in an efficient way that avoids survey fatigue.
Output: Directional signals such as Friction Index, Cognitive Load, and Coordination Score, revealing where friction accumulated across users and offices.

Survey structure diagram showing modular, repeating blocks for process and tool surveys — Surveys followed the process map: the process survey evaluated each step, while the tools survey evaluated the tools used within it. a) Section heading. b) Repeatable scalar questions. c) Comment section.

3. The Connection Layer

The final step connected the process model and measurement framework into a single decision layer. By evaluating each process step through both experience signals and tool performance, the team could determine whether observed friction was driven by existing tools or pointed to a gap in the process itself. This made tradeoffs explicit and gave the team a clear way to decide which areas warranted deeper, problem-specific discovery.

Process Step Discovery Decision Path (abstracted). Example showing how signals from a single process step were evaluated to decide whether it warranted a high-priority problem-specific discovery.

The Handoff

Presented to CPO, VP of Operations, multiple departments, and operational support teams. Operational leads showed live examples alongside the process visualization.

What shifted

Context for the first time: Problems could finally be placed within the end-to-end process
Quick fixes surfaced: Issues people had wanted to raise for months turned into ad-hoc collaboration initiatives
Shared issues identified: Different departments could now see where their concerns overlapped

"This is the first time I can see this large process clearly."

Stakeholder reaction during presentation

What Changed

Shared reference point: A single process view teams could use to discuss issues and priorities.
Qualitatively informed planning: Annual planning incorporated qualitative signals from operational users alongside existing quantitative inputs.
Repeatable research process: A lightweight research process that consistently connected operational insight to product decisions.
Cross-team collaboration: Several cross-functional initiatives launched from shared visibility into root causes.

Reflection

Two things I'd do differently:

Solution sketching earlier. Not to jump to answers, but to show what "solutions informed by this map" could look like. Would have built momentum during foundational work.
Frame as business process from the start. "Design" can be undervalued. Positioning this as business infrastructure, like operations or finance set up would have earned faster recognition.

Follow us