Errata

O bispo revê a obra

Por volta de 426 e 427, já no fim da vida, Agostinho de Hipona releu a própria obra em ordem cronológica e escreveu, livro por livro, o que diria de outro modo.¹ O título do trabalho, as Retractationes, costuma sair em português como retratações, e engana, porque o latim diz, em sentido literal, retratamentos: a obra é reexaminada e não renegada, com o autor a apontar onde se expressou mal e onde hoje falaria diferente.

Botticelli pintou o bispo numa cela de pedra, a escrever, e espalhou pelo chão pedaços de papel. Não sei o que quis dizer com eles, e nenhuma leitura minha o prova, mas me servem de imagem: todo autor produz mais papel do que obra, e quase nunca mostra o que jogou fora.

Lembrei do bispo ao ler a versão narrativa da palestra em que Marty Cagan, da SVPG, tenta responder a uma pergunta que, segundo ele, não lhe saía da cabeça: o que dizia antes e já não sustenta. Cagan traçou a linha na primeira edição de INSPIRED, de 2008, escrita depois de 25 anos de ofício, e listou dez coisas que aprendeu desde então e que mudam, de modo significativo, o que ele havia defendido publicamente.² A lista é longa para um ensaio só. O que me interessa nela é um padrão que o próprio Cagan não nomeia.

O que o método deixava de fora

Cinco dos dez itens são, pelas palavras dele, coisas que o método omitiu ou tratou como menores; a contagem é minha, e outro leitor poderia chegar a quatro ou a seis. Na primeira edição de INSPIRED, os riscos de um produto eram valor, usabilidade e exequibilidade, e a viabilidade de negócio vinha escondida sob a última; só dez anos depois, na segunda edição, ganhou lugar próprio, e nesse intervalo centenas de milhares de profissionais ouviram dele uma visão unilateral do papel. A omissão custou em proporção à plateia. “Subestimei por completo a importância da viabilidade de negócio”, escreve.² Cagan dá também a explicação de ofício: quase toda a sua carreira até ali se passara em ferramentas e plataformas para desenvolvedores, um dos raros lugares em que se escapa impune com pouco saber de negócio.

A liderança de produto ficou de fora por escolha deliberada, com consequências que ele não previu, pois as empresas entenderam que bastava montar os times como no livro. A política foi ignorada na esperança de que o bom trabalho bastasse. A governança da empresa parecia assunto alheio ao líder de produto, e a concorrência foi descrita com mais cortesia do que ela tem.

Escrevi em O preço de tudo que especificar é decidir o que o sistema tem permissão de ignorar. A frase vale para o livro de Cagan: um método publicado é uma especificação para organizações, e uma organização obedece ao que lê com a fidelidade do otimizador de anúncios, que fez exatamente o que mandaram. O que a especificação cala, ela autoriza a ignorar. Quem entrega um documento a um agente de IA, que não tem a cultura da casa para preencher o silêncio, escreve o mesmo livro para um leitor menos caridoso, ao menos é o que suponho.

Como a mensagem foi ouvida

Os outros itens tratam da recepção. Cagan conta que o principal que muita gente tirou dos textos dele foi a ideia de que precisava ser o “CEO do produto”, mensagem que dificilmente se chamaria de humilde. Conta também que, ao estruturar o livro em pessoas, processo e produto, alimentou sem querer a fome de processo de quem prefere não pensar. “Processo, muitas vezes, é de fato usado como substituto do pensamento”, escreve.² O autor que escolhe o título de uma seção escolhe também o cartaz que a leitura apressada vai levar para casa.

Entre os artefatos mais típicos do ofício, Cagan aponta dois pelo nome, o roadmap e o PRD, e pergunta o quanto eles ajudam “a pensar que sabemos mais do que de fato sabemos”.² Para um Product Owner a frase incomoda, porque esses são os documentos que ele mais escreve. O texto que sai da mão de quem especifica é lido por quem decide, por quem constrói e, cada vez mais, por uma máquina, e o leitor fica com o título, a primeira seção e o slogan. O resto fica no papel.

