Fato: A comunicação sobre o lançamento do produto é problemática

O objetivo das notas de lançamento do produto é informar suas equipes internas (da engenharia ao suporte ao cliente) e seus parceiros externos (clientes e parceiros) sobre as mudanças no produto. Na tecnologia, onde tudo se move em velocidade da luz, entregar atualizações do produto por meio de notas de lançamento é praticamente um problema antigo.

Toda empresa em que trabalhei teve dificuldades para fazer as notas de lançamento ficarem "certas". Mas é uma tarefa difícil de acertar; a importância de cada mudança ou lançamento do produto varia com base no público, como essa mudança altera a interação de um grupo específico com o recurso, e como esse grupo usa o produto geral diariamente.

Essas comunicações de lançamento do produto (comumente conhecidas como notas de lançamento) precisam ser entregues a públicos que se importam com coisas diferentes. Como líder de Capacitação em Receita na Guru, meus constituintes são qualquer pessoa cuja capacidade de fazer seu trabalho é impactada pelo roadmap do produto, incluindo:

• As equipes de Produto/Design/Engenharia
• A Equipe de Vendas (Operações de vendas, Vendas internas, Executivos de contas em vários segmentos)
• Experiência do Cliente (Gerentes de Sucesso e Representantes de Suporte)
• Equipe de Marketing (Marketing de Produto, Marketing de Crescimento, Marca, Conteúdo que liderará a estratégia de lançamento e divulgação à imprensa do produto)
• Desenvolvimento de Negócios e Parceiros

Todos esses parceiros precisam entender as atualizações do produto e imediatamente determinar em que medida precisam aplicar essas atualizações em seus trabalhos. Eles também precisam considerar como podem ajudar os usuários finais a entender o impacto que qualquer mudança terá sobre eles.

A pessoa (ou equipe) que elabora as comunicações de lançamento precisa considerar todos os públicos que irão consumir o conhecimento do produto. Quais são as implicações do lançamento para um engenheiro de backend versus um cliente em potencial na indústria do varejo?

Como Não Abordar Notas de Lançamento

Embora seja difícil levar em conta as necessidades de diferentes públicos, também não é escalável para um Gerente de Produto ou um Gerente de Marketing de Produto (PMM) escrever cinco versões diferentes de notas de lançamento internas. Na minha experiência, as notas de lançamento são muito longas e fora de contexto ou não têm informação técnica suficiente. Notas de lançamento estáticas não nos dão esse insight e muitas vezes são escritas para o autor, não para a pessoa que precisa entender o que mudou. Para ser francamente, elas geralmente são oportunidades perdidas.  

Participei de chamadas semanais de notas de lançamento que duravam uma hora, onde uma voz monótona da gestão de produtos falava sobre os pontos em slides. Depois que a chamada termina, aquele mesmo gerente de produto recebe e-mails, telefonemas (lembra-se deles?), mensagens no Slack, etc., de todos, desde o suporte ao cliente até vendas, que querem saber o que as mudanças significam para eles, seus clientes e potenciais clientes. Se você perdeu a chamada, perdeu nuances e contexto, e não obteve apenas o registro de alterações bruto.

Mas não é papel do gerente de produto fazer essa tradução sagrada; seu trabalho é construir um produto que resolve um problema para o mercado. É o trabalho do PMM traduzir essa intenção para que o mercado entenda seu valor.

O segredo para escrever grandes notas de lançamento de software

Sou um grande fã de A Noviça Rebelde (chocante, eu sei) e como profissional de capacitação, as lições atemporais do filme são verdadeiras. “Vamos começar pelo começo/é um ótimo lugar para começar”, passa pela minha cabeça semanalmente. Portanto, ao moldar ou remodelar um processo de entrega de produtos, você deve aprender a linguagem antes de poder ensinar o assunto.

1. Desenvolver um glossário interno

