Insights at the speed of a deal

Insights reports were not back-office artifacts. They were how teams sold, upsold, and proved value.

Every report was a request, and every request was a wait

Sellers and customer success managers used audience insights to win business and to defend renewals. But producing one 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 confidence, and a powerful tool they could not use would only add one more broken step before they went back to the data team anyway.

The question that shaped the project was never can we build it. It was will they actually use it.

We already knew who we were building for

Months before this feature reached the roadmap, I led foundational research across the platform's roles, mapping workflows, goals, and technical comfort. That included both sides of the bottleneck: the people waiting on reports, and the people being asked to produce them.

So when the project started, the team never had to ask who we were building for. The more useful question became: given what we already know about these users, what does the design have to be?

Different goals, one shared constraint. That translated into three design commitments: simplify the primary flow and lead with smart defaults; open with the client-ready story rather than the configuration screen; and treat the request as repeatable, because every "custom" ask was the same analysis with different inputs.

They didn't need new data, they needed it usable

Six discovery interviews reframed the opportunity. Users were not asking for a new analytics capability. The data already existed, the requests repeated, and the structure was the same every time. What they lacked was a way to get data they already had into a form they could put in front of a client, without waiting for someone else to build it.

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

The tool mirrored how users already thought

The most consequential research contribution was not a usability fix. It was architectural.

Users already pictured audiences, campaigns, reporting windows, and insights as one connected chain, not as separate reports. That mental model became an argument for reusing the platform's existing data objects instead of building an isolated data layer for the feature.

This is the difference between research shaping a screen and research shaping a system. Because users saw these as one chain, the team reused existing audience and campaign objects across related workflows rather than duplicating them.

When the funnel confirmed the finding

Five pre-launch usability sessions made the core flow shippable, clarifying platform-specific labels and strengthening defaults so configuration felt lighter than the task itself.

The sharper finding came after launch. With no baseline for a brand-new workflow, I built a measurement approach combining eight live 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 something that lived elsewhere in the platform, and come back. In the lab it read as a quibble. In live use, under deal pressure, it was where people abandoned.

Research across the whole lifecycle

What made this work was not 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. Adoption closed the loop.

Shipping was never the finish line

A feature can launch and change nothing. What made this project worth doing was that two groups of people who did not consider themselves technical chose to make it part of how they work, and kept choosing it after the novelty wore off.

That is a research outcome, not a product one. It came from knowing these users a year before the feature existed, from designing around their confidence rather than around the data model, and from measuring adoption as behavior over time instead of as a launch-week number.