When Adoption Became the Business Case

For account executives and CSMs, insights reports weren't back-office artifacts. They were how teams sold, upsold, and proved value. But every report meant a custom request to the data team, which meant waiting at exactly the moments a deal needed speed.

The product team believed a self-service feature could break that dependency. The real risk was adoption: both primary user groups had low technical comfort. A powerful tool they couldn't use would just add one more broken step before they went back to the data team. So the question that shaped the whole project wasn't "can we build it," it was "will they actually use it." Adoption was the bet.

The dependency the tool had to break. Every report routed through the data team, turning a sales-moment need into a days-to-weeks wait. Self-service had to collapse the loop without losing the trust users placed in data-team output.

01 · FoundationWe already knew who we were building for

Months before this feature reached the roadmap, I'd led foundational research across platform roles (AEs, CSMs, traders, analysts, admins), mapping workflows, goals, and technical comfort by role. So when the project started, the team never had to ask "who are we building for." We knew. The more useful question became: given what we know about these users, what does the design have to be?

Two primary users, one shared need. AEs sell; CSMs retain and grow. Different goals, but both had low technical confidence and both needed client-ready insights fast, which made adoption, not feature depth, the design priority.

That foundation translated directly into design commitments: low technical confidence meant simplify the primary flow and lead with smart defaults; reports existing to support selling meant lead with the client-ready story, not configuration; and the fact that "custom" requests were really the same analysis with different inputs meant the need was repeatable, and could be systematized as self-service.

02 · DiscoveryThey didn't need new data, they needed it usable

Discovery interviews reframed the opportunity. Users weren't asking for a new analytics capability. The data already existed; the requests were repetitive; the structure was the same every time. What they lacked was a way to get the data they already had into a form they could put in front of a client, without waiting.

The team wasn't inventing a new analytics product. It was turning a repeated manual workflow into a self-service experience.

03 · ArchitectureThe tool mirrored how users already thought

The most consequential research contribution wasn't a usability fix. It was architectural. Users already pictured audiences, campaigns, reporting windows, and insights as connected objects, not separate reports. That mental model became an argument: reuse the platform's existing data objects instead of building an isolated data layer for the feature.

Research shaping the data architecture. Because users already saw these as one connected chain, the team reused existing audience and campaign objects across related workflows, a structural decision research drove, not a surface one.

04 · ValidationWhen the funnel confirmed the finding

Pre-launch usability made the core flow shippable, clarifying platform-specific labels and strengthening defaults so configuration felt lighter than the task. But the sharpest finding came after launch. With no baseline for a brand-new workflow, I built a measurement approach combining live usability sessions, a behavioral funnel, and week-over-week retention by role.

One step told the whole story. To continue, users had to leave the flow, retrieve data that lived elsewhere in the platform, and come back. In the lab it was a quibble; in live use, under deal pressure, it was where people abandoned. The qualitative friction and the quantitative drop-off pointed to the exact same step, and that convergence handed product a single, defensible next-quarter priority instead of a wish list.

Qual and quant, same step, same problem. Usability sessions and funnel analysis independently located the highest-friction moment in the same place, turning a broad "make it better" into one prioritized fix.

The impact

Adoption was the bet. New business was the proof it paid off.

The truest measure of adoption wasn't a usage count. It was that AEs and CSMs kept coming back, week over week, and folded the tool into how they actually sold. Adopted into pitches and upsells, it became a direct driver of new business in its first year. That's the business case: not that a feature shipped, but that two low-technical-confidence user groups made it part of how they win deals.

The before/after wasn't only speed, it was independence. Teams moved from waiting on the data team to generating client-ready insights themselves, in minutes, at the moment a conversation needed them.

From dependency to self-service. The same work that took days of back-and-forth became a self-service motion measured in minutes, and, just as important, in confident, timely client conversations.

05 · ReflectionResearch across the whole lifecycle

What made this work wasn't any single study. It was research carried across the entire arc, each stage compounding the last. Persona work done before the feature existed became the evidence behind its design. Discovery reframed the problem. Architecture research shaped what got built. Usability made it shippable. Post-launch measurement found the one fix that mattered. And adoption, measured in the business it drove, closed the loop.

Research wasn't a phase, it was the through-line. Embedded from foundational discovery to post-launch analytics, each stage fed the next, and the loop fed continuous improvement.

Foundational research compounds, mixed methods locate the truth, and the strongest proof of a research-built product is that people adopt it into the work that earns the business its money.