Blog 6 min read

Why meeting summaries are not enough for product teams.

A summary records one meeting. Product teams need what is true across all of them. Here is where recaps break, what to keep instead, and where an AI assistant fits.

CK
CK
Product manager, and the human FAQ before this existed
Left: three dated meeting recaps fading out, captioned 'three documents nobody opens twice'. Right: one Onboarding thread in Wisibl showing a question asked on March 4, a decision on March 19, and a result measured on April 2, kept together.
The same three meetings, twice. On the left, three recaps filed by date. On the right, one thread filed by product area.
The short answer

A meeting summary is a record of one meeting, filed by date. Product knowledge is a thread that runs across many meetings, organised by the part of the product it concerns. Summaries capture the first thing well and the second thing not at all, which is why a team can have a recap of every meeting and still be unable to answer "what did we decide about this, and why?"

What to take from this
  • Recaps are filed by date. Questions arrive by topic. That mismatch is the whole problem.
  • A summary keeps the decision and drops the reasoning, which is the part people ask for six weeks later.
  • Nobody edits a recap after the meeting, so open questions stay "open" forever in the document, even after they are answered.
  • What to keep instead: decisions with reasons, open questions with status, requests counted, all filed by product area and pointing back to the source.

The notetaker has done its job. Every meeting now ends with a recap in your inbox: attendees, key points, action items. Nobody argues with that. It beat the alternative, which was one person typing while pretending to listen.

Three months in, something is off. The recaps pile up. The questions keep coming. And the answer to "what did we decide about the permissions model?" is still: let me check. The problem is not the summaries. The problem is what a summary is.

A summary is a photograph of one meeting

A recap describes a moment. It is indexed by the date it happened, it is self-contained, and it is finished the second the meeting ends. That is exactly what you want from a record.

Product knowledge is not a moment. It is a thread. Take a real shape of one:

One question, three meetings
Mar 4Growth sync. "Where does activation drop off?" Lena thinks it is the profile step. Open question.
Mar 19Standup. Decision: collapse the profile step into step two. Lena owns it.
Apr 2Quarterly review. Week-one activation moved from 41% to 58%. The change worked.

That is one story. Your notetaker produced three recaps, in three files, with no line between them. To answer "did collapsing the profile step work?" someone opens three documents and does the joining in their head. The tool did precisely what it was asked to do. Nobody asked it to remember.

Where summaries break, specifically

They file by date, but questions arrive by topic

Nobody asks "what happened on March 19?" They ask about permissions, or billing, or the onboarding flow. So the first act of finding anything is remembering when it was said, which is the thing you were trying not to have to remember.

They flatten why into what

"Decision: collapse the profile step into step two." Fine. Six weeks later engineering asks why, because they want to add a field back. The recap has the decision. The reasoning was in the four minutes before it, and the summary compressed those four minutes to one line.

They cannot see across meetings

A question raised on March 4 and answered on March 19 will say "open" in the March 4 recap forever. Nobody goes back to edit recaps. So the document that a new teammate finds first is the one that is wrong.

They decay silently

A recap is accurate on the day it is written, and it has no way of knowing when it stops being accurate. A wiki page has the same flaw; it is just slower to write.

They produce more documents

The promise was less writing. The result is one document per meeting that nobody opens twice, plus a person whose job quietly becomes "the one who knows which document."

What product teams actually need to keep

Three things, and only three.

  • Decisions, with the reason and the sourceNot just what was decided, but the two sentences of why, and a pointer to the moment it was said.
  • Open questions, with their current statusA question is a first-class object. It gets raised, it gets answered, sometimes it gets reopened. It should carry that state with it.
  • Requests, counted and attributed"Sales has asked for a read-only role seven times since March" is information. "A prospect mentioned roles" three times in three recaps is noise.

All of it filed by product area, not by date, because that is how questions arrive. And all of it pointing back to the source, because a memory system that cannot show where it got something is a rumour with better formatting.

What this looks like without a tool

You can do a version of this by hand. A decision log per product area. A running list of open questions with an owner. A habit of writing "because" next to every decision, and a link to the recording timestamp. Small teams with discipline make this work for a while.

It breaks at a predictable point: when one person becomes the only one who updates it. At that moment the product manager is the human FAQ again, with extra steps.

Where an assistant fits

This is the gap Wisibl was built for. It sits on top of the notetaker rather than replacing it. Fireflies transcripts and uploaded documents go in; Wisibl reads every line, works out which part of the product each item belongs to, and files decisions, open questions, risks, and customer requests under that product area. When a question raised in one meeting is answered in another, the two are linked. When someone asks a question, the answer comes back with its source, and if there is no source, Wisibl says so instead of guessing.

One conversation, start to finish: the transcript is read, filed by product area, and four teams get answers with sources.

It is single-user today, it works with Fireflies and transcript upload, and there is a free plan. It does not write your recaps. Keep the notetaker for that.

Keep the summaries. They are a fine record of what happened. Just do not ask them to be your memory.

Questions people ask

Should I stop using a meeting notetaker?
No. Notetakers are good at what they do: a record of one meeting. Keep it. The problem starts when that record is the only place product knowledge lives, because recaps are filed by date and nobody edits them later.
What should product teams keep from meetings?
Three things, filed by product area rather than by date: decisions with the reason and the source, open questions with their current status, and customer requests counted and attributed. Each should point back to the moment it was said.
How is Wisibl different from a meeting summary?
Wisibl sits on top of the notetaker. It reads transcripts and documents, files what it finds by product area, links related items across meetings, and answers questions with the source attached. It declines rather than guessing when it has no source.

See the thread instead of the recaps.

Add one meeting. Ask one question. Every answer comes with its source.

Hire Wisibl
Related
Meeting notes tools vs product knowledge platforms: which one does your team need?What each one stores, when a notes tool is enough, and why most teams run both. AI assistant for product teams: what it should do, and how to test one in ten minutesWhat the phrase should mean, five tests to run before you buy, and how Wisibl does on each. Half the loop is deciding the same thing twiceWhere the repeats in the loop come from, and what keeping a decision once actually means.
CK
CK

Product manager who spent years being the person everyone messaged for context. Wisibl is the tool they wanted instead.

Last updated . We revisit posts when the product or the advice changes.