How to take meeting notes

Taking notes is something you've most likely done since high school. And yet, your note-taking strategy may be all wrong.

I've seen product and project managers take incomprehensible, useless meeting notes. This is not what we want to do as product managers! We need our meeting notes to be clear, concise, and accessible for both other PMs and engineers.

take meeting notes.jpg

Completed & distributed meeting notes should contain 5 items: 

  • Purpose of the meeting. Make it short and sweet - no longer than one line. Document it at the top of your notes.
  • Discussion points. Bullet points, people. NO ONE wants to read full, lengthy sentences. (No one will read full, lengthy sentences.) Be as concise as possible.
  • Use Cases. If any specific use cases were discussed, document them. This gives the notes context, and will enable note-readers to quickly remember the meeting.
  • Decisions made. The point of a meeting is to make decisions. If decisions are made in a meeting, write down what decision was made, and who agreed to it. This has saved my ass several times. Do not skip this part.
  • Action items + assignees + dates. This is very important. What came out of the meeting? What are the follow-ups? Who is responsible for them? By when? Seems simple, but we've all lived through meetings that drag on for hours, with little or no resolution or follow-ups items, leaving us wondering what the hell we just decided.
 Check out this product manager, taking them badass notes in an organized fashion!

Check out this product manager, taking them badass notes in an organized fashion!

Once compiled, send out meeting notes to all attendees, and ask for any edits. This acts as a public record of decisions made, and action items. 

If you're having trouble extracting or documenting important information during fast-paced meetings, try these other nuggets of advice: 

  1. Don't be afraid to interrupt to ask for clarification, or ask if what you've written down is correct.
    "Sorry Juan, did you say it's our team that needs to re-generate the CQL queries for the rules present in the DB and update them in the OCEP processor?" <-- valid question!
    Sometimes devs will spit out long sentences of seemingly unreal words in rapid succession. Do not fret! Write down what you can, and ask if what you've notated is correct. These interruptions will be annoying at first, but you'll learn a lot, and over time you'll get a lot better at understanding without clarification. 

  2. Recap your notes at the end of the meeting.
    Everyone will be eager to leave, but if done quickly, this exercise will take one minute. If you have less than a minute (or a particularly anxious crowd), recap action items only.

  3. Don't be afraid to ask 'why'.
    If your meeting is technical in nature, business may ask further questions when your engineers aren't there. Make sure you understand enough to regurgitate the gist of what decisions were made. This may mean asking your engineers "why are we doing X?"