How NotebookLM Was Made

A textbook after a full day of work

Raiza Martin had attended college while working full time. When she encountered a prototype for asking questions of personal documents, she pictured talking to a textbook when she was tired after work. College students, particularly adult learners, immediately understood its value. That study problem helped shape [NotebookLM](https://notebooklm.google.com/): a workspace for bringing in sources, asking questions, and creating new outputs from them.

In the October 2024 Latent Space conversation, Martin introduced herself as NotebookLM’s lead within Google Labs. The capabilities, limits, and roadmap plans discussed below describe that period. She had worked in ads and payments before leading [AI Test Kitchen](https://aitestkitchen.withgoogle.com/), which she recalled being announced or launched at Google I/O 2022. Her manager encouraged her to turn technology demonstrations into practical products. Usama Shafqat’s route ran through data-center supply-chain planning and a creator-commerce project at Area 120 before he joined Labs’ work on new AI products.

The prototype Martin encountered in October 2022 was Talk to Small Corpus, built by an engineer named Adam to let a large language model converse with a user’s data. Martin characterized it as retrieval-augmented generation; its name reflected how much material the team thought it could handle well. As competing chat-with-PDF tools appeared, she wanted to launch sooner and learn faster from users.

Before the 2023 I/O announcement, studies revealed a recurring first request: summarize the document. Martin saw this partly as a capability test by people who already knew the material. The early Project Tailwind product combined text-based questions and answers with automatic summaries and support for roughly ten documents. She also recalled key-topic generation, but was unsure whether it appeared in the initial release.

Learning what to add—and retire

After the demo, the team built a waitlist and a Discord community for immediate reactions and follow-up questions. Feedback informed note saving, note writing, and generated follow-up questions. NotebookLM later removed the waitlist, expanded across the United States and then to more than 200 countries and territories, and added language support for its interface and sources.

Unexpected adoption in Japan demonstrated the value of separating source language from conversation language: users could ask questions in Japanese about rules written in English. The same flexibility could make difficult prose more approachable. One participant regularly asked plain-language questions about The Wealth of Nations and found that the explanations adapted to their tone—a personal assessment, rather than a measured evaluation.

Discord also surfaced failures, with the team recalling outage reports arriving faster than its monitoring. More revealing were users who persisted despite trouble: their circumstances explained why a task mattered enough to keep trying. Those conversations helped distinguish valuable functionality from features that had not resonated.

That learning included removing features. A tool for highlighting and transforming source passages saw little use while adding architectural complexity. The team was running a 50/50 sunset experiment and had received no complaints so far, though its duration and sample size were unspecified. Feature exposure mostly used Mendel experiments. In one incident, someone bypassed the flags and posted unreleased functionality on Twitter; the bypass mechanism was not explained.

Turning documents into conversations

The audio experiment began outside NotebookLM, with a question about content transformation: how could source material become something people wanted to listen to? Simply narrating on-screen text seemed insufficient. The team explored a two-person conversation, developing an almost separate engineering pipeline that was subsequently integrated into NotebookLM.

The central step was an editorial transformation. A résumé or long slide deck became a discussion with interpretations, questions, and an unfolding explanation. Two personas approached the material from different angles, unpacking dense information through their exchange. The team described this as resembling a model prompting itself—an analogy for the interaction, rather than a specification of the deployed architecture.

The system paired Gemini 1.5’s ability to absorb long inputs with audio techniques developed alongside DeepMind’s audio team. The team had tried both - a single model writing a conversation for text-to-speech - and separate persona prompts producing an exchange step by step. Both had tradeoffs. Generation involved substantial inference and multiple operations; the production architecture, speech model, call count, latency, and cost were not disclosed.

Distinct perspectives and conversational imperfections helped prevent two voices from delivering essentially the same answer. Some users reported discovering new insights in discussions of their own journals or books. Surprise became part of the appeal: uploading a résumé created anticipation about what the conversation would say. Requests for more control introduced a tension between that surprise and predictable results.

Making an expert workflow accessible

Steven Johnson joined the project early with the ambition of building a tool to help him think. His research, note-taking, self-questioning, and reflection gave the team a concrete workflow to learn from. The product direction was to make some of that research and analysis expertise accessible to everyday users, including product managers.

Watching Johnson work revealed different things from interviewing him. A team member used both methods, and similarly observed students’ study decisions and frustrations. Before there was a usable product, Johnson described what he wanted; afterward, he pushed its features to their limits. The team then tested whether those directions would also serve less specialized users.

One demonstration analyzed PDFs of handwritten Marie Curie notes for a writing project. NotebookLM could recognize content in image-only PDFs, although the example came without an accuracy measurement. It also exposed a discoverability gap: a teammate could understand Johnson’s application once shown, yet doubted they would have discovered it independently. Making the capability easier to find was part of the product work.

Sources, capabilities, outputs

The roadmap had three parts: - Sources: the material users bring in. - Capabilities: what they can do with it. - Outputs: what they create and put back into the world. Questions often served a larger task: users interrogated sources because they were making something new. Shared notebooks and one-click document creation were proposed directions, with matching a user’s style, brand, and guidelines identified as the harder output requirement.

Input support remained uneven. Despite the handwritten-PDF demonstration, gaps remained around handwriting, DOCX, PowerPoint, and documents mixing text with images. The team fed those problems back to the modeling team. NotebookLM was described as accepting up to 50 sources of 500,000 words each, too much to fit into the model’s context window at once. Handling that collection across text and images remained an unresolved engineering problem; no detailed retrieval design was presented.

Natural audio delivery depended on script generation and speech modeling together. Audio models reproduced intonation, breathing, pauses, and laughter, while generated text signaled where those behaviors made sense. Uploaded audio took a different path: transcription discarded vocal and emotional information. Annotations in uploaded text might influence the output, but still through Deep Dive, the sole audio format available at the time.

Deep Dive was an upbeat general overview, sometimes finding a positive framing even for sad material. Its enthusiasm also supported a personal encouragement use case: users uploaded profiles, and Google employees generated discussions of quarterly accomplishments that reportedly boosted confidence before manager meetings. A founder used the same transformation diagnostically, listening to a discussion of a landing page to assess whether its value proposition came through.

Listening first, formalizing quality second

Audio development began with extensive internal listening and a deliberately high quality bar before formal rater evaluations. The team improved both transcript generation and the audio model, using side-by-side transcript comparisons along the way. One comparison file, jokingly titled Potatoes for Chefs, became an internal reference.

The approach was to 1. reject obviously unsatisfying audio through listening, 2. iterate until it felt impressive, 3. and then validate that judgment formally. Raters scored multiple dimensions, breaking entertainment into several factors. The team did not specify the factors or scale endpoints. This was a case for opinionated product judgment, without a measured development speedup.

Continued listening served another purpose: preserving engagement while improving factuality. Reducing invented or insensitive content and strengthening narrative coherence still had to leave something people wanted to hear. The team assessed those qualities together throughout development.

The narrow format made evaluation more manageable. Users largely selected sources and pressed a button; the team assessed entertainment, consistency, groundedness, and adherence to Deep Dive’s structure. Preprocessing and the prescribed format helped constrain variation. Poor overviews still occurred, and following the format could not guarantee that a listener would like the result. The team did not specify how many generations it sampled to evaluate that variability.

Personality, tension, and the order of information

Deep Dive combined several teammates’ editorial judgments, with Usama described as its strongest editorial voice. Steven was credited with the decision to leave the hosts unnamed. A character designer helped shape the two speakers alongside the dialogue format. Their recurring personalities became recognizable enough to raise another product question: did users want to edit them, or choose among more personas?

A participant’s attempt to build a similar product illustrated a failure mode. Detailed backstories about education, work, and hobbies kept surfacing in the conversation. Giving a speaker a personality required more subtlety than supplying a biography the model would repeatedly recite.

The audio-design account emphasized structure, tension, and gradual disclosure. Dialogue needed a destination; too much agreement flattened it. Where an article might state an outcome immediately, the conversation could reveal information gradually, introduce differing interpretations, explore a subtopic, and return to the main narrative. That pacing mattered especially when listeners were driving or otherwise unable to skim.

Interjections, acknowledgments, and follow-up questions added conversational texture. The generated presentation had to sustain interest itself, whereas users often supplied the entertainment in chatbot interactions by testing or trying to trick the model. The team had not yet invested in audio-format specialists; future involvement would depend on the experience it wanted to improve.

Humor sometimes emerged without an explicit instruction to be funny. In an inserted audio example about a paper whose title repeated the word chicken, the generated discussion compared its chicken content to a KFC buffet. The team viewed humor as highly contextual. Its understanding of actual usage was still preliminary: participants estimated that the audio launch had occurred only two or three weeks earlier.

Letting the recipient choose the format

Personal sources gave audio a built-in reason to matter. A mortgage deed might be dry, but its owner had a reason to understand it. Participants discussed retirement-plan comparisons, a woman listening to an adaptation of her diary from 2004, and early experiments with Mountain View city council meeting notes. Such material could become personally useful audio without needing a broad audience.

The larger possibility was moving control of presentation from sender to recipient. Someone receiving a hundred-slide deck could prefer a sixteen-minute audio overview for the drive home—an illustrative use case, not a measured conversion. The discussion extended that idea to media regenerated for individual tastes, a possibility rather than an existing NotebookLM feature.

Asked when to implement behavior explicitly in code and when to rely on prompts, the response began with the desired outcome: delight, task completion, a simpler workflow, less engineering friction, or exceptional output quality. The choice required product judgment along a spectrum. A clear view of user value was presented as more durable than designing around today’s model limits, given the expectation that capabilities would improve.

Every control creates a quality obligation

The team saw room for developer access alongside the end-user product, but offered no API readiness date. More languages were a priority, supported by separate speech and modeling teams. Broad coverage was considered possible, though the speaker explicitly withdrew confidence in the suggested timing.

Early French tests showed why producing a language was only part of the work: speech could drift between Canadian French, French as spoken in France, and an American accent. Maintaining the intended dialect required further quality work. Fixed dialect selection, personal voice contributions, and additional voice choices remained potential capabilities, without an established contribution mechanism or stated training-data requirements.

Users were already steering audio through notebook titles and fabricated show notes, sometimes changing its framing or language. Those less-tested workarounds motivated consideration of an instruction text box. System-prompt customization for core NotebookLM was also under investigation, while audio controls were expected to arrive in stages.

Mockups full of requested controls made one team member appreciate the one-button experience more. The challenge was to preserve its simplicity while adding the options people most wanted. Beneath that interface decision was an engineering cost: exposing a parameter does not make its behavior reliable. Each control could require repeating the quality-development process, and arbitrary instructions made evaluation harder than assessing one prescribed format.

The workspace beyond audio

Early signals suggested that audio attracted users while other NotebookLM features helped retain them. The team wanted more data before treating that as a durable pattern. Its larger commercial thesis remained the workspace: bring sources, work with them, and create outputs. Audio was one output modality within it.

In discussing Claude Artifacts and ChatGPT Canvas, a team member favored separating the conversation from the artifact being created. NotebookLM had explored drafting-interface mockups for about a year but prioritized audio as an area where it could deliver distinctive value. Drafting would need its own clear utility. That was the shipping bar: imperfect scrollbars were acceptable, while even a fast-follow feature needed to be useful.

The smaller team first concentrated on proving a complete journey from sources through chat to output. That clarified where to invest in engineering before broadening inputs, outputs, and chat capabilities. Code was an important direction. A participant had already seen one or two people upload downloaded GitHub repositories for audio explanations, despite the product not being packaged specifically for code.

A student’s homework session brought the story back to learning. Observed with her permission, she uploaded computer-science assignment instructions, pasted her code, and asked NotebookLM to check it. When it flagged an answer as wrong, she requested guidance without the answer because she wanted to learn the material for a later quiz. NotebookLM suggested considering an integer, though its formatting was imperfect. Understanding her motivation explained what useful assistance meant in that session.

Interactive audio was being prioritized, but its purpose remained open: answering notebook questions, changing the show, or joining the conversation. A participant separately described real-time voice interaction as difficult and judged interruption handling in OpenAI’s recently launched API imperfect, without measurements. The product question was what participation would add to the existing experience.

Build at the boundary, then help users begin

The closing invitation was to try NotebookLM, join its Discord, and share feedback beyond requests for an API. The team wanted to know what people did, why it helped, whether it remained useful the next day or week, and why they continued or stopped. Those motivations would guide development beyond the initial excitement.

The advice to AI product managers was build enough to earn conviction: try other products and APIs, make prototypes, and test the experience yourself. Another participant encouraged working near the limits of model capability and showing prototypes to others before declaring a ceiling. A fresh perspective could reveal a way forward.

For engineers, a participant recommended combining multiple models and allowing more thinking time when a task failed initially, based on consistently better results in their own work. That was experiential advice, without a benchmark or orchestration recipe. The complementary product principle was clear: decide what users should be able to do, and help them begin. An interface that accepts anything can still leave someone unsure what to type.

The final operational detail was repeated requests for more compute capacity; an Elmo-on-fire reference had doubled as a public nudge for additional resources. The closing commitment was continued iteration: keep trying to make NotebookLM better.