Por que é importante encerrar features de produto?

minutos de leitura

16 de maio de 2022

Escrito por
Beatriz Donegá

De forma simples, pode-se dizer que as empresas nascem por um motivo: resolver algum problema do mundo, tornando a vida de seus clientes e usuários melhor com o uso daquele serviço ou produto.

Porém, é natural que à medida que estas empresas cresçam, cresça também a complexidade de seus produtos. O principal motivo é porque a hipótese principal foi validada e, com isso, surge a necessidade de ampliar seu escopo de atuação para novas fontes de receita (produtos adicionais) que agregam valor para o negócio. Dessa forma, com novos produtos ou frentes de atuação, a complexidade do negócio aumenta porque surgem mais necessidades dos clientes e, com isso, novas features de produtos para sanar esses novos problemas dos usuários.

Acontece que a relação entre quantidade de features e felicidade dos usuários não é linear. Geralmente há um ponto ótimo em que a felicidade dos clientes está em seu máximo e, com a adição de novas funcionalidades aos produtos, acaba-se por comprometer a satisfação desse cliente, conforme o gráfico abaixo.

Dessa forma, é importante que os profissionais de produto avaliem e entendam se o produto chegou num ponto de estar complexo demais para os usuários. Se sim, é hora de fazer mais com menos e agir para evitar que o produto se torne um “Feature Creep”, ou um produto Frankenstein.

Quais as razões para encerrar uma feature?

É comum observar alguns sintomas que podem indicar quando está na hora de eliminar funcionalidades de um produto, sendo os mais comuns: redução no engajamento de usuários, métricas de produto lineares, custo de suporte e manutenção cada vez maior e até mesmo queda nas vendas. A lista abaixo, adapatada do artigo com perspectivas da Reforge e Mixpanel, resume as principais razões que podem levar ao encerramento de uma feature.

  • Bugs → A feature chegou a um ponto em que gera muitos bugs e atrapalha a experiência do usuário;
  • Custos técnicos → A manutenção dessa feature tende a levar a custos técnicos muito elevados, como custos de armazenamento, custos de atendimento pelo suporte, vulnerabilidade de segurança, etc;
  • Redundância → Existem no produto mais de uma feature que realizam a mesma função;
  • Uso nichado → Apenas um grupo específico e pequeno de usuários utiliza a funcionalidade. Muito comum em casos B2B, o que pode ser um problema para o encerramento caso o nicho envolva clientes responsáveis por boa parte do faturamento da companhia;
  • Incompatibilidade → A feature funciona em outros produtos, geralmente concorrentes, mas não funciona para a empresa;
  • Desalinhamento estratégico → Não faz mais sentido com a nova visão e alinhamento do negócio;
  • Obsolescência → A feature foi criada para resolver um problema antigo que, por algum fator externo, não existe mais;
  • Novidade → A feature foi lançada, mas o retorno foi aquém do esperado para o prazo estipulado de validação.

Em qualquer um dos casos, se entendido que a razão para o encerramento de uma feature é válida, é recomendado seguir os passos abaixo para o encerramento da mesma.

Quais são os passos para encerrar uma ou mais features?

Ao longo do curso “Simplificando produtos: A importância de se remover funcionalidades” o professor Danilo Roselli, que é Product Manager com passagem por várias empresas no Brasil, resume as etapas necessárias para que o encerramento de uma feature de produto seja bem sucedido. Elas se resumem em 6 passos:

1. Diagnóstico

Aqui o objetivo é reunir dados e análises que sustentem a hipótese de que uma ou mais razões identificadas para a remoção da feature são válidas, ou seja, que comprovem o impacto negativo que a manutenção da feature está causando para o produto ou satisfação dos clientes. O objetivo é montar um “case” mesmo, explicando o problema e a melhoria esperada em determinados indicadores de negócio caso a remoção seja feita. Alguns exemplos podem ser:

a) A funcionalidade não agradou aos clientes. Teve pouquíssimo engajamento (Cohort baixo), tornou a experiência de uso mais complexa, devagar e gerou insatisfação generalizada por parte dos usuários. Ou seja, foi observado que a hipótese de adição da feature (trazer mais satisfação, melhorar a experiência, resolver alguma dor do usuário) não se concretizou e, na verdade, caminhou em sentido oposto;
b) A funcionalidade está causando muitos bugs, o que torna os clientes insatisfeitos, tendo sido relatada 20 vezes como ponto de dor na última pesquisa de satisfação realizada com os usuários;
c) A funcionalidade tem um custo altíssimo para a companhia, apenas 10% dos clientes a utilizaram no último ano e existe uma empresa parceira que poderia oferecer o mesmo serviço aos clientes por um valor atrativo.

