Quase todo dia, no Slack, chega até mim a pergunta de produto.

Não uma pergunta abstrata. Não uma grande reflexão sobre a visão dos próximos cinco anos. Uma pergunta concreta, do dia a dia.

Dá para fazer isso?

O que acontece se o cliente configurar o produto assim?

Qual é o limite?

Essa regra também vale nesse caso?

Por que o produto trava aqui?

Dá para prometer isso ao cliente?

Algumas dessas perguntas são estratégicas. Exigem entender o mercado, o cliente, o posicionamento, a direção que queremos tomar. Nesses casos, é preciso um product manager. É preciso julgamento. Às vezes é preciso dizer não, às vezes decidir, às vezes assumir uma orientação.

Mas muitas perguntas não são desse tipo.

Elas falam de como o produto realmente se comporta.

Uma regra. Um limite. Uma exceção. Uma restrição. Um caso de uso. Uma configuração. Uma interação entre duas funcionalidades.

E aí, em tese, a resposta deveria ser simples.

O problema é que nem sempre ela é.

O custo escondido da pergunta de produto

Quando a pergunta é fina, nem sempre basta abrir a documentação.

Primeiro porque a documentação nem sempre existe.

Depois porque às vezes ela existe, mas você não sabe se ainda está atualizada.

E por fim porque a pergunta de verdade quase sempre recai sobre um caso-limite que ninguém documentou de forma explícita.

Aí você faz o que todo PM, CSM, alguém do suporte ou um desenvolvedor faz na dúvida: testa.

Você sobe um ambiente de teste.

Prepara uma massa de dados.

Reproduz o cenário.

Confere se o produto trava, aceita, calcula, exibe, esconde, dispara, envia, recusa.

E já se passou meia hora.

Às vezes uma hora.

Às vezes mais.

Esse tempo não aparece em lugar nenhum. Não está no Jira. Não está no roadmap. Não está nas estimativas. Ele é simplesmente absorvido pelo funcionamento normal da organização.

E existe ainda outro custo, mais invisível que esse: a troca de contexto.

A pergunta raramente chega na hora certa. Ela chega porque um cliente está esperando. Porque alguém de vendas está numa reunião. Porque um CSM está preparando um encontro. Porque o suporte precisa responder antes do fim do dia.

Então você interrompe o que estava fazendo. Entra num assunto. Testa. Responde. Depois tenta voltar ao que estava fazendo antes.

Não é só perda de tempo. É perda de continuidade intelectual.

E é exatamente esse tipo de tarefa que a IA deveria absorver.

O problema não é a pergunta. É a fonte.

Alguém poderia responder: bastaria ter uma documentação melhor.

Em tese, sim.

Na prática, não.

Uma documentação de produto está quase sempre atrás do produto real. Não é um problema de disciplina individual. Não é só porque alguém esqueceu de atualizar uma página.

É algo mais estrutural.

Uma spec descreve uma intenção. Um PRD descreve um objetivo, regras esperadas, cenários. Um protótipo descreve uma interface desejada. Mas entre essa intenção e a produção, sempre acontece alguma coisa.

Concessões são feitas.

Detalhes são ajustados.

Casos-limite aparecem.

Decisões são tomadas durante o desenvolvimento.

Restrições técnicas obrigam a mudar um pouco o comportamento.

Conversas acontecem dentro de um pull request ou de um merge request.

Nem toda decisão volta para a documentação inicial.

Não é necessariamente grave. É até bastante normal. Um produto vivo não se constrói como um documento congelado.

Mas isso cria uma consequência simples: a spec não é a verdade do produto.

Ela é uma aproximação útil num dado momento.

A verdade é o que roda.

E o que roda é o código.

O código como fonte da verdade do produto

A produção é a realidade.

Não a spec.

Não o PRD.

Não a página no Notion.

Não a lembrança do PM.

Não a conversa no Slack de três semanas atrás.

Para saber como o produto se comporta de fato, é preciso olhar o que foi entregue. E o que foi entregue está no código-fonte.

