Case Study · Research Operations × Product Strategy
Building decision infrastructure
How I helped move research from late-stage validation to a shared operating system for understanding users, aligning teams, and guiding product decisions.
Research shifted from reviewing solutions after decisions were formed to shaping problem definition, tradeoffs, and product direction earlier in the process.
7 journey maps
End-to-end workflow artifacts made cross-team seams, handoffs, rework loops, and ownership gaps visible across a complex platform ecosystem.
Shared measurement
Research readouts evolved from findings-only reports into decision tools connected to business goals, product KPIs, behavior metrics, and experiments.
The organization did not need more research reports. It needed a better way to make product decisions.
The challenge
Research was often brought in after a solution already existed. Teams had user questions, but lacked shared language, workflow visibility, and a consistent way to connect research to product and business outcomes.
My role
I built reusable research assets, introduced participatory rituals, mapped end-to-end workflows, and helped connect research questions to KPIs, analytics, and experimentation plans.
The shift
Research became less of a checkpoint and more of a product partnership model—a shared system for how teams understand users, learn together, and decide what to build.
NDA-safe visual · Research operating system
Layer 01
Shared understanding
Reusable personas created a common vocabulary for roles, goals, technical comfort, responsibilities, and platform touchpoints.
Layer 02
Shared context
Journey maps showed what happened before, during, and after each team's surface area—making seams and dependencies easier to see.
Layer 03
Shared learning
PMs, designers, and engineers participated in sessions, debriefs, and synthesis instead of only consuming final readouts.
Layer 04
Shared measurement
Research findings were connected to product KPIs, behavior metrics, experiments, and the decisions teams needed to make.
Result
Better decisions
The research function became decision infrastructure: not just producing insights, but creating the conditions for teams to act on them.
Recommended hero visual. This replaces confidential screenshots with a strategic model that communicates principal-level impact: research as decision infrastructure.
01 · The inherited modelResearch was being used too late
Research requests often arrived after a product team had already selected a solution. The ask was usually to validate whether an idea would land, not to understand the problem, compare opportunities, or shape what should be built.
The deeper issue was organizational. Different teams described the same users differently, workflow knowledge was fragmented by product area, and measurement was not consistently tied to user behavior or business outcomes. The work was not just to run studies—it was to build the operating model that made research useful earlier.
Symptom
Why it mattered
Research response
Research engaged after decisions
Limited the ability to influence product direction.
Moved research upstream through discovery, workshops, and decision-framed readouts.
No shared user vocabulary
Teams used inconsistent definitions for roles and needs.
Created personas that became reusable onboarding and planning artifacts.
Fragmented workflow knowledge
Teams optimized locally without seeing cross-team friction.
Mapped end-to-end journeys to expose handoffs, rework, and ownership seams.
Weak measurement connection
Research impact was hard to defend beyond findings.
Connected objectives to KPIs, behavior metrics, research questions, and experiments.
02 · Shared understandingCreating a common language for users
One of the first gaps was basic but consequential: teams did not always share the same language for users. The same role could mean different things depending on whether the conversation was happening in Product, UX, Engineering, Operations, or Customer Success.
I led foundational research to define major platform personas by workflow responsibility, goals, pain points, technical comfort, success measures, and platform touchpoints. The value was not the persona artifact itself. The value was a shared vocabulary teams could reuse in roadmaps, onboarding, design reviews, and prioritization conversations.
Research artifact
Persona system
Defined the major roles using consistent dimensions: responsibilities, workflows, goals, technical confidence, pain points, success measures, and platform touchpoints.
Why it matteredPersonas became shared language—not just research documentation. They helped teams discuss users with more precision and reduced ambiguity in product conversations.
Design implication
Build for real user capability
Role-level understanding helped teams avoid designing for an imagined expert user when the actual user needed clearer defaults, simpler flows, or more guided decision support.
Decision impactThe personas gave research a defensible way to influence design tradeoffs and challenge complexity before it became product debt.
Most teams understood their own part of the platform well. Very few had a full view of what happened before or after their part of the workflow. That created local optimization: each team could improve its own surface area while the broader experience still felt fragmented to users.
I created seven end-to-end journey maps using user discovery, PM working sessions, workflow analysis, and operational signals. The journey maps made invisible friction visible: handoff delays, unclear ownership, tool switching, rework loops, and dependencies across teams.
NDA-safe visual · Journey architecture excerpt
Plan
Visible seamUnclear inputs from upstream teams
Set up
Visible seamMultiple tools and repeated data entry
Launch
Visible seamApproval and ownership delays
Monitor
Visible seamSignals split across surfaces
Optimize
Visible seamManual interpretation and handoffs
Report
Visible seamRework loops before client delivery
Recommended artifact style. Instead of showing a full confidential journey map, show an abstract journey excerpt with generic stages and friction types. This communicates the thinking without exposing internal details.
Seven journey maps that showed the full workflow across teams, not just a single product surface.
How teams used it
As reference material for onboarding, roadmap conversations, opportunity framing, and cross-team alignment.
04 · Shared learningReplacing checkpoint research with partnership
The inherited model treated research as a request queue: a team arrived with a solution, research evaluated it, and the output was a report. That model created useful findings, but kept decision-making outside the research process.
The newer model made research participatory. Product managers, designers, and engineers joined sessions, debriefed immediately afterward, and participated in synthesis. The goal was not simply stakeholder buy-in. The goal was shared ownership of learning.
Operating model shift
Checkpoint model
Request arrives after solution
Research validates concept
Findings delivered as report
Decision stays outside the research process
→
Partnership model
Research starts with the decision
Stakeholders observe users directly
Teams debrief and synthesize together
Findings become product direction and measurement plans
Principal-level signal. This section shows that the impact was not only study quality—it was changing the way product teams learned and made decisions.
05 · Shared measurementConnecting research to business outcomes
To make research more useful to product and leadership, the work had to connect findings to the outcomes teams cared about. That meant moving beyond "what users said" and building a line of sight from business objectives to product KPIs, behavior metrics, research questions, and experiments.
This avoided overclaiming direct revenue attribution while still making research more accountable. The point was not to measure research activity. The point was to understand whether product decisions were improving user behavior and supporting business goals.
NDA-safe visual · Decision and measurement system
01 Business objective
What outcome does the organization need to improve?
02 Product KPI
What product-level signal would indicate progress?
03 Behavior metric
What user behavior should change if the solution works?
04 Research question
What do we need to learn to make a better decision?
05 Experiment
How will we test whether the decision changed behavior?
Recommended measurement visual. This is NDA-safe and strategic. It shows how research connects to business outcomes without claiming research alone moved revenue.
06 · What had to changeThe change management behind the work
Building a research function was not only about artifacts. It required changing habits: when teams involved research, how stakeholders participated, what counted as evidence, and how findings were translated into decisions.
Old habit
New practice
Why it mattered
Bring research in after solution selection.
Start with problem framing and the decision to be made.
Research could influence direction, not just validate execution.
Stakeholders read findings later.
Stakeholders observe sessions and join synthesis.
Teams built shared conviction faster and made better tradeoffs.
Reports centered on findings.
Readouts connected findings to KPIs, recommendations, and measurement plans.
Research became easier to act on and easier to defend.
07 · ImpactWhat changed in the organization
Shared user vocabulary
Personas gave Product, UX, and Engineering a more consistent language for roles, needs, workflows, and technical comfort.
Workflow visibility
Seven journey maps made cross-team friction visible and became reference artifacts for onboarding, planning, and alignment.
Research participation
PMs, designers, and engineers increasingly participated in sessions, debriefs, and synthesis rather than only receiving final outputs.
Decision-oriented reporting
Research readouts connected findings to objectives, KPIs, recommendations, and measurement plans.
Measurement foundation
Experimentation and analytics frameworks gave teams a clearer way to connect product decisions with user behavior and business outcomes.
08 · ReflectionWhat I would repeat
Three lessons from this work now shape how I approach research leadership in complex product organizations.
Takeaway 01
Build shared vocabulary before scaling research
Teams cannot align on product decisions if they do not share a clear language for users, roles, workflows, and success criteria.
Takeaway 02
Map end-to-end when ownership is fragmented
In complex organizations, the highest-value friction often sits between teams rather than inside any one team's product surface.
Takeaway 03
Make research participatory
Stakeholders make better decisions when they hear users directly and participate in synthesis, not just read findings after the fact.
Takeaway 04
Connect learning to measurement
Research impact becomes easier to defend when product teams can trace business objectives to KPIs, behavior metrics, and experiments.
For me, building a research function meant building the conditions for better decisions—not just better research artifacts.