The gap between what user research surfaces and what gets built
User research is one of the most consistently expensive activities in a product organisation. It is also one of the most consistently misused. Not because the research is bad. Because the path from finding to decision is broken in ways that are structural, not accidental, and that most organisations treat as a communication problem when they are actually a governance problem.
I have spent over a decade working in product and growth roles at major digital platforms. In that time, I have commissioned research, presented research, sat in rooms where research was being discussed, and watched research findings disappear without trace into the space between a discovery session and a sprint planning meeting. The pattern is consistent enough that I no longer think it is a people problem. It is a process problem. And the fix is analytical, not interpersonal.
This essay is an attempt to name the mechanisms precisely and describe what closing the gap actually requires.
Why findings do not become decisions
The first thing to understand is that research findings do not fail to get implemented because nobody read them. They fail to get implemented because they arrive in the wrong form for the decision-making context they are entering.
A user research finding looks like this: ‘Users in the 35–50 age group express confusion at the point where the form asks for billing address separately from delivery address. Three of the five participants in the session attempted to skip this step.’ That is a legitimate research finding. It is specific, observed, and traceable to a session.
A product backlog item looks like this: ‘As a user, I want to complete my checkout without confusion so that I can receive my order.’ These are not the same thing. The finding describes a specific friction point with a specific mechanism. The user story describes a desired outcome at a level of abstraction that could be addressed by dozens of different interventions, or by none.
The translation from finding to backlog item is where most of the information content is lost. Not through negligence. Through a mismatch between the format research produces and the format that planning processes consume. Research outputs are typically qualitative, contextual, and causal. Backlog items are typically functional, abstract, and outcome-stated. Bridging those two formats requires explicit work that most organisations have not formalised.
The gap between what user research surfaces and what gets built is not a research quality problem. It is a translation problem. The findings are often correct. The mechanism for converting them into implementable decisions does not exist.
The three points where findings die
There are three specific points in most product processes where research findings stop moving forward. Understanding which one is responsible in a given organisation determines what the fix looks like.
The first is the handover. Research is conducted by one team (UX, research, or insight) and handed to another (product, engineering, or design) in the form of a report, a slide deck, or a session readout. The receiving team was not present for the sessions. They did not hear the tone of voice when a participant said they found something confusing. They did not see the hesitation. They received a document. Documents are easy to acknowledge and easy to deprioritise, because acknowledging is not the same as committing.
The organisations that avoid the handover problem do not solve it with better documents. They solve it by requiring the people who will make the implementation decision to be present, at minimum, for the synthesis session. Not the full sessions. The synthesis. If the product lead sits in the room when the research team says ‘the billing address step caused abandonment in three of five participants,’ the finding has a human observer attached to it. It is harder to deprioritise a finding you witnessed than one you read about.
Get Ammarah Ahmed’s stories in your inbox
Join Medium for free to get updates from this writer.
The second point is prioritisation. Even when findings are well-understood, they compete for backlog position against items that are easier to estimate, easier to scope, and more directly connected to a metric that someone is being measured on. A finding that says ‘mobile users are abandoning at the postcode field because the wrong keyboard type opens’ is correct and specific. But it does not come with a story points estimate or a revenue impact figure. It comes with a quote and an observation. Against a feature request that has a business case attached, it loses almost every time.
The fix here is not to make research findings more compelling. It is to require that findings be translated into a format that the prioritisation process accepts before they can be considered. If prioritisation decisions are made against an effort-impact matrix, findings need to arrive at that meeting with both an effort estimate and an impact estimate. The impact estimate does not need to be precise. It needs to exist. ‘If we fix this, we expect checkout completion on mobile to improve by X percentage points, based on the proportion of sessions where this step caused visible friction.’ That is enough to enter the prioritisation conversation. A quote from a user session is not.
The third point is accountability. Most organisations have no mechanism for tracking what happened to a research finding after it was shared. There is no system that records ‘finding F was surfaced on date D, entered the backlog as item I, was deprioritised at sprint planning S, and has not been revisited.’ Without that tracking, findings exist in a state of permanent ambiguity. Nobody is responsible for ensuring they are addressed. Nobody can report on the percentage of high-severity findings that were implemented within a defined time frame. The research function has no feedback loop on whether its output is generating value.
What closing the gap actually requires
Closing the gap between research and implementation is not a research methodology question. The research methodology may be fine. It is an organisational design question. The following three changes address the three failure points described above.
First: embed research observation into the decision-making role. This does not mean every product manager must conduct research. It means that the people who will decide whether to implement a finding should be present for the moment at which the finding is synthesised, not just the moment at which it is reported. In practice, this means replacing the research readout meeting with a joint synthesis session in which product and design stakeholders participate in organising and prioritising the raw findings before they are written up. What gets lost in the written report never existed in the joint session. The finding is already contextualised.
Second: create a finding-to-backlog translation layer with defined criteria. Before any research finding can be considered in sprint planning, it should pass through a structured translation that produces: a problem statement (what the user cannot do or finds difficult), an estimated impact (what percentage of users are affected and what behaviour is disrupted), an effort range (small, medium, large, validated with engineering), and a proposed success metric (how we will know this has been addressed). This is a one-page template, not a process burden. It exists to ensure that findings arrive at planning meetings in a form that can be compared to other backlog items on the same dimensions.
Third: track finding status as a first-class metric. High-severity findings (those affecting a significant percentage of users at a high-impact funnel stage) should be tracked with the same rigour as open bugs. They should have a status (identified, translated, in backlog, in sprint, implemented, validated), an owner, and a review cadence. The research function should report, on a regular cycle, on the percentage of high-severity findings that have been implemented within a defined window. If that number is consistently low, it is a product process problem, not a research problem, and it should be escalated as one.
The research function cannot fix this alone. And the product function cannot fix it by asking for better research. The fix requires a shared accountability structure that does not currently exist in most organisations.
The analyst’s role in closing the gap
Business analysts are well-positioned to own the translation layer described above. The skills required are already in the BA toolkit: structured problem decomposition, requirements translation, effort-impact analysis, and stakeholder facilitation. What is usually missing is the mandate to apply those skills to the research-to-backlog pipeline.
In practice, this means the BA role in a product team should include a defined responsibility for finding translation: taking research outputs and converting them into backlog-ready items with the full set of attributes the prioritisation process requires. This is not a creative interpretation of BA work. It is a natural extension of the requirements elicitation and analysis function into a domain that has been underserved by structured thinking.
The alternative, which is the current default, is that research findings are translated informally by whoever happens to be in the room, using whatever format feels right, with no consistency and no tracking. The output of that process is a backlog full of items that originated in research sessions nobody can trace, and a research archive full of findings that nobody implemented and nobody can explain why.
That is not a research failure. It is an analytical gap. And it is exactly the kind of gap that structured analytical practice exists to close.
Ammarah Ahmed is the founder of Precision Consulting, a CRO and UX practice for growth-stage e-commerce brands. She spent over a decade leading growth and product teams at Delivery Hero, Foodpanda, Talabat, and Daraz across MENA and Southeast Asia.
References: Krug, S. (2009). Rocket Surgery Made Easy. New Riders. Patton, J. (2014). User Story Mapping. O’Reilly. Nielsen Norman Group research on research-to-design translation: nngroup.com.