Dito assim, pode soar brutal. Alguém pode achar que isso equivale a dizer: "joguem fora toda a documentação".

Não é essa a ideia.

A distinção certa não é entre "código" e "documentação".

A distinção certa é entre o que explica e o que descreve.

O que explica, a gente guarda.

O que descreve, a gente regenera.

Os Contextos precisam ser preservados. Neles estão as conversas, as fontes, os raciocínios, as ideias que levaram a uma escolha. São blocos reutilizáveis.

As decisões precisam ser preservadas. Quando uma empresa escolhe uma direção, é preciso guardar o porquê. Por que essa escolha? Que alternativas foram descartadas? Por que essa decisão substitui uma decisão anterior?

É esse o papel dos Product Decision Records, os PDRs. Já escrevi sobre isso: um PDR não descreve uma funcionalidade, ele registra uma decisão de produto estruturante.

Algumas restrições também precisam continuar acessíveis: restrições contratuais, regulatórias, documentos externos, compromissos específicos. Nem tudo pode ser deduzido do código.

Mas a documentação que descreve o comportamento do produto deveria, sempre que possível, ser regenerada a partir do código.

Porque o código é a verdade do comportamento implementado.

O que a IA torna possível

Até agora, essa ideia tinha uma limitação evidente.

Código é código.

Nem sempre é legível para o suporte. Nem sempre é legível para vendas. Nem sempre é legível para um C-level. Nem sempre é fácil de ler nem para um PM, ainda mais se ele não tem cultura técnica.

Durante muito tempo, era preciso então uma camada intermediária. Specs. Documentos de apoio. Páginas de produto. Changelogs. Tabelas. Diagramas.

A IA muda essa equação.

Ela pode virar a interface entre uma pergunta de negócio e o código-fonte.

Alguém do suporte pode perguntar: "O que acontece se o cliente cancelar esse item depois da validação?"

Um CSM pode perguntar: "Em que condições esse workflow trava?"

Alguém de vendas pode perguntar: "Dá para prometer essa configuração para esse prospect?"

Um PM pode perguntar: "Onde essa regra está implementada e que casos não estão cobertos?"

E a IA pode buscar no código, no histórico do Git, nos merge requests, nos feature flags, nos contextos de negócio, e então produzir uma resposta compreensível.

Não uma resposta mágica.

Uma resposta ancorada.

Uma boa resposta de produto tem que mostrar suas provas

O ponto-chave está aí.

Se a IA responde sem prova, ela vira mais uma documentação aproximada. Mais rápida, mais elegante, mas não necessariamente mais confiável.

É preciso então obrigar a IA a ancorar a resposta.

Quando ela afirma que uma regra existe, ela tem que dizer por quê.

Não só: "o produto funciona assim".

Mas: "o produto funciona assim porque tal função aplica essa regra, porque tal exceção trava esse caso, porque tal merge request introduziu esse comportamento, porque tal teste cobre esse cenário".

As provas não precisam necessariamente ficar no centro da resposta. Para o suporte ou para vendas, elas podem ficar no rodapé do documento. Nem todo mundo precisa ler os detalhes técnicos.

Mas elas têm que existir.

A presença delas muda o comportamento da IA. Ela não pode mais responder só por verossimilhança. Ela tem que amarrar suas afirmações a elementos factuais.

É a mesma lógica de uma análise de texto. Se peço a uma IA que analise um corpus, prefiro que ela me dê, para cada conclusão, a frase ou o parágrafo em que se apoia. Isso reduz muito as alucinações.

Numa pergunta de produto, é igual.

A prova pode ser um arquivo.

Uma função.

Uma exceção.

Um teste.

Um commit.

Um merge request.

Um pull request.

Um feature flag.

Uma decisão de produto.

Uma fonte de negócio.

Sem isso, você só desloca o problema. Você troca a memória imperfeita do PM pela memória probabilística de um modelo.

Não é suficiente.

Também é preciso dizer o que não se sabe

Uma boa resposta de produto não pode só responder.

Ela também tem que dizer onde emperra.

Essa é uma diretriz essencial.

