Uma documentação sempre atrasada

Todos nós já passamos por isso: um bug aparece, ou uma evolução funcional precisa ser tratada. O primeiro reflexo é consultar a documentação. E, na maioria das vezes, ela já não está mais atualizada.

Na verdade, a gente quase sabe de antemão que ela não vai estar. O padrão é conhecido: uma documentação é produzida, entregue junto com a especificação, e aí o desenvolvimento começa. No meio do caminho, surgem perguntas, decisões são tomadas, alguns pontos evoluem, e os desenvolvedores às vezes decidem sem voltar sistematicamente ao product manager. É normal. Se não fosse assim, o trabalho avançaria no ritmo de uma validação permanente. O resultado, porém, é sempre o mesmo: a documentação e o código acabam divergindo.

Essa divergência também vem de uma restrição bem simples. A cada modificação, mesmo pequena, ninguém tem tempo de sair de novo atrás da especificação certa, do protótipo certo, do documento de suporte certo ou do changelog certo para atualizar tudo. Trabalhamos em torno de um produto vivo, que evolui o tempo todo. Nesse contexto, manter manualmente o conjunto dos artefatos fica caro demais em relação ao tempo disponível.

Quanto mais o tempo passa, mais o problema se agrava. Hoje, uma funcionalidade não é mais concebida de uma vez por todas: ela é ajustada, enriquecida, corrigida, às vezes durante meses ou anos. Nessas condições, é pouco realista esperar manter perfeitamente sincronizados a especificação inicial, as trocas do projeto, o changelog, a documentação de suporte, a documentação comercial e os protótipos.

O código como fonte da verdade

O verdadeiro entregável, no fundo, é o código. Talvez não seja a fórmula oficial, mas é ele que descreve o estado real do produto. O resto só tenta acompanhá-lo. Nesse sentido, a expressão "Code is Law" continua especialmente certeira: https://framablog.org/2010/05/22/code-is-law-lessig/

Durante muito tempo, essa situação foi inevitável. A documentação em linguagem natural era a solução menos ruim, principalmente porque a maioria dos product managers não trabalha diretamente no código. Era preciso, então, uma camada intermediária, compreensível por todos, usável em reunião, compartilhável com os times e utilizável sem competência técnica específica.

O que a IA muda

A IA muda essa equação agora. Quando o código está limpo e documentado o suficiente, dá para transformá-lo em uma fonte utilizável para reconstruir ou atualizar outros entregáveis. Você pode, por exemplo, partir do código real para atualizar uma documentação de suporte depois de uma entrega, gerar um changelog mais confiável ou reconstituir uma especificação funcional a partir do estado atual do produto, em vez de partir de um documento antigo.

O código não é mais só o entregável final: ele vira o elemento central, a fonte da verdade em torno da qual gravitam e se reconstroem os demais artefatos do produto, dentro de uma lógica verdadeiramente code centric.

A questão da cultura técnica

Mas isso abre outra questão: como um product manager não técnico pode tirar proveito dessa possibilidade?

As ferramentas atuais são poderosas, mas você não usa sem discernimento. Elas podem ajudar a produzir rápido, a automatizar certas tarefas e a gerar blocos úteis. Por outro lado, assim que você mexe na arquitetura, na coerência do conjunto ou na manutenibilidade, os limites delas aparecem rápido. Sem um mínimo de cultura técnica, o risco é multiplicar pequenas ferramentas eficazes localmente, mas mal articuladas entre si. Você ganha tempo aqui e ali, e depois perde esse tempo fazendo os dados circularem, lidando com incoerências ou mantendo um conjunto que ficou difícil de entender.

O desafio, portanto, não é só produzir mais rápido. É produzir dentro de um quadro coerente. É essa coerência que faz a diferença entre um amontoado de ferramentas e um verdadeiro sistema de trabalho.

Desse ponto de vista, provavelmente já existe uma diferença de capacidade entre os PMs que vêm de uma trajetória técnica e os que não vêm. Não porque uns sejam intrinsecamente melhores que os outros, mas porque os primeiros têm hoje uma alavanca a mais: eles conseguem intervir de forma mais direta no próprio material do produto, ou seja, o código, e usá-lo como base para gerar, controlar ou questionar outros artefatos.

Alguém poderia argumentar que os SaaS vão integrar cada vez mais agentes capazes de automatizar essas tarefas. É provável, e vai ser um progresso real. Mas eu não acho que isso baste para apagar a diferença. A maioria dessas ferramentas vai continuar especializada.

É justamente aí que o limite aparece. Uma ferramenta como o Zendesk provavelmente vai poder ajudar a produzir uma documentação de suporte melhor. Uma ferramenta como o Figma vai continuar excelente para desenhar telas. Mas nem uma nem outra têm, sozinhas, uma visão completa do produto real como ele existe no código, como ele evolui nos merge requests e como ele deve ser entendido no seu contexto de negócio.

Hoje, com as ferramentas certas, eu consigo, por exemplo, cruzar vários níveis de informação: o código-fonte, o histórico das evoluções, os merge requests e as regras de negócio que acumulei como product manager. Isso permite não só gerar uma documentação mais correta, mas também questionar o que já existe.

A mesma lógica vale para o design. Hoje, você desenha uma interface no Figma, e depois precisa desenvolvê-la. Mas se eu for capaz de reconstruir um design system a partir do código real, de mantê-lo atualizado conforme as evoluções do repositório, e de acrescentar as convenções de desenvolvimento do time, então o protótipo muda de status. Ele deixa de ser só uma representação: ele pode começar a virar uma primeira base utilizável pelos desenvolvedores front-end.

Em outras palavras, a fronteira entre design, implementação e documentação começa a diminuir. Não é só uma questão de produtividade. É uma transformação mais profunda: o código não é mais simplesmente o resultado do trabalho, ele vira também o material a partir do qual dá para reconstruir o resto.

O que o MCP vai mudar

Eu não afirmo que esse modelo já esteja estabilizado. Daqui a alguns meses, ele talvez esteja em parte superado. O MCP, em especial, ainda pode mudar o equilíbrio. Dá para imaginar amanhã um ecossistema em que cada SaaS teria a sua própria camada de agentes, capaz de dialogar com outros sistemas. O Figma poderia, por exemplo, recuperar contexto vindo de um repositório GitLab, ler as evoluções recentes, entender os merge requests relevantes e alinhar melhor o design à realidade do produto. Ainda não chegamos totalmente lá, mas a direção começa a ficar visível.

É por isso que o MCP me parece importante. Do mesmo jeito que as APIs se tornaram indispensáveis quando os SaaS deixaram de viver isolados, os MCPs poderiam se tornar essenciais à medida que os agentes se generalizam. Cada ferramenta vai manter a sua especialidade, mas o valor real vai vir da capacidade dela de dialogar com as outras, de recuperar contexto e de agir dentro de um ecossistema maior que o seu próprio perímetro.

A melhor atitude, nesse estágio, provavelmente é experimentar de verdade. Não para seguir um modismo, mas para entender o que já permite, na prática, criar valor. Porque a mudança em curso não é só tecnológica. Ela toca a própria natureza dos entregáveis do produto, a sua fonte da verdade e o lugar do product manager na produção deles.

Para saber mais

Adicionar uma memória de sessão como no OpenClaw Em 8 dias, entendi que a profissão de Product Manager vai mudar completamente A qualidade pertence a quem entrega A pergunta de produto deve partir do código-fonte