Gestão de portfólio: quando (e como) matar uma feature
Manter tudo vivo tem um custo real, só que diluído no tempo. O framework dos quatro quadrantes (uso x alinhamento estratégico) e como desligar uma feature sem incendiar a base de clientes.
Nenhum PM entra na carreira sonhando em matar features. E, ainda assim, essa é uma das decisões que mais separa gestão de portfólio madura de acúmulo cego de código. Todo produto que existe há alguns anos carrega funcionalidades que custam manutenção e não geram valor proporcional, e a resistência em desligá-las é quase sempre emocional, não estratégica.
O custo invisível de manter tudo vivo
Cada feature ativa não é gratuita só porque já foi paga uma vez. Ela custa em débito técnico acumulado, em complexidade de teste (mais caminhos para validar a cada release), em confusão de interface (mais opções competindo pela atenção do usuário, o mesmo problema que a jornada do usuário revela), e em atenção do time de suporte respondendo dúvidas sobre algo que quase ninguém usa.
Um dado que costuma surpreender quando medido pela primeira vez: em muitos produtos maduros, entre 60% e 80% das funcionalidades são usadas por uma fração pequena da base ativa. Manter tudo "por via das dúvidas" tem um preço real, só que diluído ao longo do tempo, o que o torna fácil de ignorar até se acumular.
O framework de decisão: os quatro quadrantes
Cruze duas perguntas para cada funcionalidade candidata a revisão:
- Uso: quantos usuários ativos a tocam com frequência real?
- Estratégia: ela reforça a direção atual do produto, ou é resquício de uma direção antiga?
Alto uso + alinhada à estratégia: investir. É onde o roadmap deveria focar energia.
Alto uso + desalinhada: o quadrante mais delicado. Usuários dependem dela, mas ela puxa o produto para uma direção que a estratégia atual não quer mais. Aqui cabe migração assistida, não corte abrupto: comunicar a mudança com antecedência e oferecer caminho de transição.
Baixo uso + alinhada: manter e observar. Pode ser cedo demais, não necessariamente errada.
Baixo uso + desalinhada: candidata clara a desligamento. É aqui que a maioria das "features fantasma" mora, drenando manutenção sem retorno proporcional.
Como desligar sem incendiar a base de clientes
O erro mais comum não é a decisão de matar a feature, é a execução do desligamento:
- Comunique com antecedência real, não um aviso de duas semanas. Clientes que dependem de algo, mesmo que poucos, merecem tempo para se ajustar ou migrar.
- Ofereça alternativa, quando existir. "Estamos removendo X" soa diferente de "estamos removendo X porque Y resolve melhor o mesmo problema, e aqui está como migrar".
- Meça o impacto antes de anunciar, não depois. Uma consulta rápida aos usuários que mais usam a funcionalidade evita surpresas desagradáveis e às vezes revela um caso de uso que a análise de dados sozinha não capturou.
- Trate como mudança de contrato, não como faxina interna. O mesmo rigor de comunicar breaking changes de uma API pública vale para features de produto: quem depende de algo merece aviso proporcional ao impacto.
O viés que impede a decisão de acontecer
O maior obstáculo raramente é técnico, é psicológico: custo afundado. "Investimos seis meses construindo isso, não podemos simplesmente jogar fora." Esse raciocínio ignora que o custo de construção já foi gasto e é irrecuperável de qualquer forma; a única pergunta que importa é se manter a feature daqui para frente vale o custo contínuo, o mesmo raciocínio que se aplica à decisão entre reescrever e evoluir um sistema.
A revisão de portfólio como rotina, não como evento raro
Times maduros fazem essa análise trimestralmente, junto com o ciclo de OKR, não como um projeto especial de "limpeza" que acontece uma vez a cada dois anos quando o produto já está pesado demais.
Estruturar essa disciplina de portfólio (métricas de uso, critério de decisão e o processo de comunicação) é parte do que ajudamos a implantar no nosso serviço de Discovery e Product Owner.
Seu produto tem alguma funcionalidade que ninguém lembra por que ainda existe? Descreva-a para a IA da Rabelo Digital, aqui no canto da tela, e ela ajuda a aplicar o framework dos quatro quadrantes. Sem formulário, sem espera.
Deixe um Comentário