How to Organize a Customer Research Repository

TL;DR. Organize a customer research repository around evidence people can find and the decisions it supports. Keep source material, evidence notes, findings and decisions connected, using a small, consistent set of tags. Record participant permissions and restrict access before sharing. Every conclusion should show its supporting evidence, limitations and any conflicting observations.

What should a customer research repository contain?

Use four connected record types:

Record	What belongs here	What it connects to
Source	Interview recording, transcript, observation notes or feedback record	Evidence notes and permission record
Evidence note	A specific observation or excerpt with context	Exact source location and relevant finding
Finding	An interpretation supported by evidence	Supporting notes, conflicting evidence and limitations
Decision	What the team chose, why and what remains uncertain	Findings used and follow-up questions

Give each record a stable identifier. Link records rather than copying the same evidence into several folders.

A source preserves context. An evidence note makes a relevant moment findable. A finding explains what you think it means. A decision records what you did with that interpretation.

Keep those roles distinct: a participant’s request belongs in the evidence; your proposed response belongs in the decision.

How should you structure the repository?

Start with a shared index and a consistent record template. Use study or project pages to collect material from a research activity, but let readers find evidence across projects through filters and links.

Build views around questions people need to answer:

• What have we learned about this customer segment?
• Where do people struggle with this task?
• What evidence informed this product decision?
• Which assumptions still need investigation?

Avoid making team names or project names the only route into the material. Someone investigating onboarding should be able to find relevant evidence without knowing who collected it.

Link segment definitions to your ideal customer profile. For task-based research, connect findings to the progress customers are trying to make, as described in Jobs to Be Done for B2B Product Teams.

Which tags should you use?

Start with a few tag families. Add a tag only when it supports a useful search or comparison.

Tag family	Question it answers	Illustrative values
Customer segment	Whose experience is this?	Small team, multi-team organisation
Role	What responsibility does this person have?	Buyer, administrator, daily user
Journey stage	Where does the experience happen?	Evaluation, setup, ongoing use
Topic	What is the evidence about?	Permissions, reporting, handover

Keep research method, owner, collection time and source type in dedicated fields. Keep permission and access status in controlled fields too; ordinary topic tags should not determine who can open a recording.

Write a short definition for every tag. Explain when to use it and where it overlaps with another label. Choose one term for synonyms, and give one person responsibility for resolving additions and duplicates.

Do not tag everything that appears in a conversation. Tag an evidence note for the subject it supports, rather than every passing mention.

What should each evidence note include?

Use a template that preserves enough context to assess the observation:

• Observation or excerpt: what happened or what the participant said.
• Context: the task, situation and relevant customer characteristics.
• Participant identifier: a pseudonymous reference linked to restricted records.
• Source link: the original material and an exact timestamp, section or note reference.
• Collection details: when and how the evidence was gathered.
• Permission status: permitted uses and relevant restrictions.
• Tags: the agreed labels needed for retrieval.
• Interpretation: a separately labelled explanation or question.

Preserve wording when using an excerpt. Mark omissions and keep paraphrases distinct from direct speech.

For observations, separate behaviour from explanation. A participant leaving a setup screen is an observation; concluding that the screen is confusing requires further evidence.

Use descriptive note titles, such as “Administrator cannot identify who owns setup”, rather than “Useful interview quote”.

How should you handle consent and access?

Record what participants agreed to before making their material available. Distinguish permission to participate, record, share internally and publish externally. Do not treat these as interchangeable.

Keep the permission record accessible to authorised researchers without exposing participant contact details to every repository reader. Where permission is unclear, restrict the material while you resolve it.

Use access groups based on what readers need:

Material	Suggested access approach
Contact details and consent records	Designated research administrators
Identifiable recordings and transcripts	Approved research collaborators
Redacted evidence notes	Relevant product and commercial readers
Findings and decisions	Intended decision-makers, with sensitive details removed

Check permissions on both the repository entry and the linked source. Opening a finding should not grant access to a restricted recording.

Set a retention and removal process. Keep track of derived excerpts so a change in permission can be handled across connected records. Review redacted notes for identifying context, including unusual roles or distinctive events.

How do you turn evidence into a supported finding?

Synthesis should explain how you reached an interpretation, not just collect excerpts beneath a heading.

For each finding, record:

1. The claim: a specific statement with a defined scope.
2. Supporting evidence: linked observations and their context.
3. Conflicting evidence: cases that suggest a different explanation.
4. Limitations: gaps in recruitment, method or coverage.
5. Decision relevance: what this could change.
6. Next question: what would strengthen or challenge the interpretation.

Count independent participants separately from excerpts. Several notes from the same conversation still represent one participant’s experience.

Avoid presenting interview observations as a measure of how common a problem is across all customers. Scope the finding to the people and situations studied.

Keep alternative explanations visible. A missed step might reflect unclear wording, missing authority or a task that participants did not need to complete.

What does a connected example look like?

The following example is illustrative.

A team is deciding whether to change its workspace setup flow. In an interview, an administrator describes waiting for a colleague to confirm who should approve access.

The evidence note links to the relevant transcript passage and records the participant’s role, task and permissions. It uses the tags administrator, setup and permissions.

During synthesis, the team compares that note with other setup observations. Some participants hesitate over ownership; others understand ownership but lack permission to continue.

The finding becomes: “Setup handovers need clearer ownership in the situations studied.” It does not become a claim that all setup problems need fewer screens.

The decision records a proposed ownership prompt, the evidence behind it, the access problem it leaves unresolved and a plan to test the change. Link that decision to the relevant item in your now, next, later roadmap.

What common mistakes should you avoid?

Saving excerpts without context. Include the task and source location so readers can assess what the evidence supports.

Using a finding as a tag. A label such as “customers hate setup” embeds a conclusion. Use a topic label, then test the interpretation during synthesis.

Treating missing evidence as proof. If research did not explore a subject, mark it as unknown.

Keeping every old finding active. Mark findings as current, superseded or awaiting review. Explain when product or customer changes limit their relevance.

Building an elaborate taxonomy before using the repository. Start small, test real retrieval questions and add structure where searches fail.

Treating repository access as publishing permission. Check the recorded permission before reusing customer material in public content.

How can you tell whether the structure works?

Ask someone unfamiliar with a study to find evidence for a live decision. Check whether they can:

• Find relevant notes using the agreed fields and tags.
• Open permitted sources at the relevant location.
• Separate observations from interpretations.
• See conflicting evidence and limitations.
• Trace a decision back to the findings used.

Fix the point where that path breaks. Sometimes the answer is a better title or a missing source link, rather than another tag.

Related reading

• How to Build an ICP — define the customer segments used to organise evidence.
• Jobs to Be Done for B2B Product Teams — connect observations to customer tasks and desired progress.
• Now, Next, Later Roadmap — connect research findings to product choices.