From taking requests to setting the agenda

When I joined CHG, research only reacted. Product asked for an interview or a usability test, and researchers ran it. There was no intake and no way to tell a request that would change a roadmap from one that would confirm a decision somebody had already made. We had no baselines either, so things shipped and nobody knew if they got better.

The team was capable and motivated. The problem was structural. Without a system, research was always going to look slow to teams that wanted to move fast, and it was always going to struggle to show its value in terms leadership cared about.

The first change was a formal intake. Every request came through the same form: What decision will this inform? What happens if we skip it? How does it connect to a business outcome? It wasn't a gate. It just made the conversation happen up front instead of never.

From there we moved to what I call the intentional commitment: a regular message to stakeholders showing the five things research was working on, where each request sat, and why things were sequenced the way they were. When someone felt their request was moving slowly, the answer wasn't "we're busy." It was: here's the full picture, here's your request, here's what moves if we bump it up. That conversation is a lot easier when the queue is visible.

Running everything through Jira helped too. All product work already lives there, so tracking research tickets in the same place and tying them to product epics keeps research sitting right next to the decisions, not in a separate system nobody checks. When a PM opens an epic, the research tied to it is already there.

Teams that used to see research as a black box started understanding the tradeoffs. Once the work was tied to business and user outcomes, arguing about priority mostly stopped.

With the advancement of AI, the next bottleneck to rebuild was synthesis and documentation. We built a pipeline that runs on its own. A participant pool with automated recruiting meant studies no longer stalled waiting on scheduling. Session findings went straight into a Claude project that pulled the sessions together and wrote up what we learned. From there the write-up went two ways: into Confluence, which synced back to Dovetail to keep the research repository current, and into Jira, where it wrote tickets straight to the product team. No researcher had to touch any step.

The result was a 70% drop in the time from starting a study to sharing what it found. Researchers stopped spending their days on documentation and copying things between systems, and the repository stayed current as a side effect of doing the work rather than as a separate chore.

There were no experience baselines when I arrived. Nothing showed whether anything that shipped got better or worse. So we started running UMUX-Lite surveys at every major feature launch and every significant stage of the journey. The point was a picture of quality across the whole product over time, not any individual score.

The goal isn't to report that a feature went from 3.0 to 4.8 on a five-point scale, though that has happened. UMUX-Lite asks two questions: does the product do what you need, and is it easy to use. A score of 3.0 means people are struggling with one or both. A score of 4.8 means we're in good shape and can worry about other things. That difference is real, and it only exists because we measured before the redesign, not just after. Without the baseline, all you have is a before and after screenshot. With it, you have evidence.

Earlier in my time at CHG, Crazy Egg heat maps showed users weren't scrolling on landing pages. Seeing what people clicked and what they ignored led to reorganized pages and more conversions. The click data told us where to look, the research explained what was going on, and the pages changed. One A/B test added about 200 monthly leads, a 20.3% desktop lift at 98% confidence.

The same pattern played out on Locumstory. A navigation redesign my team researched shipped with all eight recommendations adopted. Crash Course page views rose 84 percent, total blog traffic grew about 15 percent, and the count of top-25 blog pages went from 13 to 18, measured before and after in Adobe Analytics. We brought it to the Monthly Business Review in business terms, not research terms.

On credentialing, a baseline survey showed 45 percent of providers found the application hard work to complete. That one number became the business case behind the Credentialing App Modernization program across Imaging Centers, Hospital, Licensing, Sales, and QA. The baseline did more than evaluate a feature. It created a program and a target to measure against.

Where the calendar could distort a before-and-after, my team controlled for it. The provider dashboard study compared the same five-month window from each year on completion rate, job-send visits, and document access, so the difference reflected the change and not the season.

The MBR came out of a conversation with my director. Leadership wanted a clearer view of what UXR, CX, and Journey Management were doing and why. Each month I ask the team to surface their most important work, we put it into a deck, and we present to executive and VP-level leadership.

It's not a pure metrics dashboard. It's a story: what we learned, what changed because of it, what's next. Preparing it every month forces the team to put the work in terms leadership understands instead of research terms. The confidence it's built in the research function is the kind that accumulates over time, not the kind that comes from one impressive study.

The reporting system behind the MBR is something I built and taught the team to use. All research work is tracked in Jira, with tickets, bandwidth, and timelines, so there's already a running record of what everyone is doing. Every two weeks, researchers pull from their Jira tickets to write a short update on their work. I built a Claude pipeline that takes those updates, matches them against the team's OKRs, and generates an HTML report showing how the work connects to the department's yearly goals. The report goes two directions: up to leadership as the MBR, and back to the team so everyone can see what they're working on and how it fits the bigger picture.

I built quarterly 360 feedback into the same system. Peer feedback lands in the same HTML file, next to my own notes on each person's growth. So every team member has a clear record of what they contributed and how they grew, ready to use in performance reviews. Nobody is trying to remember what they did six months ago. It's already written down and framed in terms the organization cares about.

When I'm the one reporting up, the artifact I bring is the Line of Sight: a live document showing how every initiative across UXR, CX, and Journey Management connects to XD Initiatives and CHG Strategic Goals. It's built for a VP who needs to scan the function in 90 seconds, not read a research report. Filter by function or initiative and you can see who is working on what and how it connects to strategy.

Some teams still think research slows them down. The answer isn't to argue about it.

When a team wants to move fast, the first response is: go to Dovetail and search. The answer isn't always a new study. Past research often covers the question already, and pulling an existing insight takes two days, not two weeks. When something genuinely has to be new, unmoderated studies in Maze can turn findings around in days. The message the team carries: we can move as fast as you need. Here's how.

There's no dramatic turning point in this story, and no single study that changed everything. The shift added up piece by piece: an intake that made priorities visible, baselines that made quality measurable, an MBR that gave leadership a window into the work, and a team that knew what to say when someone brought up speed.

The research team does more foundational work now than when I arrived. The systems freed them from being buried in recruitment, synthesis, and reactive usability testing.