Five customers, five different pain points, one transcript per call, no server between you and the data.

A product manager's day is five customer calls back-to-back, each one with a different customer, each one revealing a different part of how the product works in real companies. By the end of the day, five recordings sit on the Mac. Five transcripts. Five summaries. Each one a record of what that customer actually does with the product, what they do with other tools instead, what breaks in their workflow, and what feature they'd switch for if it existed.

What makes customer feedback actionable isn't the feeling that customers asked for something. It is the moment you can point to the exact transcript of the exact conversation where they said so, and show your team the exact context: what they're working around today, why that workaround exists, what happens when it fails.

8:00am — preparing for five customer conversations

Before the first call, the PM reviews the call schedule. First call: a 50-person SaaS company using the product for three months. They want to discuss their transcription workflow. Second: an agency where the product hasn't been used much, but the operations manager wants to integrate it into their client delivery process. Third: a lawyer who's been using the product since launch, wants to discuss security features. Fourth: a consultant who's been asking for a specific export format. Fifth: a small team that switched from another tool two months ago and is running into a specific limitation.

Five different contexts. Five different use cases. The prep isn't new — it's reading the tickets and support notes before each call. What's different is that answers to questions raised in these calls will be sitting on the Mac within minutes, not reconstructed from memory at the end of the day. The PM doesn't have to choose between listening fully and taking notes while listening. The recording does the notes.

9:00am — the first customer: a SaaS company, scaling transcription

The first call is with a team that's been using the product to transcribe customer calls — they're using recordings to log the substance of each call and refer back to it later. They've been happy overall, but they're running into a scaling problem. They've moved from three people recording calls a week to about twenty calls a week across the team. Right now, each person is organizing their own recordings in folders, but there's no shared index of what's been recorded. A customer service rep recorded something two weeks ago, and now the team can't find it.

The PM walks through the limitation and asks what they've tried to work around it. They're using a shared spreadsheet where someone manually writes the customer name and call date. But someone forgets to update it, so the spreadsheet is always out of sync. The customer asks whether the product has a shared library or a search across all team members' recordings. It doesn't. But the fact that they're trying to build a workaround shows where the pain is: they need discoverability.

This is the insight that matters. Not "they want a shared library" but "they recorded something two weeks ago and can't find it because there's no way to search the whole team's archive." The team has named the symptom. The PM has the context.

9:45am — after the first call, before the second

The PM has fifteen minutes before the second call. That second customer is an agency that hasn't adopted the product widely yet, but the operations manager is considering making it part of the delivery process. What should the PM know before the call? The first conversation revealed that team transcription and searchability is a real use case. The agency might be thinking the same thing.

The PM pulls up the summary from the first call. Key points: shared library is missing, discovery is a pain point, team would benefit from centralized search. Before the second call starts, the PM knows what questions to ask from the second customer: whether they also have this problem, whether their team has the same shape.

10:00am — the second customer: an agency, building discovery into delivery

The second customer runs an agency that does client work for small companies. They're thinking about how to use the product as part of their delivery — recording client kickoff calls, discovery interviews, feedback sessions. Right now they do this in part through Zoom recording, which lives in Zoom. But they want something they can give to clients as a deliverable: "here's the recording and transcript from our discovery conversation with you."

The operations manager is thinking about whether the product fits into their delivery workflow. Can they export the recording and transcript together? Can they share a transcript with a client without sharing the audio? Can they organize recordings by client? What does the workflow look like?

These are different questions from the first customer. The first customer wanted internal team search. This customer wants client-facing delivery. But both are asking about organization and sharing, which is related. The PM asks whether they'd want to share the raw recording or just the summary, and the customer explains they'd want to send the client the transcript as a record of what was discussed, but not necessarily the audio.

10:45am — before the third call, comparing two different use cases

The PM has fifteen minutes before the third call. Now there are two very different contexts: one company wants internal team discoverability, another wants client deliverables. Both involve transcripts and organization. But the first is about searching internally; the second is about sharing externally. Those are different product decisions.

Before the third call, the PM knows to ask about this explicitly: whether customers want to share transcripts with external parties, and if so, what format makes sense.

11:00am — the third customer: a lawyer, security and privacy questions

