The transcript isn't the interesting part

For years I thought I had a note-taking problem. Every customer call got recorded, and I’d tell myself I would go back and watch it if I ever needed something. I almost never did, and the few times I tried, I’d burn fifteen minutes scrubbing through an hour of video looking for one sentence I half-remembered. I took notes during the calls too, and those were barely better. Half the time I couldn’t read them afterward, and the other half I’d find something like “onboarding confusing?” with no memory of what it meant a week later. So I’d walk away from every call with two useless artifacts, a recording I’d never watch and notes I couldn’t decode, and the actual insight died somewhere between them. I assumed the problem was discipline. It was tooling.

I stopped trying to capture the call

Every call now gets recorded and transcribed by Granola. Otter, Fathom, whatever, the specific tool isn’t the point. What changed is that I stopped trying to capture the call myself. I still hold a pen sometimes, but not to take notes with; holding it keeps me locked in and listening, and that’s the only job it has now. The transcript handles the record, and my job on the call is just to listen.

It’s connected to everything else

The surprising part was never that AI could summarize a conversation. Everyone can do that now, and on its own it isn’t worth much. The surprising part was what happened once the transcript was connected to everything else.

After a call I ask Claude to pull up the conversation, and the transcript is only one of the inputs. It also has the previous conversations with the same person, the other customer calls, our product docs, the roadmap, the features we’ve already shipped, the technical constraints, and all the context that normally lives scattered across tickets, docs, Slack threads, and people’s heads. Without that surrounding context, a transcript barely helps. A customer might spend ten minutes describing a problem we solved two releases ago. They might ask for something we can’t build. They might be describing, almost word for word, the same friction that has come up in five other calls this month. The transcript alone can’t tell me which of those is true. The context can.

The question I actually ask

So I don’t ask what features someone requested. I’ve found customers are bad at requesting features and great at describing pain, and the times I built exactly what was asked for, I usually shipped the wrong thing. Instead I ask what got in this person’s way. What friction did they hit, what workaround are they leaning on, what are they doing by hand that they clearly resent doing. The feature is my job to invent. The pain is theirs to report. On one call a customer spent the whole time describing how hard it was to tell who on our platform was legitimate and who wasn’t. They never asked for verification and never proposed a fix. They just kept circling the discomfort of not knowing who to trust. That was the useful part, not a feature request that never came, but the problem sitting underneath it.

Most feedback shouldn’t become a feature

Finding the problem is only half of it, and this is where judgment still matters. Most feedback should not become a feature. Some pain is unique to one customer. Some isn’t important enough to act on. Some cuts against the direction we’re trying to go, and some already has a solution we shipped and never told anyone about. Telling the difference is a skill, and the thing that sharpened it for me more than any tool was a short book called The Mom Test by Rob Fitzpatrick. It’s about how to talk to customers so they tell you the truth instead of what you want to hear, and it taught me to discount the polite enthusiasm and listen for the real, costly problems people actually have. The tools surface what was said faster than ever. They still can’t tell me what was worth saying. That part stays human.

What the context does change is the next question. Deciding whether a problem is worth solving used to mean pulling from a dozen places: customer notes, product docs, the roadmap, a prioritization meeting, an engineering thread. Now I can ask one thing. Given everything we know, is this worth building? That’s the part that genuinely surprised me. The transcript is useful, but the context is where the value lives.

From a problem to a shipped feature

Once a problem survives that filter it becomes a Linear issue, and then something else interesting happens. The same setup that helped me understand the problem helps me build it. Call, transcript, context, problem statement, issue, implementation. For most of my career those were separate functions handled by separate people, research and product and prioritization and engineering, and every handoff between them was a place for context to leak. The distance between them is now very short. The problem statement becomes a ticket, the ticket becomes work inside Claude Code, and the commit closes the issue on its own. Call on Monday, feature live by Wednesday, sometimes the same day. I’m not a developer by training, and I built most of our platform this way. Not because the tools are magic, but because the handoffs mostly disappeared.

The loop isn’t closed when it ships

The step I treat as non-negotiable, and the one most people drop, is telling the customer. The loop isn’t closed when the feature ships. It’s closed when the person who described the problem hears back. Every time I do it the response is stronger than I expect, because people notice when they’ve been listened to, and they bring you better problems next time once they’ve seen that describing one actually leads somewhere.

It isn’t really about customers

I’ve framed all of this around customers and product because that’s the cleanest version of it. The output is a literal shipped feature, so the payoff is easy to see. But none of the mechanism actually depends on customers. The shape is the same for any recurring conversation that’s supposed to lead somewhere. I run monthly check-ins with the founders and partners in our programs, and they have the same problem a sales call does: the useful signal is buried in an hour of talk, the context from the last few sessions is what makes any of it mean something, and whatever we agreed to tends to evaporate in the gap afterward. The same is true of a team call, a professor’s office hours, planning an event, even planning things at my church. Anywhere a conversation is supposed to turn into action and keeps not turning into action, this works. Product is just the place where you can watch it working most clearly.

What actually broke

The thing that caught my attention through all of this is that the call was never the bottleneck. The feedback loop was always there. What broke was everything after the call: the note that had to become a ticket, the ticket that had to become a task, the task that had to get prioritized, the insight that had to survive long enough for someone to act on it. Each step was a small crack where a little information leaked out. Nothing was ever lost all at once. It was death by a thousand cuts.

Which is why the tools are almost beside the point. Use Granola or don’t. Use Claude or don’t. Use Linear or don’t. The part worth paying attention to is that we’re getting very close to a world where understanding a problem, deciding whether it matters, and building the solution can all happen in the same place. The shorter that distance gets, the faster an offhand comment on a Tuesday call turns into something real.

*One caveat, and it mostly goes without saying. Keep private things private. Not every conversation belongs in this loop. When a coworker is telling you what they’re struggling with, or a friend is confiding in you, that is not a transcript to feed into anything. Use some discretion about what is actually feedback and what is just a person trusting you with something. And any time you are recording, make sure the other side knows. The point of all this is to listen to people better, not to quietly turn them into data.