Quase todo dia, no Slack, eu recebo a pergunta de produto.

Não uma pergunta abstrata. Não uma grande reflexão sobre a visão de cinco anos. Uma pergunta de verdade, do dia a dia.

A gente consegue 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. Elas 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 arbitrar, às vezes assumir uma orientação.

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

Elas são sobre o comportamento real do produto.

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 teoria, a resposta deveria ser simples.

O problema é que nem sempre é.

O custo escondido da pergunta de produto

Quando a pergunta é específica, 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.

Por fim porque a pergunta de verdade quase sempre trata de um caso-limite que ninguém documentou explicitamente.

Então você faz o que todo PM, CSM, suporte ou desenvolvedor faz quando está na dúvida: você testa.

Você sobe um ambiente de teste.

Você prepara um conjunto de dados.

Você reproduz o cenário.

Você verifica se o produto trava, aceita, calcula, exibe, oculta, dispara, envia, recusa.

E meia hora já passou.

À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.

Existe também outro custo, ainda mais invisível: a troca de contexto.

A pergunta raramente chega na hora certa. Ela chega porque um cliente está esperando. Porque um vendedor 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. Você entra num assunto. Você testa. Você responde. Depois você tenta voltar ao que estava fazendo antes.

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

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

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

Você poderia responder: basta ter uma documentação melhor.

Em teoria, sim.

Na prática, não.

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

É 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.

Compromissos são feitos.

Detalhes são ajustados.

Casos-limite aparecem.

Decisões são tomadas durante o desenvolvimento.

Restrições técnicas obrigam a modificar levemente o comportamento.

Discussões acontecem num pull request ou num merge request.

Arbitragens nem sempre voltam para a documentação inicial.

Isso não é necessariamente grave. Até é bem normal. Um produto vivo não é construído como um documento congelado.

Mas isso gera 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 do Notion.

Não a memória do PM.

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

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

Dito assim, pode soar brutal. Você poderia 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.

Você mantém o que explica.

Você regenera o que descreve.

Os contextos precisam ser preservados. Eles contêm as discussões, 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? Quais 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 feature, ele registra uma decisão de produto estruturante.

Certas 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, na medida do 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 um limite evidente.

Código é código.

Nem sempre é legível para o suporte. Nem sempre é legível para o time de 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 tiver bagagem técnica.

Por muito tempo, era preciso então uma camada intermediária. Specs. Documentos de suporte. 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.

Um 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 fluxo trava?"

Um vendedor pode perguntar: "Dá para prometer essa configuração a esse prospect?"

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

E a IA pode ir buscar no código, no histórico do Git, nos merge requests, nas 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 precisa 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.

Então é preciso obrigar a IA a ancorar sua resposta.

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

Não apenas: "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 estar no centro da resposta. Para o suporte ou para vendas, elas podem ficar no fim do documento. Nem todo mundo precisa ler os detalhes técnicos.

Mas elas precisam existir.

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

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

Para uma pergunta de produto, é a mesma coisa.

A prova pode ser um arquivo.

Uma função.

Uma exceção.

Um teste.

Um commit.

Um merge request.

Um pull request.

Uma 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.

Isso não basta.

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

Uma boa resposta de produto não deve apenas responder.

Ela também deve dizer onde trava.

Essa é uma diretriz essencial.

A IA precisa ser capaz de escrever:

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

"O código mostra dois comportamentos possíveis dependendo do estado da 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 tem uma dúvida, ele sinaliza. Quando precisa testar, ele testa.

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

O objetivo é reduzir o custo de pesquisa, aumentando a rastreabilidade.

Nem todo público precisa da mesma leitura

Uma pergunta de produto pode interessar a vários times.

O suporte quase sempre quer uma resposta que dê para usar na frente do cliente.

O CSM quer entender o uso e os impactos.

Vendas quer saber o que pode prometer, e qual valor destacar.

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

A diretoria pode querer entender o que está em jogo estrategicamente.

Você poderia então imaginar uma resposta diferente para cada público.

