How to Set Up a Customer Interview Process in Dovetail
Dovetail is a research repository and analysis tool designed specifically for product teams. It stores interview recordings, auto-transcribes them, lets you tag and code qualitative data, and surfaces patterns across all your research in one searchable repository. The alternative — interview notes scattered across Notion docs, Google Docs, and Slack threads — makes synthesis impossible.
This guide covers how to set up a repeatable customer interview process in Dovetail, from project setup to sharing insights with stakeholders.
Step-by-step guide
Create a Research project
In Dovetail, create a new Project for each research initiative (e.g., "Onboarding Research — Q3 2026"). Set the research question, methods (interviews, usability tests), and participant criteria in the project description. Projects keep related interviews grouped so you can synthesize patterns across sessions without mixing research from different topics.
Set up your tagging taxonomy
Before conducting interviews, define your tag set in Project Settings > Tags. Create tag groups: Pain Points, Workarounds, Desired Features, Jobs to Be Done, Emotional Response. Pre-defined tags create consistent coding across all interviews. You can add tags during analysis, but having a starting taxonomy prevents inconsistent labeling.
Import and transcribe interviews
Upload interview recordings via the Data section. Dovetail auto-transcribes audio and video using AI. Review the transcript for accuracy — especially product-specific terms and names. Enable speaker identification to label which turns belong to the interviewer vs. the participant. Transcription takes 10-30 minutes depending on length.
Tag and code the transcript
Open the transcript and highlight quotes that are significant. Apply tags from your taxonomy. Dovetail automatically links the tagged quote to the timestamp in the recording. Code systematically: work through the full transcript rather than cherry-picking confirming quotes. Tagging takes 30-60 minutes per interview.
Synthesize insights across interviews
Navigate to Insights in your project. Dovetail clusters tagged quotes by tag, showing how many participants mentioned each theme. Create Insight documents that summarize each major theme: write a one-paragraph summary, embed the supporting quotes, and add a "So what?" section with the implication for product decisions. These Insight documents are what you share with stakeholders.
Common mistakes
Tagging only confirming evidence
Confirmation bias in tagging is the most common research mistake. Code everything, including quotes that contradict your hypothesis. Dovetail shows tag frequency across all interviews — if a theme only appears in 2 of 10 interviews, it should not drive a roadmap decision.
Conducting interviews without a discussion guide
Ad hoc interviews produce incomparable data. Each interview covers different topics, making synthesis impossible. Write a discussion guide with 5-7 open-ended questions before the first session. Dovetail lets you attach the guide to the project for reference during sessions.
Sharing raw transcripts instead of synthesized insights
A 60-minute transcript is not a deliverable. Stakeholders need the "so what" — not the raw data. Use Dovetail's Insights feature to synthesize themes and embed supporting quotes. Share a 2-page Insight document, not a link to 10 raw transcripts.
Tips
Use Dovetail's Magic feature to auto-tag transcripts based on your existing taxonomy — then review and correct the AI tags manually
Connect Dovetail to Slack to automatically share new Insight documents with your #product-research channel
Build a Research Repository project in Dovetail that archives all completed research — a searchable library of past insights that new team members and PMs can draw from
How Vantage helps
Vantage connects to research documentation so your interview findings become context for PRD generation. When you create a project in Vantage, import your Dovetail insight summaries as context sources. The AI grounds PRD requirements in real customer language and observed behavior, not assumptions about what users want.