O acidente que virou produto
Em meados de 2022, Jeff Dean tinha um problema pequeno e chato: papers demais chegando rápido demais. Dean é o engenheiro que co-criou o MapReduce e o TensorFlow, um dos nomes mais respeitados na história da computação. O que ele queria era simples: ouvir um resumo dos artigos que saíam todo dia no campo de IA durante o caminho para o trabalho. Não ler, apenas ouvir.
A ideia foi parar nas mãos de uma equipe do Google Labs que já trabalhava numa outra direção: uma ferramenta de pesquisa ancorada nos documentos do próprio usuário. Os dois impulsos se juntaram. O que surgiu foi o NotebookLM, que começou com seis semanas de desenvolvimento, quatro ou cinco pessoas, e nenhum roadmap de produto formal. O nome original era Project Tailwind, que a propósito era claramente um nome ruim comercialmente falando.
O produto ficou dois anos como experimento interno antes de virar algo público. Cresceu dentro do Google porque os próprios funcionários o usavam: para transcrições de reunião, para organizar anotações, para processar entrevistas longas antes de escrever. Dezenas de milhares de usuários ativos mensais só dentro da empresa antes de qualquer lançamento externo. Esse uso interno funcionou como pesquisa de produto sem ter sido desenhado pra isso.
O que detonou o produto para o mundo foi uma feature que também não estava no plano original. A equipe adicionou os Audio Overviews em setembro de 2024: você sobe seus documentos e o produto gera um podcast com dois apresentadores discutindo o conteúdo. Em outubro de 2024, o tráfego do NotebookLM cresceu 371% num único mês, chegando a 3 milhões de visitas mensais. Em novembro de 2025, os usuários ativos mensais via web tinham mais que dobrado ano a ano, e o app mobile lançado em maio de 2025 acumulou 8 milhões de usuários ativos mensais.
Ninguém pesquisou se o mercado queria um podcast gerado por IA. Jeff Dean queria ouvir papers no carro. Isso foi suficiente.
A diferença entre essa história e a história de um produto construído dentro de um processo de OKR convencional é o ponto de partida. No processo convencional, você começa com uma lacuna de mercado, constrói uma hipótese, valida com usuários, define métricas de sucesso e só então começa a construir. No NotebookLM, o ponto de partida foi uma necessidade real de uma pessoa real dentro da empresa. Não havia métrica de sucesso porque não havia problema definido com precisão. A equipe estava respondendo a uma necessidade que ela mesma entendia porque vivia aquele contexto.
🚨6 aulas gratuitas com pessoas de produto do iFood, Nubank e Pipefy.
Ao vivo, com certificado, sem pagar nada. A PM3 tá fazendo uma maratona em março pra comemorar o aniversário deles. Acesse aqui.
Isso não é argumento contra processos, já que times sem processo produzem caos, não produtos. O problema com o OKR como ferramenta de inovação é diferente: ele mede bem o que já é conhecido e mensurável. “Aumentar retenção em 10%”, “crescer DAU em 20%”, “reduzir churn de usuários pagantes” são todos objetivos razoáveis de produto. Mas o Audio Overview não teria sobrevivido a esse filtro antes de existir. O que seria a métrica de sucesso de uma feature que ninguém tinha pedido e que viralizou por razões que a própria equipe não antecipou?
A ironia é que o Google Labs, que produziu o NotebookLM, opera com cerca de 30 experimentos simultâneos, alguns viram produto mas a maioria não. O modelo funciona porque aceita que não sabe com antecedência o que vai funcionar. O que parece falta de rigor é na verdade a única postura honesta quando você está tentando descobrir algo que ainda não existe.
O escritor Steven Johnson, que participou do time que construiu o NotebookLM, tem uma forma de trabalhar que deu o impulso inicial ao produto: ele guarda notas desde os anos 90, rascunhos de livros, citações, ideias soltas. Queria uma ferramenta onde pudesse despejar tudo isso e interagir com o material, ou seja, ele não sabia o que queria com precisão. A equipe de produto também não sabia, então começaram a construir enquanto Johnson descrevia o que queria, e a PM Raiza Martin ficava observando como ele usava o que estava sendo construído, notando onde o produto quase funcionava mas não chegava lá.
Esse processo de observação direta de um usuário concreto usando uma versão inacabada do produto é o que produziu as escolhas que definiram o NotebookLM. As citações que linkam de volta ao documento original, o formato de podcast com pausas e interjeições naturais em vez de texto-para-voz robótico, a decisão de não ter opções de customização na primeira versão porque usuários reais não sabem o que é “temperature” ou “top-k”. Cada uma dessas escolhas veio de alguém olhando para outra pessoa tentando usar algo que ainda não estava pronto.
Times que planejam tudo dentro de OKRs às vezes confundem execução com descoberta, mas são atividades diferentes. Execução funciona quando o problema e a solução já são conhecidos o suficiente para transformar em métrica. Descoberta funciona quando o problema ainda está mal definido e a solução não existe. O erro é usar o mesmo processo para as duas coisas.
O que o Google Labs faz, e que a maioria dos times de produto não consegue replicar, é separar as duas fases. Experimento sem prazo de entrega, com equipe pequena, sem pressão de crescimento. Quando o produto prova que tem alguma coisa real, aí entra o processo. O NotebookLM virou produto formalmente apenas em outubro de 2024, mais de um ano depois do lançamento público e dois anos depois de começar a ser construído. A versão paga, o NotebookLM Plus, saiu em dezembro de 2024.
O problema para a maioria das empresas não é que não têm pessoas com boas ideias, o problema é que o processo consome as ideias antes que elas possam virar algo testável. A ideia de Jeff Dean de ouvir papers no carro teria sobrevivido ao processo de priorização do seu time de produto?
Claro que esse artigo eu transformaria em podcast usando o NotebookLM.