A IA precisa poder escrever:

"Não encontrei nenhum teste cobrindo esse caso."

"O código mostra dois comportamentos possíveis, dependendo do estado do feature flag."

"Não consigo determinar o comportamento exato para esse cliente sem acessar a configuração dele."

"O PDR indica uma regra, mas o código parece implementar outra coisa."

"A documentação de suporte atual contradiz o comportamento observado no código."

É desconfortável, mas é valioso.

Um humano sério faz a mesma coisa. Quando não sabe, ele diz. Quando está em dúvida, ele avisa. Quando precisa testar, ele testa.

O objetivo não é fazer parecer que a IA sabe tudo.

O objetivo é reduzir o custo da busca, aumentando ao mesmo tempo a rastreabilidade.

Nem todo público precisa da mesma leitura

Uma pergunta de produto pode interessar a várias áreas.

O suporte quase sempre quer uma resposta aproveitável na frente do cliente.

O CSM quer entender o uso e os impactos.

Vendas quer saber o que pode prometer, e que valor colocar em destaque.

O PM quer conferir a regra, o limite, a exceção.

A diretoria pode querer entender o que está em jogo no plano estratégico.

É possível imaginar, então, uma resposta diferente para cada público.

Mas isso não é necessariamente preciso.

Uma mesma resposta pode ser estruturada em vários ângulos. Uma parte curta para responder à pergunta. Uma parte de suporte. Uma parte de uso. Uma parte de valor. Uma parte de limites. Uma parte de provas.

Cada um lê o que precisa.

E às vezes é justamente útil que alguém de vendas veja um limite do produto ou que um CSM entenda a origem técnica de um comportamento. Isso depende da cultura da empresa. Algumas organizações preferem restringir a informação. Outras amadurecem ao compartilhá-la.

Não é uma questão puramente técnica.

É uma questão de cultura.

Os blocos necessários

Do ponto de vista técnico, não basta plugar um LLM num repositório Git e torcer para tudo funcionar.

Várias ferramentas se complementam.

O RAG permite recuperar os fragmentos certos. Costuma ser muito eficiente para fazer emergir os trechos pertinentes dentro de uma grande massa documental ou de um código volumoso.

Mas o RAG nem sempre dá conta. Ele recupera. Ele não necessariamente circula.

Um grafo semântico pode ajudar a explorar os elementos próximos: conceitos ligados, módulos vizinhos, regras conectadas, eventos que disparam outros eventos.

Percorrer o filesystem continua indispensável também. Depois de identificar uma região, às vezes é preciso ler o diretório, abrir os arquivos vizinhos, entender a estrutura local. É menos elegante que uma busca vetorial, mas muitas vezes bem eficiente.

O Git traz outra dimensão: o tempo.

O código atual diz o que existe. O histórico diz como se chegou lá. Os commits, os pull requests ou os merge requests podem revelar a intenção, as conversas, as concessões, as correções.

Os feature flags acrescentam mais uma nuance. O código pode conter vários comportamentos possíveis. O comportamento real depende então do estado do flag.

Se a IA não tem acesso a esse estado, ela tem que responder de forma condicional: se o flag estiver ativado, o comportamento é este; se não, é outro.

Se ela tem acesso ao ambiente, ela pode ir mais longe: para este cliente específico, nesta configuração específica, o comportamento ativo é aquele.

Essa passagem é importante. A pergunta de produto nem sempre fala do código abstrato. Ela fala, às vezes, do produto tal como um cliente específico o vive.

A condição: um código que fala a linguagem do negócio

Só que existe uma condição de base.

O código tem que representar o negócio.

Se o código é um emaranhado, se os conceitos de negócio estão escondidos atrás de nomes técnicos, se as regras estão espalhadas, se as exceções não carregam o vocabulário do domínio, aí a IA vai ter dificuldade.

Mas essa não é uma limitação nova.

Um desenvolvedor humano também vai ter dificuldade.

Um PM técnico também vai ter dificuldade.

Um time que queira evoluir o produto também vai ter dificuldade.

