O entregável não é mais o capital

Durante muito tempo, eu via o entregável como o resultado principal do trabalho.

Um documento está pronto. Uma apresentação foi enviada. Uma spec foi compartilhada. Um artigo foi publicado. Uma resposta a um edital voltou para o cliente.

Alguma coisa foi produzida.

Então o trabalho parece encerrado.

Mas quanto mais uso a IA com contextos, mais essa evidência me parece incompleta.

O entregável é visível.

Ele é necessário.

Mas não é sempre o capital de verdade.

O documento final consome um pensamento

Um entregável é feito para um uso.

Ele responde a um público, a um momento, a uma restrição de forma. Uma spec fala com os desenvolvedores. Um pitch fala com um CPO. Uma documentação de suporte fala com um time que precisa responder rápido. Um artigo fala com leitores que ainda não conhecem o assunto. Uma resposta a um edital fala com um cliente que tem os campos dele, a numeração dele, o vocabulário dele.

Cada entregável seleciona, simplifica, reescreve e ordena o material para uma necessidade precisa.

Isso é normal. É até o papel dele.

Mas dar essa forma tem um custo: parte do pensamento que permitiu produzir o entregável desaparece atrás dele.

Você vê o documento final.

Já não vê sempre as fontes, as hesitações, as alternativas descartadas, os exemplos que ficaram de fora, as decisões intermediárias, as contradições, as nuances que você guardou na cabeça mas não na versão enviada.

O entregável carrega o resultado.

Ele não carrega necessariamente o raciocínio.

O problema começa no segundo entregável

Isso fica discreto enquanto existe só uma saída para produzir.

Você trabalha um material. Escreve um documento. Envia. Fim.

Mas na vida real, o mesmo conteúdo muitas vezes precisa servir várias vezes.

A partir do mesmo material, talvez seja preciso produzir:

• uma spec funcional;
• user stories;
• um pitch para a diretoria;
• uma nota para o time de vendas;
• uma documentação de suporte;
• um plano de testes;
• uma resposta a um edital;
• um artigo;
• uma síntese curta para uma reunião.

Num workflow clássico, cada formato novo dá a impressão de começar de novo.

Você volta ao documento anterior. Copia e cola. Reescreve. Tira o que não fala com o novo público. Acrescenta o que falta. Às vezes esquece uma nuance. Duas versões começam a divergir.

Isso não é só chato.

É perigoso.

O suporte pode receber uma explicação diferente da que foi dada ao time de vendas. A spec pode conter uma hipótese que já não está no pitch. A resposta ao edital pode reaproveitar uma formulação antiga que já não é verdadeira. O artigo pode achatar uma distinção importante porque o material disponível já está enviesado.

O problema não é produzir vários documentos.

O problema é tomar um entregável como fonte principal do entregável seguinte.

Uma saída não é fonte da verdade

Um documento final é uma saída.

Ele pode ser muito bom.

Mas foi escrito para um contexto de uso preciso.

Por isso ele contém escolhas que nem sempre pertencem ao conhecimento em si: o tom, o nível de detalhe, os exemplos, a ordem, o grau de cautela, a forma de nomear as coisas, o que você revela ou não, o que você supõe já sabido.

Se você parte desse documento para produzir tudo depois, herda as escolhas dele.

Às vezes isso é útil.

Muitas vezes isso aprisiona.

Uma frase escrita para tranquilizar um cliente não é necessariamente uma boa base para uma documentação interna. Um slide de diretoria não é uma boa base para uma user story. Uma resposta curta numa tabela não é uma boa base para entender a decisão de produto.

O entregável é enviesado.

O conhecimento de trabalho deveria continuar mais neutro.

O mundo das ideias

É por isso que acho útil acrescentar uma camada intermediária entre as fontes e os entregáveis.

Eu chamo isso de mundo das ideias.

Não é um nome muito técnico.

Mas diz bem o que ele precisa fazer.

O mundo das ideias reúne o que foi compreendido, antes de transformar isso para um público específico.

Ali dá para encontrar:

• notas atômicas;
• notas temáticas;
• definições;
• hipóteses;
• contradições;
• decisões;
• exemplos;
• limites;
• relações entre ideias;
• pontos a verificar.

Esse material ainda não fala com um cliente, com um desenvolvedor ou com um leitor.

Ele fala com o próprio trabalho.

O papel dele não é ser elegante.

O papel dele é ser reutilizável.

Uma nota não deve virar uma frase de efeito

Este ponto é mais sutil do que parece.

Quando você escreve um artigo, dá vontade de transformar uma ideia direto em frase.

Quando você prepara uma apresentação, dá vontade de transformar uma ideia direto em bullet de slide.

Quando você escreve uma spec, dá vontade de transformar uma ideia direto em requisito.

O problema é que a nota já se torna, aí, um fragmento do entregável.

Ela perde a neutralidade.

Uma boa nota precisa manter o conhecimento num nível em que ele poderá ser reexpresso de outra forma.

