Twelve customer interviews this quarter. Three people watched the recordings. The transcripts are in Drive, named by date. The themes only exist in the head of whoever ran the interview — and six weeks later the PRD goes out, written from memory.
Recording is solved. Listening is the work. The expensive part of an interview isn't the hour you spent — it's the conversion from conversation to theme, theme to persona, persona to product decision. We built the part most teams skip: an archive where the customer's voice is already organized into the patterns the team can act on.
Customer interviews are an expensive way to learn things and a cheap way to lose them. A 45-minute conversation costs scheduling, prep, the call itself, the awkward silence at minute thirty-eight where a real answer finally lands — and then it gets uploaded to Drive as a 230 MB MP4 and a transcript nobody opens.
The work that actually matters — reading the corpus, tagging passages, clustering themes, drafting the persona, finding the quote that justifies a roadmap call — is the work that gets skipped. Not because the team is lazy. Because nobody owns it, and the tools force you to choose between recording in Zoom, transcribing in Otter, tagging in Dovetail, and writing the PRD in Notion. Four surfaces, three logins, zero connections between them.
Six weeks later, when somebody on the team writes the spec, the customer voice in that spec is whoever-ran-the-interview's memory of the customer voice. Which is not the same thing.
Every recording lands in the archive with the transcript attached, speakers labelled, timestamps intact. AI tags themes the moment a third or fourth interview confirms a pattern — price sensitivity, onboarding drop, integration gap — and the quotes that justify each tag are one click away.
Personas draft themselves from clustered quotes. Jobs-to-be-Done statements emerge from the patterns the corpus is already showing you. The research isn't a deliverable you produce after the round; it's a layer that grows during the round and stays linked to every primary source it came from.
Then — the part most research tools stop short of — when the PM opens Cursor and starts writing the PRD, the relevant interview quotes surface inside the editor. Not as a dashboard the PM has to remember to check. As a citation that arrives when the section is being written.
The interview is the cheap part. Acting on what it said is the product.
Three moments from a typical research round. Pick one — the archive lights up the part of itself it would actually use. No live data, no signup; the moves are real, the quotes are illustrative.
Forty-five minutes in. The transcript is already written; you're still listening, not typing.
The session lands tagged against the rolling theme list — 'price-clarity' is now in three calls.
Two prior interviews where someone said the same thing surface beside the new one. The pattern declares itself.
The quote is already linkable from anywhere on the team — the PM doesn't need to ask you for it.
Forte called the four moves CODE for personal knowledge. We renamed the same shape for the work researchers actually do.
Knovya's twenty-six elements aren't all for research — but twelve of them carry this work cleanly. Here's which features map to which move, and which pieces are doing the heaviest lifting for an interview-driven workflow. The full table lives at /features.
Get the customer's words out of the call and into a place that can be searched, tagged, and read by the rest of the team.
Record the call, get a speaker-aware transcript with timestamps.
Paste a Zoom transcript or chat log; it lands as a structured note.
Background reading, competitor pages, public posts — clipped with sources intact.
The corpus arranges itself — tags, themes, semantic neighbors, ranked by what's repeating across calls.
Tag passages by theme; cluster quotes; pull JTBD statements.
A view of which themes connect across which interviews.
Every quote, theme, and persona linked back to the source it came from.
Themes become personas. Personas become JTBD statements. The right quote rises before the question is finished.
Search the corpus by keyword and meaning at once.
Past interviews surface alongside the new one — the precedent does the talking.
Forgotten quotes return when their topic comes up in a new draft.
The corpus is the start of the next document — PRD, persona doc, share-out — exposed to every editor and AI you already use.
Publish the persona, share the quote bank, keep the raw transcripts private.
Cursor, Claude, ChatGPT read the research archive while you write the spec.
Persona, JTBD, interview-guide, debrief — all linkable, all editable.
Customer research didn't start with software. The methods we use — field notes, usability testing, jobs-to-be-done, modern repositories — arrived in waves, each solving the bottleneck the last left behind. The current bottleneck is synthesis.
Goffman's Presentation of Self in Everyday Life codifies a discipline sociology had been practicing for decades: write down what people actually did, not what they said they did. The notebook is the instrument. Every customer interview since is a descendant of the field note.
Krug's book makes guerrilla usability testing legible to non-researchers. Five users in a hallway, a stopwatch, and a notebook produce more honest signal than a twelve-page survey. The method outlasts the era it was written in — teams still use it today.
Christensen and Anthony reframe the interview question itself. Not what features do you want but what job did you hire this product to do? The Milkshake study becomes the most-cited illustration in product strategy for two decades. The question shape changes; the listening discipline doesn't.
Dovetail (and EnjoyHQ alongside it) make the spreadsheet-of-tags into a product. Tag a transcript, cluster the tags, share with the team, search across rounds. The repository as a category is born. Notably, Aurelius, and a dozen others follow within five years.
Marvin, the AI features inside Dovetail and Notably, NotebookLM — embeddings finally cheap enough that theme extraction can happen across a corpus, not in a spreadsheet column. Tagging falls to the machine. The discipline that survives is asking the right question and reading the transcript at least once.
We built the part the previous generation stopped short of: the archive doesn't just hold interviews; it surfaces them inside the document that's about to act on them. Through MCP, when a PM opens Cursor and starts writing the spec, the relevant quote arrives where the citation goes. The research stops being a deliverable. It becomes load-bearing.
Most tools in this category are wagering on a step — the recording, the tagging, the repository, the AI synthesis. The honest comparison isn't features; it's which step each tool decided to be best at, and which one it leaves to you (or your other twelve tabs).
The bet The repository as a category. Tag a transcript, cluster the tags, share with the team, search across rounds. The reference point for what a research tool ought to feel like.
What's left to you The hand-off into product. The repo is beautifully self-contained — insights live there, the PRD lives elsewhere, and the citation back is whatever you remember to paste.
The bet Real-time, shared tagging. A research team highlights and codes the same transcript together, watches the themes form on a board, runs lightweight synthesis inside the same surface.
What's left to you The downstream document. The board is where the work feels alive; the persona doc and the PRD that act on it still live somewhere else.
The bet The insight as the unit. One observation per card, evidenced by quotes, searchable by theme. The Zettelkasten of customer research.
What's left to you The conversation between insights and decisions. Cards stay in the research tool; the spec that needs them stays in Notion or Linear.
The bet One workspace for everything. Interview notes, personas, PRDs, and roadmap all on the same page tree. If you're disciplined enough, the citation never has to leave the system.
What's left to you The synthesis. Notion holds the words; tagging, theming, persona-drafting are on you. Search is keyword-only — the right quote doesn't come find you.
The bet The corpus and the spec are the same archive. Tag and theme like a research tool; link and surface like a knowledge base; expose to Cursor and Claude through MCP so the quote appears where the spec gets written.
What's left to you Asking the right question. The synthesis layer is on the system. Listening — the part research humans are actually good at — is the only piece left for you.
Other apps pick a step to be best at. We picked the connection from research to product.
A research tool earns its place at the four surfaces a researcher already lives in: the call, the synthesis canvas, the persona doc, and — the one most tools forget — the editor where the team writes the spec.
Speaker-aware transcript while the call is still happening — you stay present, the archive captures verbatim.
Twelve interviews, four themes, the dense regions form on their own — price-clarity, onboarding, integration gap, jobs-to-be-done.
Each claim in the persona is one click from the interview quote that justifies it. Hover any sentence; see the source.
Through MCP, the editor reads from the research archive while you write. The citation arrives where the citation goes — no copy-paste, no tab-switch.
Customer research isn't a stop — it's an upstream. The corpus feeds the PRD, which feeds the meeting, which feeds the decision log. Here's the constellation around this page.
Record the call. Get a speaker-aware transcript with timestamps.
See featureTag passages, cluster themes, draft personas across a corpus of interviews.
See featureWhich themes connect across which interviews — in a view, not a spreadsheet.
See featureCursor, Claude, and ChatGPT read the corpus while you write the spec.
See feature"The PRD that starts blank, six weeks after the customer research that should have written it."
The spec drafts itself from the interviews, decisions, and prior PRDs already in the archive.
See the workflow Problem 05 · Chapter I"The literature lives in Zotero. The fieldnotes live in a notebook. The synthesis never happens."
One archive, one graph — literature, interviews, hypotheses, drafts, all linked.
See the workflowThe history from Goffman to Krug to Christensen, the methods that survived, and what AI synthesis changed in 2024.
Read the primer DefinitionThe practice underneath every research repository — capture, retrieval, the recall-to-recognition shift.
Read the primerA research archive isn't built in one round. It's built one transcribed call, one tagged theme, one persona drafted from quotes at a time. The archive starts paying back the moment the first interview lands in it.
Or scroll back to the diagnosis.
Eight questions we keep getting from PMs, UX researchers, and founders. If yours isn't here, the contact page reaches us directly.
A user interview is a structured conversation with someone in your target audience — usually 30 to 60 minutes — meant to surface the problems, motivations, and language they use around a product or task. It's the foundational method of qualitative customer research, used by product managers, UX researchers, and founders to figure out what to build before they build it.
User research is the practice of learning what your users actually do, want, and struggle with — through interviews, usability tests, surveys, and observation — and turning that into product decisions. It pre-dates the software industry; the digital version traces back to Steve Krug's usability work in 2000 and Clayton Christensen's Jobs-to-be-Done framing in 2003.
The honest answer: you don't. Trying to type or write while interviewing means you stop listening. The current best practice is to record (with consent), let an AI transcribe in the background, and stay fully present with the person. Any quick observation you do write down should be a tag or a question for follow-up — not a verbatim quote.
Three layers. Raw transcript with speaker labels and timestamps. Quote bank tagged by theme. Synthesis layer — themes, tensions, personas, JTBD statements — that links back to the quotes that justify it. Each layer should be searchable and connected, so when a PRD references "price sensitivity," the original interview where someone said it is one click away.
Read every transcript at least once before coding. Tag passages by what's actually being said, not by what you wanted to hear. Cluster the tags into themes only after the corpus is wide enough that themes start repeating themselves. Treat outliers as a question, not noise. AI can speed the tagging and clustering — it shouldn't replace the read-through.
Often nothing — many teams use them interchangeably. The technical distinction: a customer interview talks to someone who pays for the product (whose problem you solve in exchange for money); a user interview talks to someone who uses it (whose problem you solve, whether or not they hold the wallet). In B2B these are sometimes different humans; in B2C they usually aren't.
The bottleneck has moved from capture to synthesis. Recording and transcription are solved — every video call platform does it. The work AI does well is theme extraction across a corpus of twelve or fifty interviews, persona drafting from clustered quotes, and surfacing the right quote when someone is writing a PRD. AI replaces the spreadsheet step, not the listening step.
Yes. Knovya Free includes 50 notes, 50 AI credits per month, and 50 MCP calls per month — enough to keep the transcripts, themes, and personas from a small research round (roughly 8–12 interviews) and see the synthesis flow before paying anything. Pro and Team add E2E encryption and higher limits for ongoing research programs.