Tiro daí um teste simples, que nasce da confissão de Cagan e não vem de experiência minha com ela: ao fechar um documento de produto, perguntar o que um leitor apressado levará dele e qual omissão esse leitor vai tomar por licença. O teste custa pouco.

Diagnóstico e remédio

Outro item da lista fala do lugar em que as equipes gastam o tempo. Cagan conta que sempre separou a descoberta do problema da descoberta da solução, e que não previu a força com que as pessoas se deixariam atrair pela primeira, a ponto de se tomarem por guardiãs de saber se existe um problema digno de ser resolvido, sobrando pouco tempo para a solução. Muitas vão além e se perguntam se aquele é o problema mais importante a resolver, o que ele chama de pergunta infrutífera e sem resposta: tudo o que se pode saber é que o problema é real e vale a pena. Quando um produto fracassa, sustenta ele, quase sempre foi porque a solução do time não era boa o bastante; parece que faltava cliente com o problema, até que alguém aparece com uma solução melhor e a causa fica constrangedoramente clara.

Na operação que contei em O preço de tudo, o diagnóstico estava certo e o remédio é que fui superestimar: o sinal de valor que eu tinha especificado resolvia a proporção entre conversas caras e baratas, sem resolver sozinho o custo de aquisição. O custo por conversa, esse, media com exatidão, e o erro foi deixá-lo sozinho na tela. Um caso não prova nada; este, porém, não contradiz o que Cagan diz da solução, porque o sinal de valor era a solução e foi ela que errou de tamanho, e a correção veio de procurar o teste que podia contradizê-la.

Errata como método

O ponto que mais me interessa na confissão é o modo de trabalho que ela revela. Cagan diz que trata o próprio conteúdo como produto, e que faz, toda semana, descoberta de produto sobre ele. Vista assim, a errata é o que uma empresa chamaria de entrevista de churn, a conversa com quem deixou de usar. Coincide com o que ele considera o “porquê” mais importante, aquele que as equipes quase nunca perguntam: por que as pessoas continuam usando o produto, ou deixam de usá-lo. Ele conta que raramente alguém o procura, depois de abandonar um produto que testou, para saber o motivo.

Quem faz produto deveria aceitar a disciplina que aplica ao cliente. No caso que acabo de contar, achei o erro porque a hipótese estava escrita antes, com fonte e nível de evidência, e porque fui atrás do teste que podia me contradizer. A errata, ali, já existia antes do erro, na forma de uma hipótese datada, e faltava só o dia em que a evidência a contrariasse.

Proponho, como costume de ofício, que todo documento de produto termine com duas seções curtas. A primeira lista o que ficou de fora e por quê, isto é, o silêncio que o leitor poderá tomar por licença; a segunda lista o que acreditamos hoje e qual dado o desmentiria, e deixa espaço para a data em que isso acontecer. Nenhuma das duas pede ferramenta nova; pedem a coragem pequena de escrever, no dia da aprovação, o ponto em que o texto é mais frágil.

Seguro com frouxidão

O título do texto de Cagan traz uma fórmula conhecida, e a dificuldade dela está na segunda metade. Segurar uma opinião com frouxidão costuma ser tratado como traço de temperamento, e o que a confissão de Cagan mostra é que se trata de um lugar concreto, um arquivo datado em que a opinião pode ser corrigida sem que ninguém precise fingir que nunca a teve.

A frouxidão com que se segura uma opinião mede-se pelo tamanho da errata que ela admite.

Cagan conclui que, mesmo com esses erros, o conteúdo nunca foi tão relevante, e o argumento é dele: não me cabe avaliá-lo. O método, esse eu reconheço, e é o de Agostinho, a obra relida em ordem e o que resiste à releitura mantido com mais crédito do que antes. Sobra o desconforto de ser o primeiro a procurar, no próprio documento, o que ele deixou de dizer.

Que a primeira linha da errata fique em branco no dia da aprovação, e seja escrita no dia em que o dado a exigir.

Fonte: Marty Cagan, “Strong Opinions, Loosely Held”, SVPG, 11 de setembro de 2026.