My title is Staff Product Researcher. But I initiated this work, shaped the product opportunities, and took on product responsibilities well beyond a typical research scope. This page is my case for that.
The context
SonarQube CLI 1.0 was a 0-to-1 product with no prior research, no established playbook, and no clear answer to the most important question: what should we actually build? As AI-native workflows took hold, the stakes got higher. If the CLI didn't fit how developers worked, it risked being bypassed entirely in favor of tools that did. I initiated and led the discovery from scratch.
Results at a glance
800+
Active enterprise customers
At launch
0 → 1
Built from scratch
No playbook, no prior research
3
Product opportunities
Surfaced from research
1 shipped
At General Availability
Remediation agent via terminal
The friction
- No baseline existed for what developers needed from a Sonar CLI, let alone one integrated with an LLM.
- The competitive landscape was moving fast. Tools like Cursor and GitHub CLI were raising developer expectations around AI-native command-line experiences.
- Without clarity on what to build, there was a real risk of shipping a CLI that developers would route around entirely. How can we build an initial experience that lands with users and also gives us an edge in the market?
The window was narrowing
Competing tools were moving faster on LLM integration. If Sonar didn't establish the CLI as the quality layer in AI-native workflows quickly, developers would route around it entirely.
What I found
- Three key developer outcomes were underserved. I validated against a previous research I did using Jobs To Be Done (JTBD) framework with 150 Sonar users and discussed directly with the Group PM and Engineering Manager to drive prioritization decisions.
- The three underserved outcomes weren't obvious. They only emerged from mapping how developers actually move between their IDE, agent + terminal, and PR workflow. One was already addressed by the Remediation Agent shipping via terminal. The other two remain in progress — specifics are intentionally withheld as they relate to unreleased roadmap.
- Developers weren't just using the CLI as a convenience. For many, it was the primary interface for integrating Sonar into their pipelines.
The decisions this enabled
- Gave the team evidence to prioritize introducing the Remediation Agent into CLI. This shipped at General Availability 🎉
- Grounded the CLI roadmap in real developer workflow questions: command language, discoverability, LLM integration, and how to build a repeatable user feedback loop.
- Positioned the CLI not as a standalone tool but as a critical surface for Sonar's presence in AI-native developer workflows.
- Built a live FAQ page with Claude so customer-facing teams consistently answer CLI product questions, which was later included in internal sales enablement resources and also part of official CLI documentation.
Risks and tradeoffs
- Prioritization under uncertainty: Only one of three opportunities could ship at GA. We made the right commercial call — but we shipped into a competitive window with incomplete signal on whether the sequencing was right. It's about balancing velocity with perfection: pick up early signals, take a bet, execute and measure impact to course-correct.
- Measuring value without revenue: CLI is a free tool. Commercial impact can’t be tied to direct revenue. Success has to be measured through adoption breadth, pipeline influence, and downstream product engagement. That’s a harder story to tell, and it’s one we’re still figuring out.
What stayed human, and why
Deciding which of the three opportunities to ship first was a judgment call, not a data call. The research surfaced the gaps and validated them. But the prioritization decision required weighing competitive urgency, engineering feasibility, and commercial impact simultaneously.
Result: Remediation agent shipped via terminal at GA · 800+ active enterprise customers · Remaining 2 opportunities lined up for H2 2026, one currently in development
If I ran this again…
- Start the JTBD validation earlier. I used existing research as a foundation, but running CLI-specific jobs interviews before competitive analysis would have sharpened the opportunity framing faster.
- Pressure-test the sequencing of the three opportunities with engineering earlier. We landed on the right first bet, but the conversation happened later than it should have.