From one link in the chain to a closed loop

SalesQL's core product was a browser extension that let recruiters, sales, and marketing professionals reveal contact data (emails, phone numbers) directly from LinkedIn profiles, searches, and lists. It was fast, reliable at what it did, and had a loyal user base across the US, UK, and Argentina.

I ran a structured round of user interviews to understand how people actually used the extension day to day — their habits, frustrations, and unmet needs. What started as a usability-focused study ended up surfacing something bigger: a structural weakness in how the product fit into its users' workflow.

What the interviews were built to find

The study targeted paying users with at least 180 days of tenure and recent activity, split evenly across three primary roles — recruiting, sales, and marketing — and across three regions. The goal was a representative cross-section of active users, not just power users or new signups.

In practice, recruitment fell short of the target — 11 completed interviews against a goal of 21 — a common reality of early-stage startup research operations rather than a deliberate sampling decision. I treated the resulting sample as directional, not saturated, and read the findings accordingly.

The pattern that kept repeating: SalesQL as one link, not the destination

Across every interview, regardless of role or region, the same structural pattern appeared: users arrived at SalesQL from LinkedIn — a profile, a search, a pre-built list — used it to reveal contact data, and then left immediately for another tool to actually act on that data: a CRM, an email platform, a spreadsheet.

Not a single interviewed user managed their outreach process inside SalesQL. The product was, in every case, one link in a longer chain — never the destination.

Reading the pattern as a competitive risk, not just a UX gap

This finding could have stayed at the level of "users want more integrations." Instead, I connected it to a hypothesis about competitive positioning: if SalesQL only ever handled the reveal step, and users had to leave the product to close the loop, then any competitor who closed that loop — capture, reveal, and outreach in a single tool — had a structural advantage that no amount of UI polish inside the extension could offset.

A second, independent finding reinforced the same underlying fragility. Several users described real anxiety around LinkedIn account bans tied to their automation activity — using personal accounts for work, having no clear signal of what actually triggered a ban, and building manual workarounds to cope (one user had built her own informal rate-limiting ritual, logging every batch of profile reveals by hand to stay under a self-imposed safety threshold). That wasn't a UI complaint either — it was users managing risk that the product itself wasn't designed to help them manage, because the product depended entirely on a single external channel it didn't control.

Two separate findings, one structural read: dependency on a single external platform, at both the input and output ends of the workflow, was the real constraint on the product's competitiveness — not a missing feature here or there.

From hypothesis to product direction

I brought this reading to the founder and stakeholders, alongside a competitive benchmark of tools that already closed the full loop — capture, enrichment, and outreach — inside one product. That benchmark, combined with the research, shaped the direction for three initiatives:

• A public API, to reduce the friction of integrating SalesQL data into whatever tool users were already leaving for — addressing the "one link in the chain" problem without forcing users to abandon their existing workflows.
• Prospector, letting users search for and surface leads directly within SalesQL rather than depending exclusively on LinkedIn as the only entry point — reducing exposure to the account-risk problem at its root.
• Campaigns, with Gmail integration, to let users send outreach and follow-up sequences directly from SalesQL — closing the loop on the output side, the step every single interviewed user had been leaving the product to complete.

My role in defining what shipped

Research didn't hand off to a separate product team here — I stayed involved through definition. For both Prospector and Campaigns, I ran competitive benchmarking against comparable tools in the market to understand what an MVP needed to include versus what could wait, and worked directly with the founder and stakeholders to scope each feature's first version.

Designing the product

As the only designer, I also owned the interface across the product: the Chrome extension, dashboard, onboarding, pricing page, Teams, API integrations, contact list and a new collapsible navigation.

Reading the numbers

Over twelve months, active subscribers fell by around 15% while churn stayed stable. The real problem was upstream: free-to-paid conversion was down 26% on the previous period. Several pricing and plan changes, including a pricing page redesign, had shipped in the same week, so their individual effects could not be separated. I proposed tightening a free plan that gave away too much value, and sequencing future pricing changes behind A/B tests so each one could be measured.

Outcome

Prospector and Campaigns shipped and were adopted by existing users. Product instrumentation at the company was limited at the time, so I don't have precise quantitative adoption metrics from that period to cite here.

What I can point to with confidence is the throughline: a usability-focused research round surfaced a structural pattern, that pattern was reframed as a competitive hypothesis, and the hypothesis directly shaped a three-part product direction — API, Prospector, and Campaigns — that I helped scope alongside the people who owned the roadmap. It's the clearest example in my work of research functioning as a strategic input, not just a usability check.