Research That Ships

Good research dies in the handoff. You run a clean study, find something real, build the deck, and then it sits on a drive because acting on it needed a translator and nobody had time to be one. “Users are confused by the configuration flow” is both true and useless. It names a problem without committing to what gets built, or when, or how sure we are.

I stopped shipping findings a while ago. I ship decisions. What I mean is that my job isn’t finished when I know the answer. It’s finished when a product partner can act on the answer without reinterpreting it. In practice that means I write research until it’s build-ready: scoped like a PRD, with acceptance criteria and a prioritized backlog, and the risk we’re carrying stated plainly. The gap between what I learned and what we shipped should be as small as I can make it.

On VoiceConnect, our integrated voice product, I didn’t write up that telephony setup was hard. I delivered a tiered launch decision: what ships now, what risk we’re taking into GA, and what each later release has to clean up, in order. Informed confidence instead of hopeful shipping. The research wasn’t an input to the go/no-go conversation so much as it was the shape of it.

Supervisor Mobile worked the same way. The output wasn’t a persona deck. It was a See, Decide, Act framework that became the product architecture, plus a backlog with the success metrics — time to action, SLA risk, nudge engagement — written before engineering touched it. When research shows up already shaped like the next thing the team has to build, it doesn’t get filed. It gets built.

The reframe earns its keep

The most useful thing I do is usually not a new finding. It’s a sharper framing of a problem everyone assumed they already understood. Project Saral is the cleanest example. The team had lined up behind the idea that operators lacked the data to debug routing failures. They didn’t. The data was there; what was missing was a coherent account of what the system had decided and when. That shift moved the foundational platform requirement and changed what the roadmap prioritized over the next couple of release cycles. More data would never have gotten us there. It came from noticing the question people kept asking and realizing the product had no answer for it.

The unglamorous part

None of this runs without plumbing nobody finds exciting. I keep findings traceable from observation to ticket to release. After any real decision I send a recap, in writing, so the org remembers one version of what we agreed instead of five. I think of the role as a bridge between user evidence and the calls a team has to make under pressure, the person making sure the right signal lands on the right desk at the right moment.

That’s the whole thing, and it fits in a sentence I keep taped to the inside of my head: research worth doing is research someone ships. The rest is just documents.