Mas isso não é necessariamente preciso.

A 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ê aquilo de que precisa.

E às vezes é justamente útil que um vendedor 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 limitar 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

Tecnicamente, não basta plugar um LLM num repositório Git e torcer para tudo funcionar.

Várias ferramentas são complementares.

O RAG permite recuperar os fragmentos certos. Ele costuma ser muito eficaz para fazer emergir os pedaços relevantes numa grande massa documental ou num código volumoso.

Mas o RAG nem sempre basta. Ele recupera. Ele não necessariamente percorre.

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 também continua indispensável. Depois de identificar uma região, às vezes é preciso ler o diretório, abrir os arquivos próximos, entender a estrutura local. É menos elegante que uma busca vetorial, mas muitas vezes bem eficaz.

O Git traz outra dimensão: o tempo.

O código atual diz o que existe. O histórico diz como se chegou até ali. Os commits, os pull requests ou os merge requests podem revelar a intenção, as discussões, os compromissos, as correções.

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

Se a IA não tem acesso a esse estado, ela precisa responder de forma condicional: se a flag está ativada, então o comportamento é este; senão, é diferente.

Se ela tem acesso ao ambiente, ela pode ir além: para esse cliente específico, nessa configuração específica, o comportamento ativo é aquele.

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

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

Existe, porém, uma condição básica.

O código precisa representar o negócio.

Se o código é uma bagunça, 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, então a IA vai ter dificuldade.

Mas esse não é um limite novo.

Um desenvolvedor humano também vai ter dificuldade.

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

Um time que quer 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 de negócio e a mecânica de software. Cada evolução exige reconstruir mentalmente esse elo. Cada debug fica mais caro. Cada regra fica mais difícil de encontrar.

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

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

Se você quer consultar o código como fonte da verdade do produto, o código precisa falar a linguagem do produto.

As entidades precisam carregar os nomes do negócio.

As ações precisam ser legíveis.

Os eventos precisam contar o que aconteceu.

As exceções precisam expressar regras, não apenas erros técnicos.

As políticas precisam tornar visíveis as reações em cascata.

Os módulos precisam ter uma estrutura previsível.

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

É esse tipo de código que se torna 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 no Slack é o primeiro caso de uso.

Mas não é o único.

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

Você pode 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 ou não ser prometido.

A lógica é sempre a mesma: não manter à 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, elas servem ao diálogo.

Elas permitem discutir, explorar, delimitar, decidir.

Depois da produção, elas não devem mais pretender ser a verdade duradoura do produto.

Elas passam a ser regeneráveis.

Não é uma regra religiosa

É claro que é preciso manter um pouco de pragmatismo.

Nem toda empresa consegue aplicar isso ao milímetro.

Algumas têm um legado documental pesado.

Algumas têm um legado técnico difícil.

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

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

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

Algumas não podem expor as mesmas informações a todos os times.

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

Seria absurdo.

Trata-se de mudar o centro de gravidade.

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

Parar de pedir ao PM que verifique manualmente, de novo e de novo, o que o produto já faz.

Parar de manter à 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 conversam entre si.

Mais do que um método de produto

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

Ela revela uma transformação mais ampla.

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

Você procurava.

Você lia.

Você copiava.

Você atualizava.

Você esquecia.

Com a IA, você pode começar a fazer outra coisa.

Você pode dialogar com o sistema de informação.

Você pode fazer uma pergunta.

Você pode pedir uma prova.

Você pode explorar as ideias próximas.

Você pode voltar no histórico.

Você pode detectar uma contradição.

Você pode regenerar um artefato.

A pergunta de produto é um bom ponto de entrada porque é concreta. Ela custa tempo todos os dias. Ela interrompe o trabalho. Ela revela a divergência entre documentação e produção.

Mas por trá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 de verdade.

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

Para saber mais

Code centric Product Decision Record: registrar as escolhas de produto que estruturam a empresa Wiki IA: por que construí uma base de conhecimento mantida por uma IA