Research that ships

Nobody owned the route

A team owns an area. A study tests a screen. An experiment moves one number, and everything is measured on its own terms, inside its own boundary.

But getting a database into production, working out why latency spiked at 3am, moving off another vendor — every one of those crosses areas, teams and screens. Research organised by feature can tell you each piece works and still never tell you the route through them does.

Stakeholders get a vote — and a bigger one they don't know about

Traditionally the stakeholder session is where scoring happens: each person walks the route and rates it, step by step. I kept that, for a reason with very little to do with the score. One of the program's goals was to get the whole organisation engaged in user experience research and decisions, and there is no faster way to make a VP care about a step than to have them walk it and put a number on it themselves.

So stakeholders influence the result twice, through two different doors — and a stakeholder's real leverage turns out not to be the number they wrote down, but how much they noticed. The mechanism rewards attention rather than opinion, from exactly the people who own the fixes.

The list stops being a research deliverable

A list of insights sitting in a research report is still a research report. The move that changes that is small, and it is the whole game: product managers add their own tickets to the insight list.

Each insight becomes a row with a ticket attached, filed by the person who owns the fix. Nothing about the research changed — but the list is no longer something research is asking product to read. It's a shared object product is writing into, and every item on it now has a name against it and a place in someone's backlog.

That's how the program recruited its own supporters. A PM who has put three of their own tickets against a journey's insights has a stake in that journey's next score, and will ask for it. Research stops chasing adoption and starts getting pulled.

What it ran on

Four critical journeys across the product: onboarding, monitoring & alerts, migration, billing.

Migration is the one that outgrew the report — the journey nobody could see whole, which became an interactive map. That chapter is further down this page.

Weekly — and an AI-written brief before every call

A weekly interview, with a product manager or the relevant stakeholder sitting in.

The outline for each conversation was generated with Claude Code before the call — from behavioural data on what this person does in the console, the CRM, a year of support history read for recurring trouble, sales calls and the open web. It injects two or three tailored probes underneath the specific questions they bear on, so the research rides on the outline where it becomes relevant.

Then the part that made it a system. A product manager's question went into my notes as an open task with its own relevance condition attached, and every prep run read that register and decided per interview. One asked about cost tooling on a Monday; by Wednesday a founder's outline carried it — a standing question multiplied by this person's researched reality.

The craft of counting churns

Two things had to exist before this section could: a survey worth trusting, and a way to read it at scale. The survey was flawed, so I redesigned it — The Redesign, its own chapter on this page. Reading it at scale needed a tool, so I built one — The Dashboard, and it didn't stay mine: people across the org use it too.

The redesigned survey, the dashboard, and an AI pass on top of both are what turned this into a monthly practice instead of a one-off pull. Together they gave me a real read every month instead of a glance, trends followed across editions instead of reconstructed from memory, and stakeholders pointed straight at the data that mattered to them.

Turning a purchased deliverable into a dataset

This one I didn't own, and the distinction matters. Win-loss at Redis was a vendor program run by product marketing: an external firm calls the customer-side buyer on deals that just closed — won and lost alike — and rates what drove the decision. Our research team was given access in late 2025, as guests of somebody else's program.

I connected to the program's API and put an AI agent behind it: for every deal, it joins the vendor's call to our own CRM, account discussion, sales calls and support history — and the support history is what changes the story. A lost expansion looked like a service-quality problem until the record showed support had proactively monitored their performance test months earlier. The deal stops being what one buyer remembers and becomes what actually happened between the two companies.

Nobody likes NPS

NPS (Net Promoter Score) gets dismissed a lot, and there's a real case for it — a single score doesn't tell you much on its own. What it's good for is trends, and that's mainly how I used it: the all-time line as the headline, with a significance test on every move, so a bad month couldn't be read as a story it wasn't.

But the comments did something the score couldn't: spotlighted single incidents worth telling the org about — a support ticket handled well, a sales relationship worth reflecting on — written up with whoever did the work credited by name. When an interesting company's story surfaced, I'd use it to tell the org who they are and what their business with us actually looks like. Naming people wasn't just kudos — it's what pulled them into reading a UX report they'd otherwise have skipped, and that's most of how the org's own sense of the product's UX state grew.

Nobody could say how many customers were leaving

The survey fired after the deletion. So it could answer a customer who said too expensive with a page about cheaper plans and a migration guide — addressed to somebody whose database was already gone. Everything it collected was a post-mortem and everything it offered arrived for a person who no longer existed.

