From First Researcher to a Team of Five

The context

When I joined Sonar in October 2021, there was no product research function. The company was successful but product decisions were being made without a systematic way to bring user insight into the process. I was hired as the first researcher, and in that first year I built the ops, the processes, and the research program that gave the organization its first structured view of how users experienced the product.

Results at a glance

20+

Discovery cycles in year one

Across three products

56%

Usability improvement

Upgrade flow · 92/100 task score

10

Designers and PMs coached

Research methods and study design

The friction

The opportunity wasn't that the company was making bad decisions — SonarSource was already successful. The gap was that there was no infrastructure to make user insight a repeatable, systematic input to product decisions. As the product scaled and the team grew, that gap was becoming harder to ignore.

What I built — and what it produced

Research ops and infrastructure — year one

In my first year I built the research ops from scratch: templates, processes, study frameworks, and the continuous discovery practices that gave teams a way to run research independently. I ran 20+ customer discovery cycles across three products and produced the research infrastructure that the organization built on.

I want to be honest about scope here: what I built in year one has been significantly evolved by the full team over the past three years. Each domain now operates differently based on what their researcher and their squads need. The ops I established were the starting point — not the finished state.

The benchmarking program

The standout initiative from my first year was the usability benchmarking programme.

💡

I identified the opportunity, pitched it to the CPO, got buy-in, and ran it from scratch. No playbook, no prior benchmarking program at Sonar.

⬇️

Before (2022): Upgrade flow was the worst performing task in the product. Users couldn't find the entry point, spent nearly a minute just trying to start, and had no visibility into what they'd gain by upgrading.

I brought the findings to the PM and designer with specific recommendations. The team iterated. In 2023 I re-ran the study against the same metrics.

After (2023): Upgrade flow went from worst to best performing task — scoring 92/100, a 56% usability improvement.

Building the team and scaling capability

The research function grew from one to five researchers over three years. I was hiring manager for two of those hires, and I introduced a whiteboard exercise to the hiring process — a way to evaluate how a researcher handles a problem in a short time window. This was subsequently adopted across UX hiring for design as well.

I also co-ran a one-off Research 101 course with a colleague to build moderated research skills across the UX Design team, and provided guidance to 10 designers and PMs in study design, evidence-based decision-making, and research methods.

The decisions this enabled

  • Gave the organization its first structured view of how users experienced the product — creating a shared baseline for what "good" looked like and where the biggest gaps were.
  • The benchmarking program directly drove the redesign of the upgrade flow, contributing to improved free-to-paid conversion.
  • The research ops and templates I built in year one gave teams a way to run discovery independently — reducing bottlenecks and increasing research throughput as the organization scaled.
  • The whiteboard hiring exercise I introduced changed how the organisation evaluated research and design candidates — a small intervention with lasting impact.
⚠️

Risks and tradeoffs

  • Building before knowing: Year one required making decisions about what to build before I had a full picture of what the organization needed. I worked hard to build relationships across stakeholders. Some of what I built still had to be revised as the team grew and domain needs diverged. That's the nature of being first.
  • Advocacy without data: When making the case for the benchmarking program or for hiring more researchers, I was operating on qualitative signal and judgment. Management saw the value, which made advocacy easier. But the absence of a systematic way to measure research impact made some of those conversations harder than they needed to be.

Result: Research function established from zero · 56% usability improvement on upgrade flow · 20+ discovery cycles in year one · Research 101 co-delivered · 10 designers and PMs coached · Whiteboard hiring exercise adopted team-wide

If I ran this again…

  • Instrument the research program's own impact from day one. I could tell qualitatively that research was changing decisions, but I didn't have a systematic way to measure it. That made it harder to make the case for resources when it mattered most..