A feature foi entregue. Então por que ninguém está usando?
Comunicação também é trabalho de produto. Por que o deploy não é o fim do ciclo de uma feature — a adoção é.
Comunicação também é trabalho de produto. Por que o deploy não é o fim do ciclo de uma feature — a adoção é.
Em uma reunião com um cliente insatisfeito, comecei a ouvir uma lista de funcionalidades que, segundo ele, estavam faltando no produto. Enquanto ele falava, eu reconhecia cada item. Algumas daquelas funcionalidades existiam há meses.
Nem o cliente sabia. Nem a equipe de Customer Experience que estava na sala sabia. E naquele momento ficou claro para mim que o problema não era apenas o produto. Era a comunicação ao redor dele.
O constrangimento daquela reunião foi útil. Ele tornou visível algo que eu já sentia, mas não havia articulado direito: a empresa não tinha um sistema de circulação de conhecimento sobre o produto. Tinha um processo de desenvolvimento de software. Mas não tinha um processo de desenvolvimento de entendimento.
Times de produto tendem a tratar o deploy como o ponto final de uma feature. O ticket fecha, a sprint termina, a entrega é celebrada. Mas o cliente não experimenta o deploy. Ele experimenta o entendimento — e a adoção vem depois disso.
Enquanto o time comemora o merge, o cliente segue sem saber que o problema dele foi resolvido. O vendedor promete um fluxo diferente do que foi construído. O suporte ensina o caminho antigo. O onboarding sequer menciona a novidade. E a feature, por melhor que seja tecnicamente, começa a morrer antes de ser usada.
Uma feature não está realmente entregue até que os clientes estejam usando.
A consequência mais imediata da falta de comunicação é a adoção baixa. Mas existe um custo menos óbvio: a frustração acumulada do time. Engenheiros que passaram semanas construindo algo robusto veem tickets de suporte abertos para problemas que já foram resolvidos. Designers que pensaram cada detalhe do fluxo percebem que ninguém chegou a ver aquele fluxo.
Parecia que o trabalho do time era invisível. E essa sensação não era infundada — era o diagnóstico correto de um problema sistêmico. Features mais ousadas morriam não por falta de qualidade, mas por falta de caminho entre a entrega e o entendimento.
Já quando a comunicação funcionava, o contrário era notório. A adoção era mais rápida. Os clientes chegavam nas reuniões com perguntas sobre como usar melhor o que existia, não reclamando da ausência do que já estava lá. A equipe sentia que o trabalho valia.
Documentação sempre existiu. Mas passei a ir além disso. Comecei a organizar o backlog indicando também os stakeholders internos interessados em cada feature — não apenas para rastreabilidade, mas para garantir que as pessoas certas soubessem o que estava vindo. Quando a feature saía, eu comunicava para toda a empresa, marcando diretamente quem precisava repassar para clientes ou parceiros externos.
Para mudanças mais complexas, passei a gravar vídeos demonstrativos — com o meu rosto, mostrando o produto funcionando. Não terceirizava isso para um texto de release notes que ninguém leria até precisar. Quando a feature era muito disruptiva, o vídeo era regra. Alinhei com outras áreas que, sempre que julgassem necessário materiais adicionais além da documentação, podiam sinalizar — e eu garantia que o material existia antes do lançamento.
A mudança mais simbólica foi incluir o enablement como etapa oficial no quadro Kanban, após o deploy. Não era uma tarefa opcional que poderia ser pulada sob pressão — era parte da jornada da feature. Enquanto essa etapa não estava completa, a feature não estava entregue de verdade.
Um erro recorrente ao lançar features é esperar que os clientes as descubram por conta própria.
Muitos PMs acreditam que o trabalho se resume ao produto em si. Na prática, um PM frequentemente precisa se envolver com outros times, não como exceção, mas como parte da função. E comunicação de produto não é periférica; ela faz parte do processo de construção.
Um time stream-aligned de produto deve ser suficientemente autônomo para repassar esse conhecimento, com o PM como centro de gravidade. Isso não significa que engenheiros e designers não contribuem; eles contribuem, especialmente em documentações técnicas. A orquestração, porém, é responsabilidade do PM.
Empresas maduras tratam product enablement como parte do processo de construção do produto, não como um apêndice. A diferença entre uma empresa que subestima isso e uma que não subestima aparece na adoção, na percepção do cliente e na moral do time.
O cliente não separa produto, CX, onboarding e suporte. Ele enxerga uma única experiência. Quando há gaps internos de comunicação, esses gaps aparecem para ele como desorganização da empresa — não como um problema de processo interno que você ainda está resolvendo.
A pior sensação em produto é sentir que você está construindo algo que ninguém vai usar. E muitas vezes isso não acontece porque a feature era ruim. Acontece porque ninguém construiu o caminho entre a entrega e o entendimento.
O ciclo de uma feature só fecha quando os clientes estão usando.