Turn Interview Notes into a Product Opportunity Map with ChatGPT

Interview notes can contain useful evidence about a product problem alongside suggestions, incomplete quotations, and the researcher's interpretations. Turning those notes directly into a feature list risks skipping the underlying need. An opportunity map keeps the connection between observed experience and a possible product response visible.

This guide creates an original evidence-linked map using ChatGPT. The fictional interview examples are not findings from real research, and the guide does not claim a validated product opportunity. Current documentation was checked on October 6, 2026. A researcher should review attribution, interpretation, and the limits of the supplied sample before using the map.

Define the research question and note set

State the product context, research question, interview period, and intended decision. A map exploring onboarding friction should not quietly absorb unrelated pricing concerns unless the research owner expands its scope. Record which interviews are included and which are excluded.

Give participants pseudonymous IDs and notes stable passage IDs. Remove personal information not needed for the analysis, following the research team's approved process. Retain relevant context such as the participant's task and product experience without adding inferred characteristics.

Identify note types. A direct quotation, a researcher's paraphrase, and an observer's interpretation should have different labels. If the notes do not establish which type a passage represents, mark that uncertainty. Do not put quotation marks around a paraphrase to make it appear more authoritative.

Extract observations before clustering

Ask ChatGPT to list described tasks, problems, workarounds, desired outcomes, and suggestions, each with a source reference. Keep observations distinct from explanations of why the problem occurred. A participant saying a step was confusing does not by itself establish its technical cause.

Preserve important conditions. Difficulty experienced during first use may differ from difficulty experienced after a product update. Grouping them can hide a meaningful distinction. Include the contextual detail needed to evaluate whether observations belong together.

The OpenAI Enterprise prompting guide discusses supplying the relevant context and checking accuracy. The mapping schema below is an original research workflow, with human review required for its interpretations.

Build candidate need clusters

Group observations around a shared task or desired outcome rather than the same requested feature. Two participants can suggest different solutions to the same need. Conversely, the same feature suggestion can reflect different problems and should not automatically form one cluster.

Retain participant IDs and passage references in each cluster. Count distinct participants separately from mentions when counts are useful. One participant repeating an issue several times should not appear as several independent participants.

Keep contradictory and minority observations visible. A cluster that makes every interview sound consistent may conceal important differences in workflow or experience. Use those differences to define narrower candidate needs or further research questions.

Define the opportunity map structure

Use a hierarchy that connects the desired product outcome, the user need, its supporting evidence, and any proposed response. A table can be easier to review than an elaborate visual map at this stage.

Give each candidate need a stable ID. That allows later research or design discussion to refer to the same opportunity even when its phrasing improves. Do not rename IDs merely because a cluster becomes less prominent.

Ask ChatGPT for a reviewable map

Supply the research boundary, labeled notes, extraction fields, and map schema. Request evidence extraction first, followed by candidate clusters and their limitations. Avoid asking for a final roadmap from a small set of interviews.

Create a candidate product opportunity map from the supplied interview notes.
Separate direct quotations, paraphrases, and researcher interpretations.
Extract observations with participant and passage IDs before clustering.
Group by task and need, preserving context and contradictory evidence.
Do not invent quotations, participant attributes, prevalence, or causal explanations.
Label proposed solutions as hypotheses and identify validation questions.
Return the map with a coverage check and observations that do not fit a cluster.

Compare the output with the original notes. Check that an appealing cluster name has not broadened a specific complaint into a general claim about all users. The map should describe the reviewed evidence, not imply a population estimate.

Examine a fictional opportunity

Suppose two fictional participants describe uncertainty about whether a submitted request reached the reviewer. One suggests an email notification; another suggests a visible status label. The shared candidate need may be knowing that submission succeeded and understanding the next step.

The map can attach both observations to that need while retaining the proposed solutions separately. It should not declare that email is the preferred feature merely because one participant mentioned it first. The team would need more evidence about the task and suitable responses.

If a third participant reports no difficulty because a different workflow supplies confirmation, record that context as limiting evidence. It may indicate that the opportunity concerns one submission route rather than the entire product.

Prioritize questions before features

Review evidence strength, relevance to the stated outcome, and the consequence of being wrong. Use an approved prioritization framework if one exists, with its definitions and inputs visible. Avoid invented scoring weights or numerical confidence values.

Create research questions for uncertain interpretations. Does the problem occur only on first use? Is the missing information about submission success or reviewer timing? These questions can refine the opportunity before the team invests in a proposed solution.

Keep a clear distinction between deciding what to investigate and deciding what to build. A candidate opportunity map supports the former and informs the latter; it does not independently establish feasibility, adoption, or a delivery commitment.

Review and maintain the map

Ask the researcher to verify passage references, cluster membership, participant counts, and interpretation boundaries. Check that observations left outside clusters are retained and explained rather than discarded. The ungrouped evidence may become important in later research.

Use the assumption register workflow when a proposed product response depends on unconfirmed conditions. Connect those assumptions to the opportunity ID so the team can distinguish user evidence from implementation expectations.

Save the approved map with the note set, research scope, review date, and unresolved questions. Add new interviews as a new reviewed evidence set and record how they change the map. A useful opportunity map remains traceable as the team's understanding develops.

Frequently asked questions