How do you turn user research into product decisions?

Follow five links in order: evidence, pattern, insight, opportunity, initiative. Raw quotes are evidence; a repeated signal is a pattern; what that pattern implies about a customer's goal is the insight; the outcome worth improving is the opportunity; and only then do you pick an initiative. Each link should be traceable back to the one before it.

What is the difference between an insight and an opportunity?

An insight is an interpretation of what customers are experiencing — 'new customers cannot tell whether their file will be accepted before uploading it'. An opportunity is the outcome worth improving, stated so that several solutions could address it — 'new customers need a way to confirm their data will import before committing to it, so that setup does not stall'. Insights explain; opportunities point somewhere without naming the answer.

How should an opportunity be phrased?

Use the structure: [audience] needs a better way to [desired progress] because [evidenced obstacle], so that [valuable outcome]. Naming the audience stops it applying to everyone and therefore no one, the evidenced obstacle keeps it tied to data, and the outcome makes it possible to tell later whether it was achieved.

Why not go straight from a customer request to a feature?

Because a request is a customer's guess at a solution, filtered through what they already know your product can do. Building it satisfies the person who asked and frequently misses the underlying obstacle entirely. Working back from a request to the progress the customer was trying to make usually reveals a cheaper and broader answer.

How do you prioritise opportunities?

Score them on reach against the right denominator, severity when the obstacle is hit, strategic fit, and confidence in the evidence — and keep confidence visible rather than folding it into a single number. An opportunity that scores well on thin evidence is a candidate for more research, not for engineering.

From evidence to opportunity: the chain that ends in a decision

Five links sit between a customer saying something and a team building something. Most roadmap arguments are really disagreements about a link that got skipped.

Updated 19 September 20267 min readBy Karla Cruz, UX researcher

In short

Evidence → pattern → insight → opportunity → initiative. Each link has to be traceable back to the one before it. The expensive shortcut is jumping from a customer request straight to a feature, which builds one customer's guess at a solution and leaves the obstacle behind it untouched.

The five links

Evidence. Raw, attributable information: a support ticket, an interview quote, a behavioural event, a survey response, a churn reason, a sales note, a review. Evidence is always traceable to a source and never interpreted.
Pattern. A signal repeated across evidence, or rare but severe, or concentrated in one segment, or strategically meaningful. A pattern is still descriptive — it says what recurs, not what it means.
Insight. An interpretation of what the pattern suggests about a customer's job, unmet need, obstacle or motivation. This is the first link that is not directly observed, so it is labelled as an inference.
Opportunity. A customer or business outcome worth improving, phrased without prescribing a solution so that several approaches can compete for it.
Initiative. A specific thing you might do about it — a feature, a pricing change, an operational fix, a piece of content, or another round of research. The first candidate, not the conclusion.

The value is in the order. Every link is checkable against the one before it, so a disagreement can be located rather than argued in general terms. When someone objects to an initiative, the useful question is which link they doubt — the count, the interpretation, or the outcome you chose to pursue.

Worked through

Evidence. Forty-one support tickets and seven of the nine interview participants who reached the import step describe abandoning setup there.

"I had the file ready, I just couldn't tell if it wanted the raw export or something I was supposed to reformat first. I closed it and meant to come back."

Pattern. Setup abandonment concentrates at data import, and specifically around not knowing whether a file will be accepted. It is repeated, it is severe — these are customers who never reach first value — and it is concentrated among accounts migrating from a competitor.

Insight (an inference). Customers are not failing to import. They are declining to try, because the cost of a failed attempt is unknown and they have no way to check first. The obstacle is uncertainty, not capability.

Opportunity. Customers migrating from another tool need a way to confirm their data will import correctly before committing to the upload, because they cannot tell which formats are accepted and abandon rather than risk a failed attempt, so that they reach a working account in their first session.

Initiatives — several, competing. A dry-run validator that reports what would happen. A preview of the first ten parsed rows. Accepting the competitor's native export format directly. Or no feature at all: a worked example on the import screen, which is a day of work rather than a quarter.

Note what the chain bought. Had the team jumped from the tickets to an initiative, they would have built a better error message — a fix for the failed attempt nobody was making.

Why the phrasing of an opportunity matters

The structure is load-bearing:

[Audience] needs a better way to [desired progress] because [evidenced obstacle], so that [valuable outcome].

Audience stops it from applying to "users" and therefore to nobody in particular.
Desired progress is what the customer was trying to achieve, not what they asked for.
Evidenced obstacle is the link back to the data. If you cannot fill this in, you have a hypothesis.
Valuable outcome is what makes it possible to say afterwards whether it worked.

What breaks when a link is skipped

Evidence straight to initiative. The feature factory. One loud customer's suggestion becomes a roadmap item, and the underlying obstacle survives the release.
Pattern straight to initiative. Solving the symptom. Forty-one tickets about import become a better error message rather than a way to avoid the error.
Insight straight to initiative. The first solution wins by default, because no opportunity was stated for alternatives to compete against.
Opportunity with no evidence. A well-phrased opinion. These are the hardest to catch, because they read exactly like the real thing.

Prioritising the opportunities

Once several opportunities exist, they compete on four dimensions: reach against the correct denominator, severity when the obstacle is hit, strategic fit, and confidence in the underlying evidence.

Keep the fourth one visible rather than folding it into a composite score. An opportunity scoring highly on reach and severity but resting on four interviews is not a build decision — it is the clearest possible case for a week of targeted research. Collapsing confidence into a single number is how thin evidence gets laundered into certainty.

For getting reliable evidence in the first place, see customer feedback analysis and how to analyse user interviews.

Common questions

How do you turn user research into product decisions?: Follow five links in order: evidence, pattern, insight, opportunity, initiative. Raw quotes are evidence; a repeated signal is a pattern; what that pattern implies about a customer's goal is the insight; the outcome worth improving is the opportunity; and only then do you pick an initiative. Each link should be traceable back to the one before it.
What is the difference between an insight and an opportunity?: An insight is an interpretation of what customers are experiencing — 'new customers cannot tell whether their file will be accepted before uploading it'. An opportunity is the outcome worth improving, stated so that several solutions could address it — 'new customers need a way to confirm their data will import before committing to it, so that setup does not stall'. Insights explain; opportunities point somewhere without naming the answer.
How should an opportunity be phrased?: Use the structure: [audience] needs a better way to [desired progress] because [evidenced obstacle], so that [valuable outcome]. Naming the audience stops it applying to everyone and therefore no one, the evidenced obstacle keeps it tied to data, and the outcome makes it possible to tell later whether it was achieved.
Why not go straight from a customer request to a feature?: Because a request is a customer's guess at a solution, filtered through what they already know your product can do. Building it satisfies the person who asked and frequently misses the underlying obstacle entirely. Working back from a request to the progress the customer was trying to make usually reveals a cheaper and broader answer.
How do you prioritise opportunities?: Score them on reach against the right denominator, severity when the obstacle is hit, strategic fit, and confidence in the evidence — and keep confidence visible rather than folding it into a single number. An opportunity that scores well on thin evidence is a candidate for more research, not for engineering.

Run this analysis on your own evidence

Upload interviews, tickets, survey exports or reviews and humsait reads all of it, groups the patterns, and writes the report with every finding linked to the quotes behind it.

Try it free