Um código que não representa o negócio não é um bom código. Ele impõe o tempo todo uma tradução entre a necessidade do negócio e a mecânica do software. Cada evolução exige reconstruir mentalmente esse elo. Cada debug fica mais caro. Cada regra fica mais difícil de achar.

É exatamente por isso que abordagens como o DDD existem há tanto tempo. A ideia não nasceu com a IA.

A IA só torna essa exigência mais visível.

Se queremos consultar o código como fonte da verdade do produto, o código tem que falar a linguagem do produto.

As entidades têm que levar os nomes do negócio.

As ações têm que ser legíveis.

Os eventos têm que contar o que aconteceu.

As exceções têm que expressar regras, não só erros técnicos.

As políticas têm que deixar visíveis as reações em cascata.

Os módulos têm que ter uma estrutura previsível.

Uma exceção como ElementAnnuléNonModifiable não é só uma mensagem de erro. É uma regra de negócio escrita em código.

É esse tipo de código que fica consultável.

Não porque a IA é mágica.

Porque o negócio já está presente no material que ela lê.

Da resposta pontual à documentação regenerada

Responder a uma pergunta do Slack é o primeiro caso de uso.

Mas não é o único.

Se é possível responder a uma pergunta de produto a partir do código, também é possível regenerar parte da documentação de produto.

Podemos produzir um FAQ de suporte.

Atualizar um artigo vivo sobre uma funcionalidade.

Gerar um changelog.

Reconstituir uma spec a partir do estado atual do produto.

Produzir uma documentação comercial mais confiável sobre o que pode ser prometido ou não.

A lógica é sempre a mesma: não manter na mão artefatos que descrevem o comportamento real se esse comportamento pode ser reconstruído a partir da fonte da verdade.

As specs não desaparecem por completo.

Elas mudam de status.

Antes da produção, servem ao diálogo.

Permitem discutir, explorar, delimitar, decidir.

Depois da produção, não devem mais se apresentar como a verdade duradoura do produto.

Elas se tornam regeneráveis.

Isso não é uma regra religiosa

É claro que é preciso guardar um pouco de pragmatismo.

Nem toda empresa consegue aplicar isso ao pé da letra.

Algumas têm um legado documental pesado.

Algumas têm um legacy difícil.

Algumas têm restrições regulatórias fortes.

Algumas ainda não têm cultura técnica suficiente.

Algumas têm decisões de produto mal registradas.

Algumas não podem expor as mesmas informações a todas as áreas.

Não se trata, portanto, de dizer: amanhã de manhã, apaguem toda a documentação de vocês.

Seria absurdo.

Trata-se de deslocar o centro de gravidade.

Parar de considerar a documentação descritiva como a fonte da verdade.

Parar de pedir ao PM que confira na mão, de novo e de novo, o que o produto já faz.

Parar de manter na mão artefatos que divergem mecanicamente.

E começar a construir um sistema em que o código, as decisões, os Contextos e as fontes dialogam.

Mais que um método de produto

No fundo, a pergunta de produto é só um caso particular.

Ela revela uma transformação bem maior.

Durante muito tempo, o sistema de informação da empresa foi feito de bancos de dados, bases documentais, wikis, tickets, planilhas, pastas, documentos.

Buscávamos.

Líamos.

Copiávamos.

Atualizávamos.

Esquecíamos.

Com a IA, dá para começar a fazer outra coisa.

Dá para dialogar com o sistema de informação.

Dá para fazer uma pergunta.

Dá para pedir uma prova.

Dá para explorar as ideias próximas.

Dá para subir o histórico.

Dá para detectar uma contradição.

Dá para regenerar um artefato.

A pergunta de produto é uma boa porta de entrada porque é concreta. Custa tempo todo dia. Interrompe o trabalho. Escancara a divergência entre documentação e produção.

Mas atrás dela o assunto é mais profundo.

Não se trata só de ajudar o suporte a responder mais rápido.

Trata-se de tornar a empresa consultável a partir de suas fontes reais.

E no caso do produto, a fonte real do comportamento é o código.