How I Use NotebookLM for Talk Preparation

TL;DR

Before a panel at the Vienna Software Architecture Meetup I had a long preparation document: written-out answers, set pieces, a dossier on the other panelists. Instead of reading it one last time, I used NotebookLM to generate audio from it and listened on the way there. The result: more effective than reading, because I played the material through passively and immediately heard where my reasoning had gaps. Here is the workflow in five steps -- and, honestly, its limits too.

The Problem: Reading Checks the Wrong Thing

When you prepare a talk or a panel, you often end up writing yourself a document. For me, before the Vienna Software Architecture Meetup, that was a longer file: a 30-second intro, eight written-out answers to the lead questions, two set pieces as anecdotes, plus a dossier on the fellow panelists.

Writing that document is where the real value sits. That is where I think the arguments through. But reading it shortly before the event turns out to help surprisingly little. You skim your own sentences, nod internally ("yes, I know this") and fail to notice where the reasoning is actually thin. The eye is too fast. It recognizes familiar text instead of testing it.

What I was missing was a format that forces me to listen -- at the speed I will later have to speak.

The Workflow in Five Steps

The core is genuinely simple. Google's NotebookLM can generate an "Audio Overview" from uploaded sources: two synthetic voices that walk through the content in a conversational format. That is exactly what I applied to my prep doc.

Step 1: Upload the source. Create a new notebook in NotebookLM and add the preparation document as a source. Markdown, PDF, or just pasting the text -- all of it works. I take precisely the document I already wrote. No extra preparation.

Step 2: Generate the Audio Overview. Trigger the "Audio Overview" feature. NotebookLM turns it into a conversation between two voices that explain, contextualize, and pick apart the material. This takes a few minutes.

Step 3: Steer it (optional). Before generating, you can narrow the focus with a prompt -- something like "concentrate on the arguments about SDLC governance and supervising in production." This helps when the document is broad and you only want to hear part of it.

Step 4: Download and take it with you. Save the finished audio as a file on your phone. For me it lands in my usual podcast app so I can play it offline and pause it.

Step 5: Listen on the way there. That is exactly what I did: on the train to the venue I played my own material through once, in full. Not reading -- listening.

Why This Works Better Than Reading

The effect was surprisingly clear for me. Three reasons:

• Passive playback exposes gaps. When an external voice delivers my reasoning, I immediately hear where there is a leap in logic or a missing piece of evidence. When reading my own text, the brain fills the gap unconsciously. When listening, it does not.
• The pace matches reality. A panel runs at speaking speed, not reading speed. If you have heard your material, you have processed it roughly at the tempo at which you will later have to recall it.
• It uses dead time. The commute is there anyway. Instead of nervously staring at my phone, the final repetition runs alongside.

Reading checks whether the text is there. Listening checks whether the argument holds.

At the panel itself this paid off. I argued a deliberately polarizing position -- that the real problem is not the pace of AI development but the widening gap between what is technically possible and what guardrail-bound organizations allow. Having heard that reasoning once, rather than only read it, gave me noticeably more confidence in the live exchange.

The Honest Limits

So there is no false impression: this is a small trick, not a miracle. A few things worth knowing.

It does not replace thinking. The audio is only as good as the document you feed it. The work -- finding the arguments, ordering them, anticipating the counter-position -- happens beforehand, while writing. NotebookLM does not turn that into new substance; it only mirrors what is already there in a different format.

The voices simplify. The Audio Overview style tends to smooth things over and sound enthusiastic. Fine nuances, caveats, the exact wording of a punchline -- some of that gets lost in the chatty tone. For the final polish of individual phrasings, the original document is and remains the source.

Verify the facts yourself. As with any generative AI: do not trust it blindly. If the audio states a number or a connection, I check it against my document when in doubt. Listening is repetition, not verification.

Mind language and privacy. The document gets uploaded to Google. For a public talk script that is harmless; for confidential content you should think carefully about what you feed in.

AI is a tool here too -- useful, but not magical. The value lies in getting a format switch almost for free. And a format switch is often exactly what makes the difference when learning and revising.

Conclusion

The whole workflow fits in one sentence: work through it actively, then convert it into an audible format, then play it back passively so the gaps stand out.

1. Write actively. The prep document is and remains the real work.
2. Convert to audio. A NotebookLM Audio Overview from exactly that document.
3. Listen passively. On the way there, at speaking speed, once in full.
4. Note the gaps. Whatever sounds bumpy when heard, sharpen it before the event.

It is no magic and costs almost no extra effort. If you want to go deeper into how to deliberately build context for workflows like this, you will find the details in Harness Design: Keeping AI Coding Agents Productive.

I share small workflows like this regularly. If you do not want to miss them, the free handout and the newsletter are at agenticbuilders.at -- that is where I collect the methods that have proven themselves in practice.