No início da carreira como Product Manager, salvo raras excessões, é muito comum sermos responsáveis por funcionalidades de um produto.
Também, se olharmos por uma ótica um pouco mais abrangente, no início da sua carreira em Produto você vai ser testado por meio de 4 responsabilidades ou, como eu gosto de chamar, estágios do desenvolvimento de produto. São eles:
- Validação da oportunidade de uma funcionalidade;
- Design de funcionalidades;
- Desenvolvimento de funcionalidades;
- Lançamento e iteração de funcionalidades.
A literatura de Produto foca bastante nos 3 primeiros aspectos, sempre citando e renovando os conteúdos de Product Discovery, Double Diamond, prototipação, metodologias ágeis e por aí vai. Enquanto isso, lançamento e iteração ficam em segundo plano, por não ser um trabalho de produto nem tão atraente assim.
No entanto, tão importante quanto descobrir a coisa certa a lançar, é validar se ela atingiu o objetivo e resultado programado. Da mesma forma, comunicar a solução de uma maneira que destaque seus aprendizados e performance é fundamental durante a apresentação de resultados.
Bons PMs não apenas lançam funcionalidades e partem para a próxima grande coisa. Nós tomamos decisões sobre as próximas iterações e saímos com novos aprendizados sobre o que funcionou e porquê.
Entretanto, cada empresa tem a sua forma de comunicar esses resultados, muitas vezes pouco otimizada e muito focada na experiência ofertada da funcionalidade. Por essa razão, neste texto eu vou comentar algumas dicas práticas de como comunicar essas informações para mandar bem na apresentação de resultados, além de compartilhar o template que eu uso para isso.
Quando devo comunicar?
”Opa, eu sempre comunico para as equipes internas quando a gente faz o deploy, todo mundo comemora a implementação!” Péssimo exemplo, né? Mas é porque você está com pressa.
A apresentação de resultados oficial deve acontecer após a execução de todas as etapas de desenvolvimento do produto, com os aprendizados iniciais já coletados e organizados em uma boa estrutura de Product Analytics. Sem dados, sem resultados. Aguarde até que a frequência natural do seu produto responda de acordo.
O tempo de comunicação pós-lançamento difere muito para um produto usado com mais frequência, mais de uma vez ao dia (Instagram, por exemplo) para um produto que o usuário acessa praticamente uma vez ao ano (TripAdvisor, por exemplo).
O que devo comunicar na apresentação de resultados?
Quando eu falo de comunicação pós-lançamento, os bons PMs devem cumprir 3 objetivos principais:
- Fechar o ciclo com seus principais stakeholders;
- Refinar as decisões de iteração;
- Informar o aprendizado coletivo.
Idealmente, um bom relatório deve seguir a seguinte lógica:
Contexto da funcionalidade
Primeiramente, ao preparar o cenário da comunicação, é importante revisar o contexto da funcionalidade e o que efetivamente foi lançado. Apresente o contexto em torno do propósito da funcionalidade, quais objetivos estávamos trabalhando e a entrega daquilo que lançamos.
Divida essa etapa em 2 partes:
1. Resumo da iniciativa
- Alinhamento estratégico: qual é o contexto de negócio por trás desse projeto?
- Valor para o usuário e negócio: qual é a hipotese inicial dos problemas, objetivos do usuário e o resultado esperado para o negócio?
2. Resumo dos recursos lançados
- Detalhes da funcionalidade: recomendo um vídeo curto ou um GIF (prefiro) onde você pode descrever rapidamente a experiência do usuário;
- Tradeoffs: onde possivelmente a mudança de experiência pode impactar negativamente o usuário ou outras funcionalidades;
- O que ficou para trás do plano inicial de desenvolvimento: sempre lembrar de explicar brevemente o por que da possível redução de escopo do projeto.
Avaliação da performance
Eu pessoalmente gosto de iniciar com uma frase de impacto que resume se a funcionalidade resolveu o problema do usuário ou não. Assim, consigo definir o tom da comunicação e os detalhes dessa afirmação.
Por exemplo, digamos que você esteja na tribo responsável pelo Pix de um banco digital. Você ajudou a desenvolver uma funcionalidade capaz de identificar um código de QRcode da área de transferência do aparelho do usuário e transportar ele direto para o pagamento do Pix. A frase seria mais ou menos assim:
“98% dos usuários que realizaram mais de 5 transferências Pix por mês fizeram pagamentos gerando as identificações de QRcode na área de transferência.”
Dado o tom, agora você pode detalhar, descrevendo um pouco melhor o perfil do usuário que engajou com a funcionalidade, quais eram os problemas identificados anteriormente e os objetivos que não estavam sendo cumpridos.
Não deixe de trazer as evidências sobre suas afirmações, como: o funil e a taxa de drop-out da funcionalidade, segmentação por tipo de usuário, relação entre adoção, retenção e satisfação da funcionalidade, além das análises qualitativas.
Finalmente, comunique o mais importante: o impacto. “Essa funcionalidade gerou um impacto de x% na métrica Y”.
Decisões de iterações
Essa é uma das partes mais importantes e mais negligenciadas. A não ser que você trabalhe com uma perspectiva de projeto (com escopo e timeline fechados), o produto não tem fim.
Sempre há espaço para melhorias e mudanças contínuas. Afinal, como uma ótima pessoa de Produto, você analisou os dados, conversou com os clientes e stakeholders internos, gerou os insights e trilhou os próximos passos do seu produto, dado o alinhamento estratégico.
Há 3 coisas principais que você precisa comunicar aqui:
- Recomendações de iterações;
- Seu racional por trás dessa decisão ;
- Implicações para a empresa como um todo.
Com isso feito, normalmente a apresentação fica aberta a perguntas. Ou, se você preza por um modelo assíncrono, a comentários.
Próximos passos
Lembra que mencionei que você precisa fechar o ciclo com os seus stakeholders? Geralmente novas ideias demandam muitas iterações para chegar ao ponto de entregar um valor concreto ao negócio.
É necessário receber esse feedback das equipes e internalizar se houveram indagações em aberto ou se houveram pontas soltas no lançamento, que podem ter prejudicado os processos internos. Por fim, é importante conquistar o buy-in das iterações propostas e as razões por trás das possíveis discordâncias.
Conclusão
“E daí é só estourar a champanhe e correr para o abraço?” Não. Aqui estou adimitindo que a funcionalidade deu 100% certo, o que é extremamente difícil.
É muito importante e necessário ser honesto consigo mesmo e transparente com os dados e resultados. Além de ser sucinto e objetivo durante a apresentação de resultados. Essa estrutura vai te dar confiança e poder para dizer que você progrediu com o trabalho dado, seguindo o contexto do negócio e as dores do usuário. Além disso, compreender quais são os próximos passos diante de um “fracasso” é ainda mais relevante e necessário.
Outro ponto que vale sua atenção é que, por mais que a apresentação seja estruturada em slides sem formatação (eu utilizo este template), a forma como você comunica essa apresentação também faz diferença. Digo isso pois nem todos os seus stakeholders gostam de sentar por meia hora em uma reunião para ficar olhando slides.
Devemos entender qual é a melhor forma de comunicação para obter o maior engajamento possível. Ou seja, mais do que passar um recado, você quer que ele seja internalizado. Pode ser um documento no Notion, Confluence ou até mesmo um vídeo no Loom (mas fuja do Google Docs!). Teste algumas alternativas e colete feedbacks para saber o que funciona melhor.
Leia também:
