Research often ends at the least useful moment. A team now has a credible account of where users struggle, yet the roadmap still contains the commitments agreed before anyone spoke to them. Knowing what happened and deciding what to do about it are two different jobs, and most research processes go quiet right at the point where the second one starts.
At Fortnight, we call the work between those two points translation. Good research frequently gets stuck there.
Suppose a findings deck says:
Six out of eight users abandoned signup when asked for payment details before seeing the dashboard.
The team could move payment later, add a preview mode, explain the product's value earlier, or accept the drop-off because it's optimising for qualified leads. Each option is defensible, and the finding alone doesn't pick between them.
That gap is where synthesis and strategy split. Synthesis makes sense of what was observed. Strategy weighs it against work the business has already committed to, and research evidence alone can't decide whether fixing onboarding matters more than the feature sales has been promising for two quarters. That call belongs to whoever can change the roadmap and accept the consequences, and the person who ran the research may hold that authority, although in many teams they don't.
When nobody inherits that authority, the report lands in a shared folder and waits. Everyone assumes someone else will turn it into a plan, which is usually just another way of saying nobody has.
Part of why nobody does is that what's sitting in the folder is often a theme, not a finding, and themes are nearly impossible to act on. "Users want more control" sounds convincing in a presentation, but nobody can design from it. A specific behaviour, observed at a specific point in the experience, gives the team something it can act on and measure again later.
Once the findings are clear, the team needs to discuss what it's prepared to change because of them. That's a prioritisation conversation. It rarely happens on its own, because nobody schedules a meeting specifically to argue about what the team is willing to give up.
We use a short translation statement to force it into the open. It has four parts.
FindingRecord the behaviour behind the theme. The team should be able to look for the same behaviour after making a change.
Writing that part down is the easy half. What people avoid is naming what the decision actually costs if the bet is wrong, so that's the part worth forcing next.
DecisionWrite down the change to the product. Words such as "maybe" or "we should probably" mean the options are still open, and a statement with either one in it isn't finished yet.
Once the decision is definite, the next question is what it costs to be wrong about it.
Cost if wrongState what the team is giving up to make the bet. This could be a feature moving to the next quarter, a smaller first release, or extra work in the billing system. Until the cost is named, the choice is still being discussed in isolation from the roadmap it will affect, which is how a reasonable-sounding decision becomes an expensive one before anyone notices.
That cost matters more or less depending on how easy the decision is to undo, which is the last piece.
ReversibilitySet the condition that would make the team reconsider and record how it could undo the change. A choice that can be reversed in one sprint can be made with less certainty than a six-month platform rebuild. An irreversible choice needs more evidence before work begins.
If the team chooses to move payment, this is what the decision looks like in writing:
FindingSix out of eight users abandoned signup when asked for payment details before seeing the dashboard.
DecisionMove payment collection to after the dashboard tour.
Cost if wrongThe billing sprint moves back two weeks. If drop-off persists, we will have delayed a revenue feature for a fix that missed the real problem.
ReversibilityRevert to payment-first in one sprint if conversion does not improve within 30 days.
Keep it short enough to sit alongside the roadmap item. Its job is to keep the evidence and the choice in the same place, with the cost visible to whoever approves the work.
Three users asking for the same obscure export format is a real finding. It doesn't tell you whether the problem affects three people or three hundred, and committing two weeks of development before you know the difference is still a guess, only now it has a ticket number.
Teams often act anyway, because an unused finding looks like wasted research. A premature feature is a worse way to prove the research mattered.
Use the watch list instead when the pattern is still weak or the cost of solving it is unknown. It also fits problems where nobody has a credible measure of what "better" would even look like. Each entry needs a reason to revisit it, such as five more support requests or a measurable drop in completion among a priority customer group, and without that trigger it just delays the guess instead of avoiding it.
In our work with the music-marketing platform unhurd, user research and feedback from its existing agency service showed where the product was asking too much of its audience. Musicians wanted to grow their reach. Conventional marketing platforms expected them to interpret the data like a marketer or analyst.
Simply making the analytics easier to read would still have left artists to interpret the numbers for themselves. The research pointed towards a different interaction: show people where they are and what to do next.
Artists needed to understand how to grow and promote their music without having to interpret conventional, data-heavy marketing dashboards.
Translate the data into a progression-based artist journey, showing artists their current status and what to do next through actionable insights and gamified tasks.
The core experience moved away from a conventional analytics dashboard. unhurd showed artists their place in the journey and the next action available to them, using the underlying data to guide progress instead of just reporting it.
That decision reshaped the product's core interaction. It wasn't a feature added on top. After launch, unhurd recorded 50% month-on-month active-session growth and 33% month-on-month app-download growth. Median conversion time was 2.4 minutes.
Our guide to what to research before building an app covers the questions worth answering that early, before a project gets anywhere near this stage.
A roadmap owner who wasn't in the room can dismiss a finding in the time it takes to skim the deck, which is exactly why the researcher needs to be in the decision itself, not just the readout beforehand. They can explain what was actually observed and challenge an interpretation that leans too hard on one memorable quote.
The final call still belongs to whoever is accountable for the roadmap. That might be a product lead, a founder or a researcher who also holds that authority. They are the person who has to live with the trade-off if the decision is wrong.
In practice, that means running the translation session immediately after synthesis, while the evidence is still fresh enough to argue about. The researcher clarifies what was seen; the roadmap owner decides what moves. Record the agreed statement and its owner before the session ends. A decision attributed only to "the team" is nearly impossible to revisit later because nobody is clearly responsible for defending it or changing it.
Not every finding will be strong enough to write a statement like that yet. When it isn't, use the next research round to dig into that specific uncertainty rather than repeating the original study. These 20 questions for user testing are a useful starting point.
Before a finding reaches the roadmap, check:
Any unclear answer shows where the decision still needs work.
Turn research into a product plan
We help product teams decide which findings deserve action, then carry those decisions into design.
.png)