Ela pode conter uma distinção, uma prova, uma hipótese, uma arbitragem, uma nuance. Mas não deve ficar presa ao artigo, ao slide ou à spec do momento.

O build é o que produz.

A nota serve para conservar o que poderá produzir depois.

A diferença parece pequena.

Ela muda tudo quando você volta três semanas depois.

A IA torna essa separação muito mais útil

Antes da IA, manter essa camada intermediária podia parecer pesado.

Já era possível fazer notas limpas, guardar fontes, criar sínteses. Mas produzir vários entregáveis depois continuava sendo um trabalho manual considerável.

Com a IA, essa separação compensa muito mais.

Se o material está bem organizado, a IA pode ajudar a recompô-lo.

Ela pode produzir uma versão longa, uma versão curta, uma versão comercial, uma versão técnica, uma versão cautelosa, uma versão didática.

Ela pode adaptar o mesmo conhecimento a vários públicos.

Mas, para fazer isso corretamente, ela precisa partir da camada certa.

Não só do último documento enviado.

Não só de um chat.

Não só de um PDF final.

Ela precisa poder voltar às fontes, às notas, às decisões, aos limites, aos pontos ainda incertos.

Aí o trabalho muda de natureza.

Você não produz mais apenas um documento.

Você constrói um material que pode produzir.

O capital é o que sobra depois da saída

Uma boa pergunta a fazer depois de cada entregável é simples:

o que sobra?

Não só: onde está o arquivo?

Mas:

• quais ideias foram estabilizadas?
• quais fontes sustentam essas ideias?
• quais decisões foram tomadas?
• quais alternativas foram descartadas?
• quais formulações foram validadas?
• quais pontos continuam frágeis?
• quais elementos poderão servir a outro público?

Se a resposta é "nada, só o documento final", então boa parte do trabalho foi consumida.

O entregável foi produzido.

Mas o capital não foi construído.

Ao contrário, se o trabalho deixa atrás de si notas, fontes conectadas, decisões, perguntas abertas, formulações testadas, níveis de confiança, então o próximo entregável não vai começar do zero.

O resultado visível é o documento.

O capital é a capacidade de refazer, adaptar, explicar, defender e prolongar.

Isso muda a maneira de trabalhar

A ideia pode parecer abstrata.

Ela fica muito concreta ao longo de uma semana de trabalho.

Uma entrevista com usuário não serve só para escrever um relato. Ela pode alimentar uma nota de produto, uma decisão, uma hipótese, um exemplo para uma apresentação futura.

Um edital não serve só para responder a um prospect. Ele pode enriquecer uma memória de perguntas recorrentes, respostas validadas, provas e limites de divulgação.

Um artigo não serve só para publicar um pensamento. Ele pode estabilizar ideias que mais tarde vão alimentar um livro, um treinamento, um método, uma discussão de produto.

Uma spec não serve só para desenvolver uma funcionalidade. Ela pode guardar o rastro de arbitragens que vão permitir entender, seis meses depois, por que o produto funciona assim.

Em todos esses casos, o entregável não é inútil.

Ele continua indispensável.

Mas passa a ser uma saída entre outras.

Ele já não esgota o valor do trabalho.

O documento certo no lugar certo

Não acho que os entregáveis mereçam desprezo.

Ao contrário.

Um bom entregável é muitas vezes o que torna o trabalho transmissível. Ele obriga a esclarecer, a escolher, a cortar, a formular. Ele põe o pensamento em contato com um público real.

Mas precisamos parar de pedir que ele carregue tudo.

O documento final não precisa conter todas as fontes.

Não precisa conservar todas as alternativas.

Não precisa expor todas as incertezas.

Não precisa se tornar a memória completa do assunto.

Ele precisa fazer o trabalho dele de entregável.

E a memória do trabalho precisa existir em outro lugar.

É exatamente isso que um contexto permite.

O contexto conserva o material.

O build produz as saídas.

O humano fica com o julgamento.

A IA ajuda a recompor.

O deslocamento de valor

O deslocamento me parece importante.

Antes, capitalizávamos sobretudo os documentos.

Guardávamos as specs, as apresentações, as notas de reunião, os relatos, os editais respondidos.

De agora em diante, será preciso capitalizar mais o material que permite produzi-los.

Não é a mesma coisa.

Capitalizar um entregável é conservar uma forma passada.

Capitalizar um contexto é conservar uma capacidade futura.

O entregável diz: aqui está o que enviamos.

O contexto diz: aqui está o que entendemos, decidimos, verificamos, descartamos, e o que ainda podemos produzir a partir daí.

É por isso que o entregável não é mais o capital principal.

Ele continua sendo a parte visível.

Mas o valor que dura se desloca para aquilo que permite produzir várias vezes sem perder o conteúdo.

O documento vai embora.

O pensamento organizado fica.

Para saber mais

O PM como arquiteto do Contexto Fonte de sessão: o que seus documentos não capturam Por baixo do capô do meu motor de contexto: como uma IA se lembra de uma missão O segundo cérebro é um beco sem saída para o product management No software, a vantagem não será mais a tecnologia. Será a compreensão do contexto.