It asked one question with sixteen answers in a flat list, and among them sat “I want to upgrade my database”, “create new subscription” and “I was using Redis as a proof of concept.” Those are not reasons for leaving. A deletion is often routine work — there was no way to move a database between plan tiers, so upgrading meant deleting and recreating — and the instrument was adding three different events together and calling the total churn.

And it had no denominator. A thin monthly trickle answered it; out of how many, nobody in the company could say. There was no agreed definition of a churn event at all. I chased that number for months and never found anyone who had it — which turned out to be the real finding. The survey wasn't asking badly. The organisation could not count the thing the survey existed to measure.

I couldn't even see the survey I was replacing

It started as archaeology. The live survey couldn't be found or reproduced, and both people who built it had left. So I tracked down a developer who still had it, got a JSON of its structure, and had Claude Code turn that into a working demo — which is how I finally saw what I was replacing.

The demo is what I did the work with. I walked product leadership, customer success, support, growth and design through it one at a time — people could click the survey instead of reading a document about it, and every session handed back something the design had got wrong. Customer success broke my screening question outright: customers call any Redis-compatible database “Redis”, so a question the respondent cannot answer correctly is not a question.

What I had specified first was elaborate — customer segments, a different intervention per segment per reason. The walkthroughs talked me out of it. Segmentation by customer value lives in a CRM and is wrong the moment the record goes stale; segmentation by intent is answerable by the person in front of you — are you leaving, running a proof of concept, or staying and changing something? That is the whole redesign, and it is one question.

When the users are lost

When the data stops answering

Put all three rounds on one axis and the shape appears. Round one to round two is a real lift — the five-group split being wrong, and being fixed. Round two to round three is flat: the last two were a dead heat.

So the choice between them wasn't statistical. Advanced features is a label defined by what it isn't — it ages the moment the advanced thing becomes ordinary. Services names what those things are, and stays true when the next one arrives.

Knowing when the evidence has stopped discriminating is part of the method, not a failure of it — so name the judgement as a judgement, and leave the record for whoever inherits the menu.

You cannot call a menu better without the menu it replaces

A card sort tells you what people expect, not whether they can find anything — and certainly not whether the new thing beats the old. Different claims, different instrument.

So validation ran as an A/B tree test — eight scenarios put to both the proposed structure and the menu already live, scored on arrival, then on ease and confidence.

Then the problem that made it interesting: the new structure held things the old one had no counterpart for, so there was nothing to test them against. Rather than fake a control I split the question — which is better where both can answer, can they find it at all where only one can.

The proposed structure came back significantly more intuitive than the one it replaced — not we think this is better, but both put in front of people who had seen neither, and this one won. Management / Services / Monitoring / Financial is what shipped, and it is what the console carries today.

What is migration, anyway?

Migration is an umbrella term: moving a user's database assets from one place to another. Every part of that definition is vague — what counts as an asset, what counts as the place they leave, what counts as the place they arrive. That vagueness is not an accident of phrasing. When I talked to stakeholders, nobody held the same boundaries for the word.

So the first deliverable was not a map. It was a definition — what a migration is, what its subtypes are, and what all of them have in common.

Untying a knot requires patience and persistence

No single source could describe the space — and the people closest to it did not describe the same space.

Product managers saw migration as a customer arriving from another vendor, wanting to move their data in. Support saw a customer changing how they pay, moving billing off a cloud marketplace and onto a credit card. Technical account managers and CloudOps saw an infrastructure process: a change to what the data is written to, rather than a move of the data at all.

All of these were documented, and all of them made sense. That is what made the knot worth untying rather than cutting.

Paths, steps and layers

The first cut was the paths, and there are two families. Path A is a customer arriving from outside — another vendor, another cloud. Path B is a customer moving between databases inside the platform, where nothing leaves.

Every path then runs the same four steps — cognitive units, not screens — and every step is made of three layers: data, infrastructure, control plane. Not every layer is relevant at every step of every path, which is why the map has empty cells, and why an empty cell is a finding rather than a gap.

The steps are where the sorting did its work. Most stakeholders I spoke to thought Execute was the whole of migration — the deciding, the preparing and the cutting over were somebody else's problem, or nobody's.

It is still in use

The map drove the scope decision for the next phase of migration work, and then kept going — which is the part research usually doesn't get. It became the shared reference for a journey the org had never seen whole.

Solo, end to end

Discovery, synthesis, design, agentic build, deploy — one person, no handoff, and no stage where the work had to wait for someone else's queue. That is the part I'd want a design lead to look at hardest: not that a researcher can ship an interface, but that shipping it kept the research intact.

I teach this workflow now.