Onde publicar o changelog do seu produto: 5 lugares que funcionam

Escrever um bom changelog é só metade do trabalho. A outra metade, que quase todo mundo erra, é publicar num lugar onde o usuário realmente vê. Um changelog escondido num arquivo do repositório não serve pra nada — ninguém além do time técnico vai lá. Aqui estão os cinco lugares que funcionam, do mais eficaz ao menos, e um que parece boa ideia mas é furada.

1. Dentro do produto, num widget (o mais eficaz)

O melhor lugar pra avisar sobre uma novidade é onde o usuário já está: dentro do seu produto. Um widget de novidades (aquele sininho no canto, com um contador de não-lidos) coloca o changelog na frente de quem importa, no momento em que a pessoa está usando a ferramenta.

É de longe o que gera mais visualização, porque não depende de a pessoa abrir email nem visitar uma página. Ela vê o pontinho vermelho, clica, lê. Um widget leve (uns 10 kb, sem framework) instala com uma linha de <script> e não pesa no seu produto.

2. Uma página pública hospedada

Toda novidade também deveria ter um endereço fixo na internet: uma página tipo seudominio.com/novidades ou hospedada pelo próprio serviço de changelog. Serve pra:

• linkar em emails, posts e redes
• quem quer ver o histórico completo
• SEO — a página é indexável, então quem busca por atualizações do seu produto acha

3. Um feed (JSON ou RSS)

Um feed machine-readable é o changelog que outras ferramentas consomem: um Slack que posta as novidades num canal, um site que puxa as últimas mudanças, ou até um agente de IA que acompanha seus releases. É invisível pro usuário final, mas destrava integrações que multiplicam o alcance.

4. Email

Email ainda funciona pra lançamentos grandes — aquele "resumo do mês" ou o anúncio de uma feature importante. Mas com moderação: a taxa de abertura é baixa e mandar email a cada correçãozinha vira spam. Guarde o email pro que realmente merece interrupção.

5. Redes sociais e comunidade

Postar novidades no LinkedIn, no X ou numa comunidade (TabNews, Reddit, Discord do produto) alcança quem ainda não é seu usuário. Não substitui os outros canais, mas é ótimo pra atrair gente nova e mostrar que o produto está vivo.

Onde NÃO publicar (mas todo mundo faz)

• Só num CHANGELOG.md no repositório. Isso serve pro time de engenharia, não pro usuário. Se é o único lugar, seus clientes nunca vão ver.
• Num doc do Notion/Google Docs que ninguém tem link. Se a pessoa precisa pedir o link, ela nunca vai pedir.
• Só no email. Já falamos: abertura baixa, e o que não foi aberto some.

A regra que resume tudo

O changelog tem que ir até o usuário, não esperar o usuário ir até ele. Por isso o widget dentro do produto ganha de todos os outros: é o único que aparece sem exigir nenhuma ação da pessoa.

O ideal é publicar uma vez e aparecer em vários desses lugares de uma vez só. É o que o Nowledge faz: você escreve a novidade num painel e ela vira, ao mesmo tempo, o widget dentro do seu produto, uma página pública e um feed — sem você postar em três lugares na mão. Dá pra testar de graça, sem cartão.

Se ainda está montando o conteúdo em si, veja o modelo de changelog pronto.