O primeiro passo para aprofundar-se neste processo significa fazer com que toda a equipe fale a mesma linguagem. Socializar a terminologia compartilhada parece óbvio, mas pode não estar acontecendo em sua organização. Não saber siglas e interpretar mal a linguagem pode ser isolante, criando confusão e silos entre as equipes.

Exemplo: Nossa equipe de marketing usa o termo “lançamento” para descrever quando e como iremos ao mercado com um recurso. No entanto, a equipe de engenharia usa a palavra “lançamento” para descrever quando um recurso foi liberado em nosso ambiente de testes. O lançamento específico da funcionalidade é “concluído” para a engenharia antes que nossos clientes saibam sobre isso. Isso era confuso e internamente conflitante.

Ninguém quer ser aquele que se pronuncia publicamente admitindo que não sabe o que significa, pedindo definições. Nossa solução: Em um grupo de trabalho interfuncional (com representação de engenharia, produto, marketing de produto), detalhamos as nuances e documentamos nossas definições de lançamento de produto:

Nota: Se algum dos Cartões falhar ao carregar, basta atualizar a página!

2. O que incluir em suas notas de lançamento

Depois que uma linguagem comum é estabelecida e sua equipe consegue articular a terminologia de lançamento, você pode escrever suas notas. A coisa mais fácil a fazer é criar um modelo reutilizável para escrever notas de lançamento. Dessa forma, os interessados se familiarizam com o formato após algumas iterações, e isso economiza o problema de ter que reinventar a roda a cada vez.

No mínimo, boas notas de lançamento incluem:

• A(s) data(s) de lançamento
• Internas e externas
• Uma descrição do recurso ou bug
• Os produtos afetados (se você tiver mais de um)
• Se você tiver vários produtos de software, também pode querer incluir os números das versões
• Onde perguntas podem ser feitas internamente

No entanto, boas notas de lançamento também incluem:

• Perguntas frequentes antecipadas (PFQs)
• Link para nova documentação pública, se disponível
• Para recursos:
• O nome do recurso
• Capturas de tela de como o recurso se parece
• Vídeo de como demonstrar o recurso
• Por que o recurso existe
• Como isso impacta as personas relevantes de compradores/clientes

Aqui está o modelo que usamos internamente (sinta-se à vontade para copiar!):

💡Nota: É útil atribuir indivíduos diretamente responsáveis por essa tarefa (em vez de deixar isso a cargo de um esforço coletivo onde ninguém é responsável). Gerentes de Engenharia ou Produto devem ficar responsáveis pela parte técnica das notas (nome/versão/produto/datas/capturas de tela), enquanto Gerentes de Marketing de Produto ou Engenheiros de Vendas devem ficar responsáveis pelas informações contextuais (personas de compradores/por que isso é importante).

Implementando uma estratégia de processo de entrega de produtos

Criar um formato de comunicação consistente

Agora que você unificou a terminologia e escreveu seu modelo, o próximo passo é concordar com um meio de entrega consistente (ou seja: Slack, e-mail, Loom, Guru, Google Docs) e metodologia. Um meio de entrega consistente garante que seus constituintes de notas de lançamento saibam onde devem ir ou olhar ou se inscrever (para puxar) e estarem a par de um lançamento.

Isso também é essencial para gestão de mudanças porque você geralmente precisa informar alguém várias vezes para garantir que eles absorvam completamente. Dependendo do tipo de lançamento, das mudanças na UI/UX (interface do usuário e experiência do usuário) e do impacto no cliente, seu público de notas de lançamento precisará ser impulsionado com conhecimentos sobre o produto (para empurrar). Na Guru, empregamos tanto metodologias de empurrar quanto puxar.

O Puxar: Onde encontrar conhecimento

Para nós, os interessados podem nos seguir em nosso canal do Slack #release-notes, onde há um formato consistente e facilmente digerível para tudo, desde correções de bugs até novos recursos que surgem. Tenha em mente que seus respectivos públicos não só precisam saber que os lançamentos estão acontecendo (via o puxar no Slack ou e-mail) mas, mais importante, precisam saber por que esse lançamento importa em contexto.

