Pensamento de Produto

A reunião deveria terminar com as tasks já lançadas

O custo real de uma reunião não é a reunião, é o dever de casa depois: a transcrição que ninguém relê, os action items que alguém redigita, os donos e datas que silenciosamente nunca são definidos.

ASR

Apollo Space Research

Apollo Space

· 10 min de leitura

A call termina. Todo mundo diz “ótimo, vamos fazer acontecer”, as câmeras se desligam, e o trabalho não começou, ele só mudou de forma. Agora alguém tem que voltar por quarenta minutos de conversa, decidir o que de fato foi acordado, descobrir quem assume cada peça, chutar as datas que ninguém disse em voz alta, e digitar tudo na ferramenta onde o trabalho vive. Esse segundo job é invisível. É também onde a maior parte do que você decidiu silenciosamente morre.

Ficamos muito bons em gravar reuniões. Ainda somos péssimos em terminá-las.

A reunião deveria terminar com as tasks já lançadas, donos definidos, datas definidas, no sistema, antes de qualquer um sair da call. Esse é o post inteiro. Tudo abaixo é sobre por que o dever de casa existe, por que resumi-lo não o mata, e o que mata.

O dever de casa é a reunião de verdade

Aqui está a parte que não dizemos em voz alta: a reunião não está pronta quando a reunião está pronta.

Imagine a versão mais comum. Oito pessoas gastam uma hora decidindo seis coisas. A hora em si parece produtiva, há energia, há acenos de cabeça, há um “sim, vamos fazer isso”. Então a call termina, e o custo de verdade começa. Alguém, geralmente a pessoa mais sênior, porque foi ela que estava prestando atenção, tem que reconstruir o que foi decidido. Ela rola o chat. Ela meio que lembra quem se voluntariou para quê. Ela abre a ferramenta de projeto e começa a digitar tasks, uma de cada vez, anexando donos que está chutando e datas que ninguém comprometeu.

Essa reconstrução é trabalho de verdade, e é do pior tipo: de alto risco, baixa alavanca, e feito pela sua pessoa mais cara no momento de menor energia do dia dela. Erre e uma decisão evapora. O custo nunca foi a hora na sala. O custo é a segunda hora que ninguém agendou, fazendo a reunião de novo, sozinho, de memória.

E na maioria das vezes essa segunda hora simplesmente não acontece. As notas ficam num doc. Os action items vivem na cabeça de alguém até a cabeça partir para a próxima call. Duas semanas depois você está num follow-up perguntando “espera, será que a gente chegou a fazer a coisa que acordamos?”, e a resposta honesta é que ninguém a lançou, então ninguém a assumiu, então ela nunca ia acontecer.

A reunião deveria terminar com as tasks já lançadas. Não resumidas. Não transcritas. Lançadas, como trabalho, onde o trabalho vive.

O fix ingênuo: grave, resuma, siga em frente

A resposta óbvia a todo aquele trabalho perdido é a que a indústria inteira buscou primeiro. Grave a call. Transcreva. Gere um resumo com uma seção de “action items” em bullets no final. Mande por email. Pronto.

Parece uma solução. Não é, e vale ser preciso sobre por quê, porque o gap é o produto inteiro.

Uma transcrição é a reunião, de novo, completa, em texto. Ninguém relê uma transcrição. Ela é mais longa que a reunião e igualmente desestruturada, você transformou uma hora de conversa em vinte páginas de conversa, que é mais matéria-prima, não menos trabalho. Um resumo é melhor: é mais curto. Mas um resumo ainda é algo que você , e ler não é fazer. Os action items em bullets no fim do email são uma lista de sugestões sentada numa inbox. Eles não têm dono que o sistema conheça, nem data que o calendário respeite, nem lugar no board onde o time de fato olha. Eles são uma descrição de trabalho, estacionada a um copy-paste de virar trabalho.

Então o dever de casa não desapareceu. Ele se moveu. Antes, você reconstruía as decisões de memória. Agora, você as reconstrói de um resumo, material de partida melhor, mesmo job manual. Alguém ainda tem que ler os action items, decidir quais são reais, atribuir cada um, definir cada data, e digitá-los no sistema. O resumo deixou o input mais bonito. Ele não fez o trabalho acontecer.

O gargalo nunca desaparece. Ele só se move para quem abre o email.

Dois jeitos de uma reunião terminar. À esquerda, o caminho ingênuo: a call produz uma gravação, depois uma transcrição, depois um email de resumo com uma lista de action items em bullets que cai numa inbox e espera um humano relê-la e digitar manualmente cada task na ferramenta de projeto. À direita, a mesma call flui por um company brain que escuta, decide o que foi acordado, e escreve as tasks direto no board com donos e datas já definidos, sem inbox, sem redigitação, sem dever de casa.

O fix de verdade: a reunião escreve no sistema, não num documento

Aqui está a virada, e é menor do que parece. Pare de apontar a reunião para um documento. Aponte-a para o sistema onde o trabalho vive.

Um resumo é o output errado porque um documento é o destino errado. O output certo de uma reunião é um conjunto de tasks, cada uma com um dono, cada uma com uma data, cada uma já no board que o time confere toda manhã. A diferença entre esses dois outputs é a diferença entre um registro de intenção e o trabalho em si. Um deles você ainda tem que executar. O outro já aconteceu.

Para produzir a segunda coisa, o sistema tem que fazer três jobs que a ferramenta de resumo pula inteiramente.

