Continuous research produces a steady stream of findings. Without somewhere to put them, they live in slide decks and half-remembered conversations, and the same problem gets rediscovered every few months.
An insight backlog fixes that, but only if it is structured so people can actually use it. For my MSc thesis I asked a twelve-person product team to design one from scratch and vote on the answers. Here is what they landed on, alongside what practitioners already doing this told me.
Write insights as actions, not observations
The top-voted answer, with four votes, was clear: insights should be listed as actions or recommendations, with the examples and statistics from the feedback that led to that conclusion attached.
This is a small change with a big effect. “Users struggled with the upload step” is an observation, and it sits in a backlog forever. “Let users drag files onto the upload area, because four of six participants tried this before finding the button” is something a team can pick up and do.
Keep the evidence attached. The recommendation tells people what to do, and the evidence is what convinces them to do it.
Classify every item
Also on four votes: classify each finding so you know what kind of thing it is. The team suggested categories like product improvement, service feature, or discovery topic, so that when business priorities shift you can filter to the work that matters now.
Two more structural points they voted for:
- Tag it to a specific feature or product, so the right team can find it (three votes).
- Keep positive, neutral and negative feedback, not just the problems (three votes). Their reasoning was good: understanding what already works tells you how to fix what does not.
Practitioners I interviewed added a second layer to this. They separated higher-level opportunities from smaller actionable items underneath them, so the backlog holds both the big themes and the specific fixes without mixing them up.
Give prioritisation a single owner
This produced the strongest single answer in the entire workshop, with six votes: priority should be assigned by the overall owner, based on business priorities, according to the category the finding falls into.
That is worth pausing on. The team’s instinct was not to prioritise by research severity, or by how loudly users complained. It was that someone accountable for the product should weigh findings against where the business is going.
The other prioritisation factors they voted for:
- What value does it add? (three votes)
- Product owners adjusting priority using their own data alongside the research (two votes)
- Impact against effort, cost to implement, how many people raised it, and the impact on whichever team would do the work
Problem statements before solutions
Two answers tied at five votes for how a backlog item becomes real work:
- The product owner decides whether a finding merits new work, and creates it accordingly.
- Focus on problem statements first, then solutions.
The second one is the discipline that keeps discovery honest. It is tempting to move an insight into the backlog already wrapped in a solution. Framing it as a problem statement leaves room for the team to find a better answer than the first one anyone thought of.
The team also suggested converting insights into recommendations (two votes), following a share-out with a workshop to agree actions, and setting a deadline with a named owner so items do not drift.
Put it where people will look
For location, the top answer with four votes was an easily navigable tool that business users and executives can use too. Not a research tool that only researchers open.
Practitioners named the tools they use in practice: Notion for documentation, Dovetail for research data, Jira where insights need to connect to delivery, and Miro for visual synthesis. Some teams used nothing more complex than a well-tagged spreadsheet, which is fine if people actually open it.
One idea from the workshop is worth flagging because it is unusual and genuinely good: once findings are refined and planned, publish the backlog somewhere users can see it, the way some companies keep a public roadmap or backlog wiki. Users then see their feedback landing, which feeds straight back into willingness to take part in future research.
Review it on a schedule
A backlog nobody revisits is an archive. The practitioners I interviewed reviewed theirs on a set rhythm, usually every quarter or every six months, specifically looking for themes emerging across sessions that were not obvious at the time.
This is where an insight backlog earns its keep. Any single interview gives you an anecdote. Twenty interviews reviewed together give you a pattern.
One warning
Do not let a pattern automatically become an opportunity. One participant put it well: if you see a pattern that something is broken, go and fix the flow. That is a bug, not an opportunity worth building a strategy around.
Insights should inform decisions, and they should line up with business goals. They should not quietly replace the thinking.
Further reading
- Teresa Torres, Product Talk. On opportunity solution trees and connecting research to outcomes. producttalk.org
- My MSc research. Read the case study
Next, read how to turn research insights into action or how to measure the impact of continuous discovery.
Based on my MSc thesis on continuous product discovery. The research is written up in the case study.
