You ran the interview. You took notes. Now what?
Most PMs dump interview notes into a Google Doc, tag a few themes, and move on. Three months later, nobody can find the insight that should have shaped the next feature.
The problem isn't that you don't talk to users. The problem is that conversations decay into anecdotes.
Pathmode turns your conversations into structured, searchable signals that carry their own trust state. Here's how.
The Method
Step 1: One Insight, One Signal
The most common mistake is writing paragraph summaries. "Sarah had trouble with onboarding, mentioned she liked the dashboard, and asked about team features."
That's three signals crammed into one blob. Pull them apart:
| What you heard | Evidence type | Signal |
|---|---|---|
| "I almost gave up during setup" | Friction | Setup flow causes drop-off |
| "The dashboard is the first thing I check every morning" | Quote | Dashboard is primary engagement surface |
| "Can my team see the same data I see?" | Request | Team visibility / shared access |
Each insight gets its own signal. One type, one source, one row in the Inbox.
The discipline: If you can't express it in one sentence, you haven't distilled it yet.
Step 2: Type It Correctly
Pathmode uses five evidence types. Interviews generate all of them, but the distribution tells you something:
| Evidence type | What it captures | Interview signal |
|---|---|---|
| Friction | Pain, struggle, failure | "I couldn't...", "It took me forever to...", "I gave up on..." |
| Quote | Exact words worth preserving | Emotional language, surprising framing, pithy summaries |
| Observation | Something you noticed, not something they said | Hesitation, confusion, workarounds they didn't mention |
| Metric | A number they gave you | "We spend 3 hours a week on...", "Only 2 out of 10 people..." |
| Request | Something they asked for | "Can it do...?", "I wish there was...", "What if you added..." |
💡 Tip: Observations are the most underused type. What the user does matters more than what they say. If they described a task as "easy" but took four minutes to find the right button, that's a Friction and an Observation, not a positive signal.
Step 3: Resist the Urge to Solve
This is the hardest part for PMs. You hear a problem. You immediately know three ways to fix it. You want to write the solution into the signal.
Don't.
Evidence describes what is, not what should be. The moment you inject a solution, you have biased every future reader of that row, including yourself.
❌ Wrong: "User can't find export, we should add it to the toolbar"
✅ Right: "User spent 2 minutes looking for export. Checked Settings, then Help, then found it under File menu."
The solution comes later, when you have written a claim and found out how many independent sources back it. That's what the discovery play is for.
Step 4: Tag the Source
Every signal needs a source. Not "user interview", which is useless in two weeks. Be specific:
- Who: Role, segment, or anonymized ID ("Enterprise PM, Trial Day 3")
- When: Date of the interview
- Context: What you were testing or exploring
This matters when you're staring at 8 signals backing the same outcome and asking "is this pattern real, or did I just talk to one angry user twice?"
Step 5: Capture It Immediately
Process your notes the same day as the interview. Not next week. Not "when I have time." The day of.
Why? Because your memory of tone, hesitation, and body language is perishable. The difference between "she mentioned export" and "she visibly frustrated when trying to export" is context that evaporates within 48 hours.
A 30-minute interview should produce 5 to 10 signals. If you're getting fewer than 3, you're summarizing instead of decomposing.
The Payoff: Claims You Can Check
After 5 to 8 interviews processed this way, your evidence stops being a collection and starts being something the team can check. Write the problem as claims in an Intent Spec, then review the signals against them. You'll see:
- Backed claims: four people hit the same friction in onboarding, you reviewed each one, and the outcome now reads Backed with your name on it
- Gaps: everyone mentions collaboration but the permissions constraint reads No evidence, so that's your next research question
- Surprises: users love a feature you were about to deprecate, which is a strategy input rather than a spec
The backed claims point to what to build. The gaps point to your next round of interviews.
Anti-Patterns
❌ The Transcript Dump: Keeping every extracted row from a whole transcript. Evidence is distilled signal, not raw data. Drop the rows that carry nothing before you save.
❌ The Solution Interview: You asked leading questions ("Would you use a feature that...?") and now your evidence is contaminated with hypothetical demand. Evidence should capture real behavior and real pain.
❌ The Batch Processor: You ran 12 interviews over two weeks and are now trying to process them all at once. Half the nuance is gone. Process same-day.
❌ The Solo Capture: Only you add evidence. Get your designer, your engineer, your support lead adding signals from their own sources. The strongest claims are the ones backed from several independent directions.
Next Steps
- Run the play: after your next user interview, process the notes using this method. Everything you keep lands in the Inbox marked Unreviewed.
- Write the claims: start an Intent Spec that states the problem as an objective, outcomes, constraints, and edge cases.
- Review and back: work the Inbox and use each signal as backing for the exact claim it supports, or keep it unreviewed. See Evidence 101 for the full play.