Read less. Hear more.

The thought

There is a part of workshop preparation that rarely appears on the run sheet: learning the problem space. Before I can design useful questions, activities or decisions, I often need to get far enough inside somebody else's context to understand the language, the tensions and the things that are genuinely difficult.

That can mean a lot of material. A sponsor or design team might send internal strategy papers, technical reports, previous workshop outputs, websites, Word documents or books. The content can be unfamiliar and dense, and the expectation is often that I absorb it quickly while still doing the rest of the job — delivering other workshops, preparing the room, working through logistics and, like most people, having a life outside work.

I kept finding the same bottleneck: the material was useful, but the uninterrupted hours needed to read it properly were hard to find.

Over a couple of days I built a small AI podcast tool. I can give it PDFs, web pages and documents and ask it to first understand the source pack: identify themes, patterns, points of tension, decisions, competing arguments and areas worth questioning. From there it creates a conversation between two or three speakers and turns that conversation into audio.

The intention was never “450 pages become 20 minutes, therefore I have read the report.” That would be a dangerous shortcut. The intention was to create another learning surface — something that could help me build a map of unfamiliar territory while walking, driving or doing the less cognitively demanding parts of my day, and then tell me where to go back into the original source when something deserved more attention.

I know tools that create podcasts from source material already exist. Building my own was partly curiosity, but control mattered too. I wanted to experiment with the roles the speakers played, the kinds of questions they asked, the voices and accents, the rhythm of the discussion, how much challenge appeared in the conversation and, eventually, whether every important point could show me the source it came from.

Why it helps

The obvious benefit is time. Audio lets some knowledge transfer happen in parts of the day where reading simply will not. But the more interesting benefit was that a conversation did something a conventional summary did not.

One speaker could state the apparent conclusion. Another could question it. A third could connect it to a different source or ask what it might mean in practice. That small amount of friction made the material feel less like compressed information and more like thinking I could participate in.

My earliest versions were technically fine and surprisingly unpleasant to listen to. Speaker one would talk for close to a minute. Pause. Speaker two would take a turn. Pause. Speaker three would follow. It was orderly, clear and completely lifeless.

Shorter turns made a difference. So did different voice qualities, occasional overlap, a challenge arriving before the previous thought had completely settled, and small natural imperfections — an “um”, a “right”, a “hang on”. I did not need the speakers to pretend to be human. I did need the listening experience to have enough rhythm and variation that my attention stayed with it.

I tested the tool with a roughly 450-page PDF. The podcast sounded informed. It had detail, examples and a coherent narrative. As an experiment, I changed the tool so I could see the generated transcript alongside the exact source pages supporting each part.

That changed everything. Almost the entire episode was being built from a narrow part of the document — roughly pages 190 to 220. The tool had depth, but nowhere near enough breadth. And because the output sounded fluent, I could easily have mistaken “detailed” for “representative”.

That led to a redesign of the ingestion step. Instead of finding useful chunks and immediately writing from them, the tool first maps the document, deliberately allocates attention across sections, checks coverage and balances multiple uploaded sources before the script is written.

Try it in the room

For this one, the useful work happens before anybody walks into the room. I would treat it as a learning loop rather than a document-to-podcast conversion.

• Build the source pack deliberately. Include the documents the sponsor thinks matter, but also the material that brings another perspective: previous decisions, external context, contradictory evidence or the source everyone keeps referring to.
• Map before you summarise. Ask for the major themes, tensions, decisions, unanswered questions and structure of the material before generating a narrative from it.
• Make evidence visible. Keep the transcript and attach source names and page references to important claims. The ability to inspect the answer is more useful than a confident voice telling you it is correct.
• Audit breadth. With a long document, look at which pages or sections are actually being used. With several documents, check whether one source is quietly dominating the others.
• Design the speakers. Give them different jobs. One might explain, another challenge assumptions, another keep asking “so what does this mean for the workshop?” Different roles are more useful than three voices simply taking turns summarising.
• Design for listening. Shorter exchanges, changes in pace and enough conversational texture can make dense material easier to stay with. Natural does not have to mean theatrical.
• Capture questions, not just answers. While listening, note the things you want to test with the sponsor, the words you need clarified and the tensions that might deserve space in the workshop.
• Go back to the source. When something matters, use the reference and read that section properly. The podcast is an entry point, not permission to stop reading altogether.

Source material → conversation → better questions → better room.

Watch for

The main danger is not that the podcast will obviously fail. It is that it will sound good enough to trust too quickly.

• Fluency can disguise missing coverage. A polished episode built from 30 pages of a 450-page document is still built from 30 pages.
• Compression has a cost. Twenty minutes of audio cannot preserve every nuance, caveat or argument in a large source pack. Decide what the podcast is for and what it is allowed to leave out.
• References need checking. A page tag is useful only if it genuinely supports what the speaker is saying. Sampling the links back to source is part of the quality check.
• Internal material needs appropriate handling. Confidentiality, permissions and where content is processed matter just as much here as they do with any other AI workflow.
• Naturalness can become noise. A few interruptions and hesitations can make audio feel alive. Too many become an affectation and get between the listener and the material.
• There is a real generation cost. My version is deliberately not public at this point. Creating multi-speaker audio uses paid AI services, and I do not want an experiment accidentally becoming an open-ended compute bill.

The most useful outcome for me has not been a podcast library. It has been a better way of thinking about workshop preparation. Knowledge uplift is part of the design work. If I can make that learning more accessible without losing the ability to interrogate the source, I arrive in the room with better questions — and usually a much better sense of what the room actually needs to do.