User interviews do not produce a roadmap. They produce evidence about goals, behaviors, constraints, workarounds and meaning. Product priorities emerge only after that evidence is connected to business context, technical reality and an explicit decision rule.
The most common failure is to jump directly from a memorable quote to a feature request. Traceability prevents that jump.
Use a five-level evidence chain
- Observation: what the participant said or did.
- Interpretation: what the evidence may indicate.
- Pattern: where the interpretation appears across cases or contexts.
- Opportunity: which outcome could be improved.
- Product option: one possible response to that opportunity.
Keep these levels separate in the research record. A product option is not a finding, and a participant’s proposed solution is not automatically the best response.
Code for the decision, not for decoration
Before analysis, return to the research questions. Create an initial coding frame around the behaviors and constraints relevant to the decision, while leaving room for unexpected categories.
For onboarding research, useful evidence units might include:
- trigger for starting the task;
- expected outcome;
- information required;
- point of hesitation;
- workaround;
- person or system that influences the choice;
- consequence of failure;
- evidence of trust.
Count alone does not establish importance. A rare failure may be critical when it blocks a high-value segment or creates a legal, safety or trust risk.
Build an opportunity record
For each opportunity, document:
| Field | Purpose |
|---|---|
| User or stakeholder outcome | States the change in human or organizational terms |
| Supporting evidence | Links to cases, behavior and relevant data |
| Affected context | Defines where the opportunity applies |
| Business relevance | Connects the outcome with strategy or performance |
| Confidence | Reflects evidence quality and consistency |
| Important counter-evidence | Prevents selective reporting |
| Product options | Keeps multiple responses open |
This record lets a reviewer move backward from a proposed priority to the evidence and forward from evidence to the decision.
Add non-research constraints visibly
Product priority also depends on strategic fit, expected value, implementation effort, technical dependencies, regulation and opportunity cost. Add these factors after the research opportunity is clear.
Do not hide them inside a single unexplained score. A high-confidence user problem may still be deferred for a valid strategic reason. The decision record should show that trade-off.
Review contradictions before ranking
Look deliberately for cases that do not fit the dominant interpretation. Differences by role, experience, market, channel or workflow stage may reveal that a single solution would create new friction elsewhere.
Contradictory evidence can lead to segmentation, configurable workflows or a decision not to build.
The final priority statement
A defensible priority can be written as:
For defined users in context, improve outcome, because evidence, subject to constraints. We will know the response works when measure changes without guardrail deteriorating.
That sentence is more useful than “users asked for feature X.” It preserves the problem while leaving space for product design.
Related MTF resources
Explore MTF’s Research and Business Analysis Practice and Project Management program.