O conhecimento de que um lançamento simplesmente acontecerá ou já aconteceu não tem valor, a menos que sua equipe possa realmente fazer algo com isso. Para desenvolver um formato consistente que forneça o contexto adequado, entrevistei representantes de vendas, representantes de desenvolvimento de contas e pessoal de desenvolvimento de negócios, para estabelecer nosso modelo de entrega de produtos, que chamamos de “Cartão de Quebra de Funcionalidade”, que você pode encontrar acima.

Quando um Gerente de Engenharia inicia o desenvolvimento em uma nova funcionalidade, os indivíduos diretamente responsáveis são alertados via Asana para criar o Cartão de Quebra de Funcionalidade específico, usando o modelo de notas de lançamento. O novo Cartão de Quebra de Funcionalidade se torna a robusta, única fonte de verdade ou o “cérebro da funcionalidade” que estamos lançando. Especialistas no assunto (SME) — como PMM e engenheiros de vendas — incluem detalhes sobre por que o lançamento é valioso, para quem importa mais e, quando aplicável, orientações sobre como demonstrar o recurso como parte de uma história maior.

Os constituintes de notas de lançamento, particularmente os Executivos de Contas, retornam aos mesmos cartões repetidamente porque aprenderam que o conhecimento dinâmico no Cartão de Quebra de Funcionalidade é confiável, relevante e aplicável. Os públicos agora estão falando a mesma língua e lendo do mesmo (dinâmico) manual. Um retorno ao Cartão de Quebra de Funcionalidade ainda faz parte de um método de “puxar” porque é auto-dirigido, e feito para se preparar para uma chamada de vendas ou suporte, ou se um potencial cliente tem uma pergunta sobre o roadmap.

O Empurrar: Fornecendo conhecimento proativamente

A metodologia de Empurrar entra em cena quando o conhecimento sobre um lançamento é sensível ao tempo e crítico para equipes específicas. Aqui, isso é realizado por meio da funcionalidade de anúncios da Guru. Com base no impacto para meu público interno, eu empurro um anúncio via Guru para um grupo relevante. Posso então ver um relatório de quem reconheceu ou leu o alerta e envergonhar publicamente lembrar aqueles que não o fizeram.  

Por que uma cultura orientada ao conhecimento é a chave 🗝

Apesar de tudo isso, não é realmente tão simples assim como concordar com a terminologia, escrever notas de lançamento incríveis e criar um mecanismo para entrega dinâmica de produtos. As equipes precisam ser capazes de colaborar sobre o conhecimento e dar feedback ao longo do tempo. Fornecer feedback e melhorar o conhecimento compartilhando é parte dos papéis e responsabilidades de todos da equipe.

Para nós, isso significa que quando os consumidores de conhecimento (neste caso, os constituintes de notas de lançamento) têm uma pergunta ou aprendem algo novo, eles comentam no Cartão de Quebra de Funcionalidade. Incorporamos também as perguntas feitas e respondidas no Slack comentando como uma forma de continuamente melhorar o conhecimento. O especialista no assunto (tipicamente o PMM) revisará e incorporará esse novo conhecimento ou pergunta relevante, colocando-o em contexto no cartão de Quebra de Funcionalidade em questão.

Nós também tornamos todas as nossas notas de lançamento facilmente acessíveis, colocando-as nas seções de próximos lançamentos ou lançados de nosso Quadro de Quebra de Funcionalidade, onde podem ser organizadas internamente. Dessa forma, elas são fáceis de acompanhar à primeira vista. Se você não está usando Guru, recomendamos tentar criar uma página de notas de lançamento ou um changelog vinculado.

Como em qualquer outro processo, este está em constante evolução. A entrega de produtos e notas de lançamento nunca é tão simples quanto fazer uma única vez. À medida que as necessidades de sua empresa mudam, seu processo, responsabilidades e modelos devem mudar junto com elas. Mas ao buscar uma fácil compreensão, contexto e usabilidade, você não pode perder.