2. Mapeamento de riscos

Uma vez em posse dos dados e análises que ajudam a comprovar a hipótese de que a remoção de uma feature é importante, é necessário também mapear os riscos envolvidos com essa ação. Eles podem entrar em várias categorias de riscos, mas os mais comuns são riscos financeiros (quando a feature é utilizada por um grande cliente, o que pode impactar negativamente a receita) ou riscos de imagem (chance da parcela nichada de usuários se tornar detratora do produto).

3. Alinhamento com stakeholders

Após reunir todos os dados, argumentos e estar preparada para os contrapontos possíveis (riscos), chega o momento de alinhar com stakeholders e validar os próximos passos para o encerramento da feature. Essa é uma etapa que pode envolver várias reuniões e exige bastante empatia para ouvir as ponderações de quem será impactado por essa alteração no produto e comunicação. O ponto principal é deixar claro o porquê da remoção da feature, destacando o cronograma que será executado e se existem alternativas possíveis para que os clientes e usuários não fiquem sem o recurso em questão.
Como a remoção de features ainda não é um processo tão comum e discutido dentro das empresas, pode ser que essa etapa demande por mais análises, alinhamentos com equipes envolvidas e paciência. Além disso, é importante ter em mente que a decisão nunca será unânime. Porém, é importante garantir que a comunicação ocorra da melhor forma possível, visando pelo melhor para o negócio e os usuários, de forma que todos os envolvidos estejam alinhados e cientes dos próximos passos.  Uma dica é utilizar os 3Ps:

  1. Perspectiva - os recursos vão ser destinados para iniciativas mais relevantes dentro da empresa;
  2. Planejamento - reforçar etapas e datas;
  3. Paz - documentar a decisão com os stakeholders e seguir para os últimos passos.

4. Comunicação

O momento da comunicação é crucial para que o encerramento da feature ocorra de forma fluida. Sarah Park, Content Designer no Slack, resume esta etapa em 5 passos:

1. Seja clara: garantir que o cliente ou usuários não tenham dúvida do que está para acontecer, o que perdem, o que ganham e como a utlização do produto será afeatda sem a feature. É importante também adequar o conteúdo à audiência, ou seja, se a justificativa for técnica, adaptar a linguagem e os termos para os clientes por meio de analogias pode ter um resultado melhor;

2. Seja empática: mudanças, perdas e transições nem sempre são bem aceitas pelos usuários. Por vezes podem impactar seus hábitos, forma como consomem uma informação ou realizam determinada ação. Por esse motivo é importante mostrar que entendemos o lado das pessoas que utilizam o produto e explicar que, por mais que seja uma frustração, o objetivo com a mudança é sempre melhorar;

3. Comunicar antes e frequentemente: aqui ser repetitivo não é um problema, mas sim uma estratégia para não pegar ninguém de surpresa. O ideal é ter um plano de comunicação sobre o encerramento da feature o mais cedo possível e que seja realizado por várias frentes (email, canais de comunicação com o cliente, alerta na plataforma), buscando garantir que, no momento da eliminação da feature, todos os usuários e clientes estejam por dentro dessa ação;

4. Forneça uma perspectiva futura: por perspectiva podemos adotar várias ações como permitir que o cliente escolha ficar sem a feature naquele momento ou posteriormente, se possível; informar a ele que com a perda da feature existem caminhos alternativos, como um parceiro que fornceça o serviço por exemplo; ou demonstrar que em breve o produto contará com novidade que são superiores à feature que está sendo eliminada naquele momento;

5. Reforce que eliminações de feature são positivas: elas permitem que o produto foque no que importa aos usuários, continue os deixando satisfeitos e cresça sendo mais consistente e confiável.

5. Implementação

