Meeting notes for product managers

A planning meeting produces commitments between teams and needs owners and dates.

Treating every meeting the same way produces either too much (a transcript nobody rereads) or too little (a summary that lost the one sentence that mattered). This guide sorts a product manager's meetings by what the notes are for.

Research calls: keep the evidence

In customer interviews and usability tests, what matters is what people actually said and did, not your interpretation of it.

• Quotes over paraphrase. "I gave up and exported it to a spreadsheet" is evidence. "User finds reporting frustrating" is already a conclusion.
• Behaviour over opinion. What they did last time beats what they say they would do.
• The transcript as source. Your notes during the call are an index; the transcript is the record. Mark the moments worth going back to with a time rather than trying to write them out.
• Conclusions separately. Write what you think it means in a different section, and say which quotes it rests on.

User research interview notes covers consent forms, templates and synthesis in detail.

Ask participants before recording, and tell them who will hear it. Research participants are often customers who agreed to help, and they are owed a clear explanation of what happens to their words. How to ask for consent to record has wording.

Stakeholder meetings: keep the decisions and why

Most stakeholder meetings produce one or two decisions and a lot of discussion. Six months later, the discussion is forgotten and the decision is questioned. What you need is:

• The decision, in one sentence.
• Who made it, and who was in the room.
• The options considered, briefly.
• The reason. This is the part that stops the same argument happening again.
• What would change it. "Revisit if enterprise customers ask for it" is a useful line.

Put each decision in a decision log with a link back to the meeting. When someone asks why the roadmap looks the way it does, the log answers in a minute.

A fictional example

The Harbour team meets to decide whether the 2.4 release includes offline mode.

**Decision:** Offline mode moves to 2.5. 2.4 ships the sync fixes only.
**Date:** 18 September 2026
**Decided by:** Ana Ruiz (product), with Tom Becker (engineering) and Marc Dubois (support)
**Options:** ship both in 2.4 and slip three weeks; ship sync fixes now, offline in 2.5
**Reason:** Support volume is driven by the sync bugs; Northwind's renewal depends on them, not on offline mode.
**Revisit if:** a second customer makes offline mode a renewal condition.
**Meeting:** Harbour planning, 18 Sept, 12:40 in the recording

Planning and cross-team meetings: owners and dates

Commitments between teams are where products slip. For each one, write who owes what to whom, by when. If a commitment was discussed but nobody took it, write that down as an open item rather than inventing an owner. Writing meeting action items that get done covers the format.

Escalations from sales and support

When a sales engineer or support lead brings a customer problem to you, ask for the customer's words, not a summary. If they have a recording of the call, the relevant two minutes are worth more than a page of notes. Meeting notes for sales engineers describes the template that makes these handovers useful.

Status meetings

Most need no notes beyond changes and blockers. If nothing changed, nothing needs writing down.

Keeping it all findable

A product manager's notes become useful when they can be searched together: "what did customers say about exports?" across twenty interviews and five support escalations. Group meetings by project or theme, keep them searchable by what was said, and link decisions to the meetings they came from.

How Notey fits into this

Notey is a Mac app that records your microphone and what your Mac plays as two separate tracks and transcribes them on the Mac with Apple's speech recognition. It does not join the call, so there is no bot in a research session to make a participant self-conscious. It shows its red dot and timer to you, not to them, so asking is still your job.

For product work, the useful parts are:

• Two tracks. Your questions are You, the participant's answers are Them, without anyone's voice being learned — useful when you are counting how much you talked.
• Search by what was said across every meeting with ⌘K, and play the moment a line was said.
• Projects to group a research round or a feature's meetings.
• Minutes when you ask for them. With an account, ask for minutes — what was discussed and decided, topic by topic, each marked with where it began in the recording — or a summary with action items. Only transcript text is sent, and everything the AI wrote is labelled.
• Export as Markdown, so quotes and decisions go into your research repository or wiki with the AI labels kept.

Notey does not share notes with your team or connect to your issue tracker. Export and paste. For the client-facing side of the same habits, see AI meeting notes for consultants.

Frequently asked questions

What meetings should a product manager take notes in?

Customer and research calls, where the exact words are evidence; stakeholder and planning meetings, where decisions and their reasons are what matter; and cross-team meetings, where commitments between teams get made. Status meetings rarely need more than a line.

Should I use AI summaries of user interviews?

As an index, not as the evidence. A summary helps you find the interviews worth rereading. Quotes and the conclusions you draw from them should come from the transcript, with the timestamp.

How do I record why a product decision was made?

Write the decision, the date, who made it, the options considered and the reason, and link to the meeting it came from. A decision log is the simplest way to keep these together.

Do I need consent to record a user interview?

Ask participants before recording, preferably in writing through a research consent form, and again at the start. Say what the recording is for, who will see it and how long it is kept.