The third call is with a lawyer who's been using the product since launch. They're recording client sessions and client phone calls. They like the local-first approach — nothing leaves the Mac. But they're now being asked by clients about how the data is stored, whether the firm can guarantee confidentiality, whether the product meets any compliance standards.

This customer isn't asking for a new feature. They're asking about the existing behavior: "where does the recording go?" and "is it safe for attorney-client conversations?" The answer is important because if the lawyer can't confidently tell clients that recordings stay on the Mac and never leave, then the product doesn't fit a lawyer's workflow.

The PM walks through where recordings live, what happens if the Mac is backed up, what the compliance posture is. The lawyer has specific questions about whether the firm can audited who accessed recordings, and the product doesn't have user-level access controls because it's designed for one person on one Mac. That's a limitation for a firm that wants to centrally audit access.

This is valuable in a different way: it shows a use case where the product's design — local-first, one person per license — is actually a limitation, not a strength. The strength is privacy. The limitation is audit trail.

11:50am — before the fourth call, understanding the trade-off

The PM now has evidence that the architecture — local-first, one person per Mac — is a strength for privacy and a limitation for firms that need audit trails. That's useful information. It means the product makes sense for solo lawyers but not for law firms with multiple attorneys. That's not a bug; it's a feature boundary that the product should acknowledge rather than try to overcome.

12:00pm — the fourth customer: a consultant, export and integration questions

The fourth call is with a consultant who's been asking for a specific export format. They want to export transcripts as markdown so they can paste them into their notes app. Currently, the export is PDF or plain text, and the consultant is manually copying and pasting transcript sections into markdown notes.

This is a smaller request than the others — a feature, not a workflow problem. But it's real. The consultant is spending time on a conversion step that could be automated. The PM makes a note: markdown export could eliminate a step in this person's workflow. It's not urgent, but it's a data point that'll show up in the roadmap when the PM is deciding what to build next.

12:30pm — before the fifth call, synthesis

The PM now has four calls. One about team discoverability, one about client delivery, one about the privacy/audit trade-off, one about a small export format. By the time the fifth call starts, the PM is starting to see patterns. Three customers want better ways to organize and find recordings. One wants an export. One wants audit trails. The patterns are becoming clearer than they would be from a memory of four calls.

1:00pm — the fifth customer: a small team, migration and workflow fit

The fifth customer is from a small team that switched from another tool two months ago. They're happy so far, but they're running into one specific limitation: the other tool's export included a way to export all recordings from a specific time range, which they used for quarterly reviews. Now they're doing quarterly reviews and want to review all calls from the last three months, and they have to select them one by one.

This is also a workflow request, but narrower: bulk export by date range. The customer isn't asking for a complete new feature; they're asking for something the previous tool did that's now missing.

By the end of the fifth call, the PM has five different requests or observations:

1. Shared team search and discoverability
2. Client-facing transcript delivery
3. Privacy/audit trade-off (not a request, an observation)
4. Markdown export
5. Bulk export by date range

Not all of these are equally important. Some are requests, some are observations. But they all came from listening to how customers actually use the product, and each one has a timestamp and a context in the transcript.

1:50pm — end of calls, beginning of analysis

By 2:00pm, five calls are done. Five recordings on the Mac. Five transcripts. Five summaries. The PM has the rest of the day to turn these into a roadmap decision.

The PM opens a spreadsheet and starts pulling quotes from the transcripts. "We recorded something two weeks ago and can't figure out which folder it's in." That's the pain. "Can we export transcripts in a format clients can read, without the recording?" That's the new use case. "Each person has their own license and their own Mac. There's no centralized access control across the firm." That's the boundary. "Can you export all recordings from the last three months at once?" That's the small fix.

The PM isn't paraphrasing. The PM is quoting the transcript, pulling the exact words from the exact timestamp, and putting them in the same document as the product roadmap. When the PM takes these to the engineering team, they're backed by evidence, not memory.

Thursday — comparing requests against each other

Thursday, the PM is in a planning meeting with engineering. The roadmap is usually decided by a combination of internal ideas and what the PM guesses customers want. This time, the PM has five customers saying five different things, and for each one, the PM can point to the moment in the transcript where they said it.