O processo de implementar o encerramento da feature é muito particular a cada contexto. Porém, algumas ações práticas que podem ser executadas são

    1. Estancar o “problema”, ou seja, impedir que novos clientes adquiram o produto com a feature que será removida;
    2. Realizar uma comunicação "in app" explicando o que está sendo removido;
    3. Dividir os clientes atuais em grupos por complexidade:
      1. Clientes que pouco usam ou não usam a funcionalidade: comunicar e remover sem estresse;
      2. Clientes que mais usam a funcionalidade: Comunciar frequentemente, tornando transparente os prazos previstos para cada uma das datas a seguir:
        1. End of support lifecycle (EOSL) -> data em que a funcionalidade deixará de ter suporte;
        2. End of service life (ESL) -> data em que a funcionalidade será removida de fato;
      3. Para descobrir aqueles clientes que realmente utilizam a feature, caso isso não seja metrificado por alguma ferramenta de product analytics, uma estratégia mais ousada é o "Bug proposital", ou seja, desligar a funcionalidade por uma tarde ou período alinhado com os stakeholders internos, e entender quais clientes manifestam insatisfação para o suporte técnico.
    4. É estratégico comunicar da remoção em casos de substituição de feature, tornar a nova versão o padrão e permitir ao cliente retornar para a versão antiga por um período prédeterminado. Também é válido criar materiais educativos que expliquem as diferenças entre versões;

Além disso, outra dica importante é não eliminar totalmente o código fonte da funcionalidade por um período de 3 meses, se resguardando caso haja alguma alteração nos planos.

6. Documentação dos aprendizados

Para garantir que os aprendizados sejam fixados é importante documentar os aprendizados com o processo de encerramento de uma feature, tanto para garantir que o histórico das decisões daquele produto esteja documentado quanto para compartilhar conhecimento com demais PMs que possam passar por situações semelhantes.

Nesse caso, vale registrar ao menos o seguinte na documentação:

  1. Qual feature foi eliminada
  2. Quais as premissas e alinhamentos que levaram à eliminação
  3. Como e quando foi eliminada
  4. Quais foram os resultados alcançados (redução de tickets de suporte, redução de custo de infraestrutura, aumento do NPS de clientes, etc)
  5. Quais os aprendizados ao longo do processo
    1. O que poderia ter sido melhor
    2. Quantas comunicações foram necessárias aos clientes
    3. Qual tipo de comunicação teve mais engajamento, etc.

Os 6 passos acima resumem a sequência quando é validado que o encerramento da feature é o melhor cenário para o negócio. Porém, podem haver situações em que a escolha seja por corrigir ou melhorar a feature atual por entender que ela é estratégica, que resolve uma dor clara dos usuários e que tem potencial para ser mais e melhor utilizada. Nesses casos, o ideal é identificar o que será corrigido na feature, como as novidades serão comunicadas aos clientes e quais são os resultados esperados com a aplicação dessa melhoria. Por exemplo: aumento de X% no engajamento com a feature em Y dias; receita futura esperada com a atualização da feature, redução do percentual de bugs por usuário em Z%.

Bônus

Daniel Roselli destaca também os dois principais erros que podem acontecer em processos de encerramento de features e uma falha que as pessoas de produto estão sujeitas a cometer:

  1. Erro limbo: postergar frequentemente a eliminação da feature por causa de algo que pode vir para substituir tal frente no produto, ou então por despriorização;
  2. Reversão por “chororô”: críticas fazem parte, reclamações também. Como não é possível agradar a 100% dos clientes pode ser que assim que a eliminação for feita haja uma repercurssão negativa. Nesses casos é necessário acompanhar as proporções que as reclamações podem atingir e sempre se ater ao fato de que, se a decisão foi baseada em argumentos sólidos, alinhados e bem documentados, é importante seguir em frente prezando pela melhor versão do produto;
  3. Por fim, enquanto PMs, é um erro não reconhecer o esforço do time para a remoção da funcionalidade. Por vezes pode ser que a equipe tenha passado muito tempo executando a eliminação da feature, por isso é importante tratar a remoção tal como uma adição de nova funcionalidade ao produto, fazendo os devidos reconhecimentos e apresentando a novidade em Reviews de produto, dando destaque e visibilidade aos resultados atingidos pela squad.

Referências para saber mais

  • Danilo Roselli - Perfil do Linkedin e curso na Crehana
  • Intercom - Vídeo sobre por que encerrar features
  • Kathy Sierra - Artigo sobre The Featuritis Curve
  • Mixpanel - Artigo sobre as razões para se encerrar uma feature
  • Productplan - Artigo sobre Feature Creep
  • Slack - Artigo sobre como comunicar o encerramento de uma feature
  • Google - Site que reúne todas as features que foram encerradas pelo google

E então, gostou do conteúdo? Quer fazer parte do incrível time de Produto da Gupy? Veja as vagas abertas na nossa página de carreiras!