Primeiro, ele tem que decidir o que é um action, não só registrar tudo o que foi dito. Uma reunião é em grande parte não-action-items. É debate, tangentes, pensar em voz alta, duas pessoas discordando e uma delas mudando de ideia. O job é o corte: de uma hora de conversa, quais seis frases são compromissos? “A gente provavelmente deveria olhar isso algum dia” não é uma task. “Vou mandar a proposta revisada até quinta” é. Distinguir essas é o trabalho, e é exatamente o trabalho que uma transcrição se recusa a fazer por você.

Segundo, ele tem que resolver o dono. “Alguém deveria fazer follow-up com o cliente” é uma task sem casa, e uma task sem casa é uma task que não vai ser feita. O sistema tem que mapear o vago para o específico, notar que quando a sala disse “deixa ops cuidar do rollout”, ops é uma pessoa com um nome e uma fila, e pôr a task naquela fila. Um action item sem um dono que o sistema reconheça é só uma frase.

Terceiro, ele tem que definir a data, mesmo quando ninguém disse uma limpamente. “Até o fim da semana” é um prazo real que vive em lugar nenhum até algo escrevê-lo como uma data. “Depois do launch” é uma dependência, não uma data, e o sistema tem que ou resolvê-la ou sinalizar que não consegue. Datas são onde action items vão apodrecer, porque o humano fazendo o dever de casa está cansado e as pula, e uma task sem data nunca aparece até estar atrasada.

Faça essas três coisas e o output não é um resumo que você lê. É um board que você olha, populado, com dono, com data, já verdadeiro.

O que “já lançada” de fato exige por baixo dos panos

A razão pela qual isto não é só uma ferramenta de transcrição mais chique é que ela precisa de algo que uma ferramenta de transcrição não tem: ela precisa conhecer sua empresa.

Resolver “ops vai cuidar disso” para um dono real significa saber quem está no time e o que eles fazem. Resolver “follow-up com o cliente” significa saber qual cliente, aquele com quem você vem falando há três semanas, cujo nome veio à tona uma vez, só pelo primeiro nome, quarenta minutos dentro. Resolver “antes da renovação” numa data significa saber quando a renovação é. Nada disso vive no áudio. Vive na empresa, nas pessoas, nos deals, no calendário, no histórico do que foi dito e decidido antes.

Um resumidor lê a reunião isoladamente. Ele tem exatamente uma hora de contexto: a hora que acabou de ouvir. É por isso que seus action items são genéricos, “follow-up com cliente”, “revisar o documento”, “mandar a coisa”, porque genérico é tudo o que você consegue produzir de uma única call sem memória da empresa em volta. O resumo é raso porque o input é raso, não porque o modelo é fraco.

O fix é dar à reunião o mesmo contexto que as pessoas na sala têm. Quando o sistema escutando a call consegue alcançar o company brain, o time, os clientes, o calendário, as decisões anteriores, “ops vai cuidar disso” deixa de ser uma sugestão vaga e vira uma task atribuída a uma pessoa real, ligada ao deal real, datada contra a renovação real. A reunião deixa de ser um evento isolado e vira mais uma coisa que a empresa sabe, escrita no mesmo lugar onde tudo o mais que a empresa sabe vive.

Essa é a diferença entre uma ferramenta que assiste sua reunião e um sistema que a atende. Uma produz um registro. O outro produz trabalho.

Uma única frase de uma reunião, "ops vai cuidar do rollout antes da renovação", flui para um company brain que resolve cada parte vaga contra o que a empresa já sabe: ops vira um dono nomeado do time, o rollout se liga ao projeto real, e 'antes da renovação' resolve para uma data real do calendário. O output é uma task lançada com dono e data definidos, não um bullet num resumo.

A virada: devolva o dever de casa para ninguém

Tire o mecanismo e aqui está o que sobra.

Na maioria das empresas, a pessoa mais esperta da sala é também a pessoa fazendo o dever de casa de transcrição. Ela conduziu a reunião, então a entendeu melhor, então é ela quem a reconstrói depois, rolando, redigitando, chutando donos, definindo datas. Chamamos isso de diligência. É um imposto, e é cobrado exatamente da pessoa cujo tempo vale mais.

Pense no que aquela hora é em vez de. É em vez de decidir o que a empresa deveria perseguir em seguida. É em vez da única conversa que só ela pode ter. É em vez de pensar. Cada minuto gasto transformando uma reunião de volta numa lista de tasks é um minuto que a pessoa mais capaz do prédio gasta fazendo a coisa mais mecânica do prédio, e ela faz isso porque, até agora, nenhum sistema faria.

A promessa não é um resumo melhor. É que o dever de casa não pertence mais a ninguém. A reunião termina, e as tasks já estão no board, com dono, com data, verdadeiras, para que as pessoas que estavam na sala possam sair da sala e ir fazer o trabalho, em vez de ficar para trás escrevendo que o trabalho existe. A decisão e o lançamento viram o mesmo ato. A segunda hora desaparece.

A reunião deveria terminar com as tasks já lançadas. Uma vez que você sentiu a segunda hora sumir, uma vez que uma call termina e o trabalho está só , esperando no sistema em vez de esperar você, o jeito antigo começa a parecer o que sempre foi: fazer a reunião duas vezes e ser pago por uma.


É isso que estamos construindo na Apollo, não uma ferramenta que grava suas reuniões e te entrega mais dever de casa, mas um sistema que as atende, entende sua empresa, e termina a call com o trabalho já lançado. Se você já terminou uma ótima reunião e sentiu seu coração afundar com o doc que agora tem que escrever, você já sabe qual hora era a cara.

A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.

Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.

Entrar na lista de espera