Como anunciar uma funcionalidade nova (sem silêncio)
5 min de leitura
A maioria dos anúncios de funcionalidades morre em um canal que ninguém lê duas vezes: um tweet que passa rolando, um e-mail do dia do lançamento enterrado sob os outros doze que uma assinante recebeu naquela semana, uma mensagem no Slack em um canal que metade do time silenciou meses atrás. A funcionalidade foi lançada. Quase ninguém que a usaria ficou sabendo. Consertar isso tem menos a ver com escrever um anúncio melhor e mais com escolher o canal certo para a leitora certa, e alcançar diretamente quem pediu explicitamente por aquilo, em vez de contar com o fato de que vão notar uma mensagem geral.
Onde uma funcionalidade nova deveria realmente ser anunciada?
Em mais de um lugar, porque “todo mundo lê o mesmo canal” nunca é verdade. Uma entrada de changelog ou feed serve a leitora que confere no próprio ritmo e quer o registro permanente e datado. Um aviso no app serve a leitora que já usa o produto e usaria a funcionalidade hoje se soubesse que ela existe. E-mail serve a leitora que não está atualmente no produto mas voltaria pela atualização certa. Redes sociais servem alcance além das usuárias existentes, quase sem segmentação.
| Canal | Melhor para | Fraqueza |
|---|---|---|
| Changelog / feed | O registro permanente; leitoras que conferem no próprio ritmo | Passivo; não faz nada por quem nunca confere |
| Aviso no app | Usuárias já presentes que agiriam hoje | Não alcança ninguém que não esteja logada agora |
| Usuárias inativas que voltariam por isso | Fácil de enterrar sob outros e-mails; precisa de um assunto de verdade | |
| Redes sociais | Alcance além das usuárias atuais | Quase sem segmentação; vida útil curta |
Nenhum dos quatro é suficiente sozinho. O changelog é o único documento que deveria carregar todo lançamento independentemente do tamanho, porque é o registro para o qual tudo o mais aponta de volta; os outros três são amplificação adicionada por cima, escolhida de acordo com o quão grande a funcionalidade realmente é.
O que o anúncio deveria dizer primeiro?
O resultado, não o mecanismo. “Adicionamos uma camada de cache ao endpoint de relatórios” descreve o que o time construiu. “Relatórios agora carregam em menos de um segundo” descreve o que mudou para a leitora, e essa é a frase que consegue o clique, porque responde “o que eu ganho com isso” na primeira frase em vez da terceira. O mecanismo pertence à entrada do changelog ou à página de detalhes, não ao título.
Concreto antes de adjetivos. “Uma experiência de relatórios mais rápida e poderosa” não diz nada à leitora sobre o que fazer; “relatórios agora carregam em menos de um segundo e podem ser filtrados por status” diz exatamente o que mudou e o que experimentar. A segunda versão também parece mais confiável, porque uma alegação vaga soa exatamente como soa o texto de marketing quando não há nada concreto a dizer.
Como isso difere de um e-mail de atualização de produto?
Se sobrepõem mas não são idênticos. E-mail de atualização de produto cobre o canal de e-mail especificamente, incluindo cadência, assuntos, e quando um digest vence um envio único. Um anúncio de funcionalidade nova é o evento subjacente; o e-mail é um dos quatro canais acima que poderia carregá-lo, escolhido quando a funcionalidade é grande o suficiente para justificar um envio dedicado em vez de andar carona no próximo digest. Uma funcionalidade pequena merece uma entrada de changelog e talvez um aviso no app. Uma significativa merece os quatro canais, coordenados no tempo.
Como alcançar as pessoas específicas que pediram por isso?
Esse é o anúncio com o melhor retorno sobre esforço, e quase todo time o pula. Se dez clientes
pediram uma funcionalidade pelo nome, essas dez pessoas merecem uma nota direta e pessoal no
momento do lançamento, independentemente de qualquer anúncio mais amplo que saia. Fechando o ciclo de feedback com o cliente
cobre a mecânica por completo; o resumo aqui é que isso só funciona se o pedido original
continuar ligado a quem o fez, o que é mais um problema de rastreamento
do que um problema de anúncio. No changeloop, quando um feedback pelo widget virou uma issue do GitHub
e o pull request mergeado a fecha (fixes #142), aprovar a entrada do changelog posta nessa issue o
comentário “Shipped —
Como se escreve a entrada em si?
A mesma disciplina de qualquer outra entrada de notas de versão: comece com o que a leitora já pode fazer, continue com a configuração necessária, pule a justificativa interna. Como escrever notas de versão cobre o método completo; um anúncio de funcionalidade nova é o caso de maior risco, porque é a entrada com mais chance de ser capturada em print, encaminhada, e lida por alguém que nunca viu o changelog do produto.
Quando não anunciar amplamente?
Quando a funcionalidade ainda está sendo lançada para um subconjunto de contas, é realmente uma beta, ou tem preço ou bloqueio tais que nove em dez leitoras de um anúncio amplo ainda não conseguiriam usá-la. Um anúncio amplo para uma funcionalidade que nove em dez leitoras não podem usar se lê como uma isca, e queima a confiança no próximo anúncio mais do que constrói entusiasmo neste. A solução não é o silêncio, é o alcance: informe diretamente as contas elegíveis e segure os canais amplos até a disponibilidade alcançar o anúncio.
FAQ
Toda funcionalidade nova merece seu próprio anúncio? Todas merecem uma entrada de changelog. Só as significativas o suficiente para mudar como alguém usa o produto, ou as pedidas explicitamente pelo nome, merecem os canais mais amplos como e-mail ou redes sociais.
Qual é o melhor canal para uma funcionalidade pequena? Só o changelog, mais um aviso no app se a funcionalidade for descobrível em um fluxo em que a usuária já está. E-mail e redes sociais valem a pena para funcionalidades que justificam pedir atenção.
Como anunciar uma funcionalidade às pessoas que especificamente pediram por ela? Mantenha o pedido ligado a quem o fez desde o momento em que é registrado, depois notifique individualmente no lançamento, separado de qualquer anúncio mais amplo. Uma etiqueta de status compartilhada que quem pediu pode conferir sozinha também reduz quantas mensagens individuais são necessárias em primeiro lugar.
Um anúncio de funcionalidade precisa de um print? Para qualquer coisa visual, sim; uma funcionalidade descrita mas não vista é pulada com muito mais frequência do que uma para a qual as leitoras conseguem ver uma prévia. Para uma API ou capacidade de backend, um exemplo de código curto faz o mesmo trabalho que um print faria para uma mudança de UI.
As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.