Why nobody reads your meeting notes, and what to write instead

Write for the person who was not in the room

For about a year our meeting notes were transcripts. Someone typed while people talked, and the result was forty pages a month that read like a courtroom record. Then a colleague joined in autumn and asked a simple question: why had we rejected weekly email digests? The decision was in there somewhere. Nobody could find it, and two of the three people who made it had forgotten the reason.

That is the test I now use for every note: would a person who was absent understand what happened and why? Not what was said, in order. What happened. A list of names and a date is a record of attendance, not an explanation.

The note starts with the question the group needed to answer and the material it looked at. If there was a brief or a previous decision, link it. A reader should be able to climb back to the context in one click rather than reconstruct it from memory.

Four headings, and the fourth is the one that matters

Our template is four headings: Context, Decisions, Open questions, Follow-up. Context says why the meeting happened at all. Decisions says what was agreed and the reason. Open questions keeps the uncertainty visible instead of hiding it behind a vague “we will see”. Follow-up is a checklist with names.

Open questions is the heading people resist. It feels like admitting the meeting failed. In practice it is the most honest part of the note, and the one the next meeting opens with. “We do not know whether the digest problem is frequency or content” is more useful than a confident paragraph that pretends we do.

Follow-up gets a checklist in the same note, not a separate task tracker nobody opens. “Oleh checks the unsubscribe numbers for the last two months” is a line that can be ticked. “Investigate churn” is not. When the checklist is done, the note is done, and we can archive it with a clear conscience.

A decision you can argue with later

Compare two versions of the same decision. “Improve onboarding.” And: “For the next test, put the import guide next to the empty notebook, because three new users asked where to start.” The first is a wish. The second has a scope, a reason, and a way to find out whether it worked.

The reason is the part that gets lost first. Six months on, the decision itself is visible in the product, but the reason lives only in someone’s head. Keep rejected alternatives too when they are likely to come back. One line each: “Weekly digest rejected: the two users who asked for it both wanted alerts, not summaries.” That sentence saved us a repeat conversation in spring.

I used to think this was too much writing for a thirty-minute meeting. Then I measured it. A decision with a reason and one rejected alternative is about forty words. The repeat meeting it prevents is thirty minutes of four people.

Correct the note, not the chat

Share the note in the project notebook within a day and ask people to correct the decisions, not to proofread the prose. The fastest way to kill the habit is to make the review feel like editing. A comment on the note is enough for a clarification. If the clarification changes what was agreed, the main text gets updated and the comment stays as the trail.

What goes wrong without this: the clarification lands in a chat thread, the note stays wrong, and in two months the tidy document and the messy thread disagree. New people read the document. They are confidently misinformed.

At the next meeting, open with the previous note’s open questions. Thirty seconds. It is the cheapest way I know to make people believe the notes are read, and once they believe that, they start writing them properly.

A worked example: the import review with Oleh

Here is what such a note looks like. Title: “Research review, first-time import”. Context: Oleh ran three sessions last week watching people import their notes for the first time; the question was where they hesitate. Evidence: links to the three session summaries, with observed behavior kept apart from what participants said about it. Two people paused at the file picker; all three said afterwards that the picker was “fine”.

Decisions: test a clearer description of supported file types next to the import control. Reason: the hesitation happened before anyone chose a file, so the problem is probably not the picker but not knowing what it accepts. Rejected: a video walkthrough, because nobody in the sessions looked for help at that moment. Open questions: does the same pause happen with a Markdown ZIP, or only with ENEX?

Follow-up, as a checklist: Oleh drafts the new description by Wednesday; Maria runs two more sessions with a Markdown ZIP the week after. Backlink to the “Import” notebook so anyone working on it sees this note in the list. The whole thing is about 180 words. It took Oleh twelve minutes, and it answered three questions people asked over the following month without anyone pinging him.

Check the record before you trust it

Before a note counts as agreed, ask the people who were there whether the decision and its limits match what they remember. This is where notes quietly drift. One participant remembers “we will try it if the numbers support it” and the note says “we will do it”. Fix that in the main text, not in a reply.

If there was no agreement, say so. “No decision; open question stays open until Oleh’s numbers come in” is a legitimate outcome of a meeting. Pretending otherwise produces decisions nobody made, and those are the ones that get undone loudest.

For a recurring meeting, link each note from the previous one and keep them in the same notebook, so the chain reads in order. I would rather have six honest notes that admit what we did not know than one polished summary. The honest ones are what the new colleague actually needed.

Where to go next

Find it again in a year

Learning and research: from sixty saved papers to one argument