The team discusses priorities. Team searchability came up in two calls (implicitly in the first, explicitly in the consultant's request for bulk export). Client delivery came up once, but it was a bigger use case. Markdown export came up once. The privacy/audit trade-off is a boundary, not a feature request, but it's valuable to know because it shows which types of customers the product should target.

By the end of the meeting, the team has decided to focus on team discoverability first — shared search is the bigger change, and two customers are blocked by it. Client export will come second. Markdown export and bulk date-range export are smaller, will be done together.

None of this happened by accident. It happened because the PM listened to five calls and wrote them down. Not a feeling that customers wanted something. Not a guess about what would help. The actual words from the actual customers, in the actual context where they said them.

Friday — pulling the plan for the first customer

Friday, the PM wants to follow up with the first customer about the roadmap. What would the SaaS company say if they knew the team was going to prioritize shared search? The PM pulls the first call's transcript and re-reads it. The customer said: "If Sarah didn't label it clearly, we're stuck searching by hand." That's the pain. The feature directly solves that.

The PM sends a note to the customer: "Based on our call, we're prioritizing shared search as the next major feature. You mentioned the Acme Corp call that Sarah recorded — that would be searchable across the whole team once this ships." The customer hears about a feature that came directly from their own feedback, described in their own words. That's the difference between "we're listening" and "we're building based on what you told us."

Two weeks later — a feature spec that came from customer calls

Two weeks later, the feature spec for shared team search is being written. The PM can point to the exact moment in the transcript where the first customer explained the problem: the Acme Corp call that couldn't be found. That becomes the example in the spec. The second customer, the agency, asked a different question about client sharing, so that customer isn't blocking this feature. But when the feature ships, the PM knows exactly who will benefit from it first, because the PM knows exactly what they said they needed.

Four weeks later — the feature ships and solves a real problem

Four weeks later, shared search is released. The first customer gets access. The PM reaches out with a message: "Here's the shared search. You can now find the Acme Corp call Sarah recorded, even though it's in her folder. Try searching for 'Acme.'" The customer tries it. Works immediately. The customer benefits because the feature came from the customer's exact problem, not from a guess about what customers might want.

The comparison that proved the roadmap was right

Weeks later, the SaaS company is using shared search regularly. They've found three calls by searching keywords without knowing which team member recorded them. They tell the PM: "This is exactly what we needed. We didn't think it was possible." This feedback wouldn't be as strong without the context of the original conversation, but for the PM, the context is sitting right there in the transcript: the customer spent time describing the problem, and now the feature solves it.

What this workflow deliberately doesn't do

Nothing here puts customer feedback into a shared product database. The recordings stay on the PM's Mac. The summaries are written locally. The PM can choose to share a summary with the team, or a specific transcript search result, or nothing — the customer's data isn't flowing into a centralized system where it might be accessed by someone other than the PM. The recordings and transcripts are evidence of what customers said; they're not assets that belong to the company's CRM or analytics platform. This local-first approach means the PM is having a different kind of conversation with customers — one where the customer knows their words are staying with the person they're talking to, not being fed into a machine-learning model or a competitor analysis spreadsheet.

The day product managers stop paraphrasing customer feedback

The first day of recording customer calls feels deliberate — remembering to set up the recording, making sure the transcript is complete. By the third week, a team asking "what did customers say they needed?" gets answered with a direct quote and a timestamp, not "I think some people mentioned they wanted..." By week four, the roadmap priorities are being shaped by evidence, not by the PM's best guess about what mattered in a two-week-old conversation. By week six, the team can see which features came from customer calls and which came from internal ideas, because the customer calls are searchable and the internal ideas are documented separately.

What it costs, what it runs on

Coii AudioNotes is $19 once, covering up to three of your own Macs, with a 30-day trial needing no card and no account. It runs on macOS 13 Ventura or later, Apple Silicon or Intel. Notetaker for product managers covers why recording customer calls matters for roadmap decisions. How to search your old meetings walks through finding what a customer said weeks later by keyword. How to ask questions about a past meeting covers the technique of working backward from a follow-up to find the original conversation. How to write minutes from a transcript covers turning customer calls into summaries for your team. Best meeting notes apps without a bot covers tools that keep recordings local instead of uploading to cloud services. How to export a transcript shows how to share specific moments from customer calls with your team.