Esse artigo faz parte da série destes outros 3 artigos:
- Medindo o sucesso das funcionalidades através da adoção
- Medir a satisfação de funcionalidades é diferente da satisfação de produtos
- Quando e como tirar uma funcionalidade do ar
Esse é o típico assunto que todos na área de Produto sabem que é necessário e, mesmo assim, falamos pouco sobre ele. Como consequência, nós fazemos isso poucas vezes também. É daí que surgem aqueles produtos complexos cheios de funcionalidades que ninguém usa.
Isso acontece porque é mais doloroso tirar uma funcionalidade do ar do que lançar algo novo.
Precisamos falar mais sobre como matar funcionalidades e como podemos tirá-las do ar de uma maneira que não machuque o negócio ou a relação com os clientes.
Fato curioso: os “gringos” gostam de chamar isso de “sunset”, pois é algo mais fofo do que falar “matar” ou “desligar” uma funcionalidade. Então se você ler em algum lugar “sunset de feature”, é a mesma coisa.
O que avaliar para saber se devo tirar a funcionalidade do ar
Os principais motivos para descontinuar uma funcionalidade são esses:
- Desalinhamento com a estratégia atual da empresa ou produto (exemplo: Uber encerrou o Uber Eats);
- Muitos bugs e difícil de dar manutenção, o que gera altos custos (exemplo: Twitter revendo a estratégia de dar selo azul para todos);
- Engaja apenas um nicho específico de usuários e não é o tipo de estratégia adotada (exemplo: feature de agendamento que mencionei em outro artigo sobre Easy Taxi);
- Resolvia um grande problema no passado mas hoje o engajamento é baixo;
- Redundância com novas funcionalidades que foram lançadas depois (o antigo programa de Rewards do Nubank que não fazia mais tanto sentido com o Ultravioleta e outras funcionalidades da empresa).
Uma boa prática para identificar se você tem uma funcionalidade com um ou mais atributos citados acima é começar respondendo algumas perguntas. Vou deixar abaixo algumas que gosto de responder antes de tomar a decisão:
Perguntas gerais
- A feature falhou? Por que?
- Qual o benefício de desativá-la?
- Redução de custo? Foco da equipe? Facilitar a UX para os usuários?
Perguntas referentes a Adoção
- Como está a adoção da feature? Por que ao olhar para as métricas a feature deveria ser removida?
- As pessoas usam a primeira vez e voltam pra usar novamente?
- Qual é o tamanho da base de usuários existente que usa a feature?
Perguntas referentes a Satisfação
- Qual é a satisfação da feature?
- Qual o esforço ao usar essa funcionalidade?
- Os usuários acham que ela é complexa? /
- Será que não vale refazer a UX ao invés de desligá-la? Tem potencial?
Perguntas referentes a Receita
- Quanto de receita essa feature gera diretamente? E indiretamente?
Perguntas adicionais para o B2B
- Se o uso é baixo em geral, mas um número não insignificante de clientes com ticket médio está usando: qual vai ser a abordagem para fazer essa mudança?
- Você tem algum grande cliente que pagará muito para ser a exceção à regra?
- Você pode, em vez disso, encerrar o desenvolvimento de novos recursos e apenas fazer correções de bugs?
No B2B é um pouco mais complexo
Mesmo depois de responder todas as perguntas e ter alguma clareza de que o melhor caminho é o desligamento da funcionalidade, pode ser que alguns clientes importantes a utilizem.
Imagine a seguinte situação: você tem um número significativo de clientes com ticket alto como parte do segmento que usam a funcionalidade em questão. Tomar uma decisão de tirar ela do ar pode não ser uma boa, especialmente quando seu produto atende diferentes segmentos.
Em casos como esses a decisão é ainda mais difícil e exige um alinhamento redobrado com toda a empresa, pois tais remoções de funcionalidades podem gerar um prejuízo. Em termos de comunicação isso precisa acontecer com muita antecedência – já vi empresas congelarem o desenvolvimento da feature que será descontinuada e avisarem por 6 meses (já vi até 12 meses para features maiores) que ela será descontinuada. E somente usuários antigos poderão enxergar ela. É uma alternativa interessante.
É extremamente importante você ter uma timeline clara para os seus clientes e internamente também. O Mixpanel fez isso muito bem com o produto “Messages & Experiments”. Veja a comunicação completa aqui.
Eu achei um excelente exemplo – na verdade uma aula – de como desligar uma funcionalidade. Eles deixaram claro que sabem que milhares de empresas criaram campanhas nessa feature e precisam de um tempo para mudar de ferramenta. Eles deram grande prazo até desligar, o que acalma a ansiedade e dá aos clientes oportunidades de ajuste e mitiga as chances de churn.
Além disso, você ainda pode sugerir produtos diferentes para os quais seus clientes podem migrar – ou até facilitar a migração desse caso de uso específico, se for possível fazer via API. Suavizar a migração para seus clientes é uma maneira de manter um bom relacionamento com eles e evitar churn – foi algo que o Mixpanel fez nesse case.
Outra oportunidade é cobrar um valor adicional para manter a funcionalidade – isso é ainda mais comum no B2B. Se você conseguir extrair um ROI bom, poderá ser possível alocar uma equipe para essas features mais robustas de clientes específicos. É o tipo de coisa que entra em vários planos “Enterprise” de produtos SaaS, por exemplo.
Outro fator que precisa ser levado em conta: manter a feature para esses clientes B2B que tem ticket alto vai gerar problemas de suporte ou atendimento? Se for, é possível alocar parte dessa receita para deixar a equipe mais robusta? Como pessoa de Produto você precisará pensar e alinhar todas essas pontas.
Como lidar com a comunicação interna e stakeholders
Você precisará ter um excelente racional para mostrar porque quer desligar a funcionalidade – e de preferência conectar com a estratégia da empresa. Normalmente você irá encontrar resistência de vários stakeholders – muitas vezes de outras áreas e que possuem uma força na empresa.
O importante aqui é ter um bom alinhamento com sua liderança, pares e até mapear os possíveis stakeholders que podem não concordar (uma matriz de stakeholder pode ajudar a estruturar esse plano de comunicação).
Outra dica importante é: dê um deadline para o desligamento da funcionalidade, mas já planeje dois adiamentos, pois imprevistos acontecem. Podem aparecer clientes ou stakeholders de última hora que querem segurar por mais um tempo.
O que fazer ao decidir que vai tirar a funcionalidade do ar? Esses passos podem ajudar:
- Primeiramente envolva alguém de Product Marketing para ajudar na comunicação (se for possível, é claro);
- Dê alternativas para que os usuários saibam o que podem usar, já que seu produto não dará mais suporte em relação àquela feature;
- Agradeça aos clientes pelo apoio;
- Forneça informações de contato para que eles possam tirar suas dúvidas.
Canvas para decidir se deve desligar ou não uma funcionalidade
Para auxiliar você nesse momento, preparei um canvas que pode auxiliá-lo para tomar a decisão. Basicamente é um condensado de tudo que falei aqui neste artigo e acho que pode facilitar discussões e dar uma visualização mais clara do todo.
Para baixar o canvas, basta preencher o nome e email abaixo.
Conclusão
Portanto, resumidamente:
- Identifique os motivos pelo qual você acha que deve tirar a funcionalidade do ar;
- Responda as perguntas chaves citadas acima;
- Veja se as métricas estão realmente ruins (adoção, retenção e satisfação);
- Coloque na balança os prós e contras;
- Alinhe muito bem com os stakeholders;
- Dê tempo para os seus clientes se organizarem e não deixe eles na mão. Ajude-os!
Esse artigo faz parte da série destes outros três artigos. Leia os outros:
- Medindo o sucesso das funcionalidades através da adoção
- Medir a satisfação de funcionalidades é diferente da satisfação de produtos
- Quando e como tirar uma funcionalidade do ar
