Research that changes the roadmap, and research that does not

Most product research is confirmatory. It is commissioned after the decision, sized to the timeline of a build already underway, and its findings arrive as refinements: this label is confusing, this step has too many fields. That work is worth doing. It is also incapable of changing anything structural, and it is often presented as though it could.

The distinction we now make with clients before anything starts is simple and slightly rude. What finding would cause you to cancel this? If there is no answer, the research is a polish activity and should be budgeted, scheduled and named as one. If there is an answer, we write it down, and it becomes the thing the study is actually designed to test.

On a banking product this produced a question the client had never asked: how many people open the app with no intention beyond checking one number. The answer reorganised the home screen and killed two features that were mid-build. That study cost eight weeks and was the cheapest part of a two-year engagement, but only because we ran it before the roadmap hardened, when cancelling was still a normal thing to do rather than an admission.

The mechanism that makes this work is not method, it is timing and standing. Research changes a roadmap when it happens before commitments, and when whoever ran it can say so to the person who owns the budget without it going through three layers of summary. We ask for both at the start, in writing, because asking later means asking for a favour.

The corollary is that we sometimes recommend against research. If the decision is already made, made irreversibly, and made for reasons that are not about users, a study will produce a document that everyone praises and nobody acts on. That is worse than nothing, because it teaches an organisation that this is what research is.