O cemitério de recursos: o que acontece com os recursos que ninguém usa?

Todo produto tem.

Recursos que levaram dias para serem construídos.

Recursos que pareciam empolgantes nas reuniões de planejamento.

Recursos que todo mundo tinha certeza de que os usuários iam amar.

E então…

Ninguém usou.

Eles ficam ali quietinhos dentro do produto, ocupando espaço, aumentando a complexidade e, aos poucos, virando algo em que o time nem pensa mais.

Bem-vindo ao cemitério de recursos.

Todo recurso começa com um motivo

A maioria dos recursos que ninguém usa não nasceu de uma ideia ruim.

É justamente isso que torna esse problema interessante.

Um time normalmente não constrói algo sem motivo.

Talvez os usuários tenham pedido.

Talvez um concorrente tenha lançado.

Talvez as métricas tenham mostrado uma oportunidade.

Talvez o fundador tenha achado que isso deixaria o produto melhor.

Ou talvez o time simplesmente acreditasse:

“Os usuários vão amar isso.”

Então eles constroem.

Testam.

Lançam.

E aí os números chegam.

Quase ninguém clica.

Construir é mais fácil do que remover

Depois que um recurso existe, removê-lo pode parecer admitir um fracasso.

As conversas costumam soar mais ou menos assim:

• “Mas a gente passou três semanas construindo isso.”
• “E se os usuários precisarem disso depois?”
• “Talvez as pessoas só não tenham descoberto ainda.”
• “Vamos deixar por enquanto.”

E o recurso fica.

Depois entra mais um recurso.

E mais um.

E mais um.

Uma hora o produto fica complicado — não porque alguém planejou complicá-lo, mas porque nada nunca é removido.

O custo escondido de um recurso que ninguém usa

Um recurso sem uso não precisa gerar uma conta toda vez que alguém o ignora.

Mesmo assim, ele pode custar caro para o time.

Ele pode:

• Deixar a interface mais difícil de navegar.
• Aumentar o trabalho de manutenção.
• Exigir mais testes.
• Gerar mais documentação.
• Aumentar as dúvidas no suporte.
• Deixar o onboarding mais confuso.
• Tirar a atenção de recursos mais importantes.

O recurso pode ter quase zero usuários e, ainda assim, gerar trabalho.

Essa é uma das coisas estranhas do software.

Código que ninguém usa também pode ter custo.

Mais recursos nem sempre significam mais valor

É fácil medir o progresso pelo número de recursos lançados.

Cinco recursos este mês.

Dez no mês que vem.

Vinte até o fim do ano.

Parece produtivo.

Mas os usuários não escolhem um produto porque ele tem a maior lista de recursos.

Eles escolhem porque o produto os ajuda a fazer algo melhor, mais rápido ou com mais facilidade.

Às vezes, um recurso a mais melhora essa experiência.

Às vezes, só dá ao usuário mais uma coisa para entender.

Mais não é automaticamente melhor.

Às vezes, é só mais.

Mas e se os usuários não conseguem encontrar o recurso?

É aqui que a coisa fica interessante.

Um recurso pouco usado não é necessariamente um recurso inútil.

Talvez os usuários simplesmente não saibam que ele existe.

Essa é uma diferença importante.

Antes de remover algo, pergunte:

“Os usuários estão ignorando esse recurso ou não conseguem encontrá-lo?”

Um recurso útil enterrado num menu confuso pode parecer totalmente inútil nas suas métricas.

Um onboarding melhor pode ajudar.

Uma navegação mais clara pode ajudar.

Um nome melhor pode ajudar.

Um pequeno aviso dentro do produto pode ajudar.

Então, antes de mandar um recurso para o cemitério, tenha certeza de que ele realmente merece ir para lá.

Converse com quem realmente usa

As métricas mostram o que está acontecendo.

Os usuários muitas vezes conseguem explicar por quê.

Se só 2% dos usuários usam um recurso, converse com algumas dessas pessoas.

Pergunte:

• “Por que você usa isso?”
• “Que problema isso resolve para você?”
• “O que você faria se esse recurso sumisse amanhã?”

Você pode descobrir que o recurso não é popular, mas é extremamente valioso para um grupo pequeno de usuários.

E essa é uma distinção importante.

Um recurso não precisa ser popular para ser valioso.

A pergunta que todo recurso enfrenta um dia

Em algum momento, todo time de produto deveria se perguntar:

“Se a gente não tivesse esse recurso hoje, construiria de novo?”

Se a resposta for não, vale investigar.

Talvez o recurso precise de um redesign.

Talvez ele deva ficar escondido para a maioria dos usuários.

Talvez deva ser combinado com outra coisa.

Ou talvez… ele deva ser removido.

O tempo que já foi gasto construindo algo não deveria decidir se ele merece ficar.

Isso é só a armadilha do custo afundado.

Remover um recurso também é desenvolver produto

Apagar algo pode parecer andar para trás.

Não é.

Tirar complexidade desnecessária também pode ser progresso.

Quando um recurso some, o produto pode ficar:

• Mais fácil de entender.
• Mais fácil de manter.
• Mais fácil de começar a usar.
• Mais fácil de explicar.
• Mais fácil de navegar.

Às vezes, a melhor atualização de produto não é:

“Adicionamos algo novo.”

É:

“Deixamos o produto mais simples.”

E os usuários podem valorizar isso mais do que mais um botão na interface.

Mas não transforme isso numa faxina

Aqui existe outra armadilha.

Um time pode ficar obcecado em remover tudo o que não tem números de uso enormes.

Isso nem sempre é inteligente.

Alguns recursos são raramente usados, mas se tornam extremamente importantes quando alguém precisa deles.

Pense num botão de exportar.

A maioria dos usuários talvez nunca encoste nele.

Mas os que usam podem depender dele.

Então o uso, sozinho, não deveria decidir o destino de um recurso.

Olhe o quadro completo:

Uso + valor + feedback dos usuários + custo de manutenção.

Esse é um jeito bem melhor de avaliar se algo merece ficar.

Construa a partir de uma pergunta, não só de um recurso

Antes de construir algo, pergunte:

Que problema estamos resolvendo?

Depois:

Quem realmente tem esse problema?

E, por fim:

Como vamos saber que resolvemos?

Essas perguntas parecem simples.

Mas podem economizar semanas de desenvolvimento.

Em vez de comemorar quantos recursos o time lançou, comemore quantos problemas reais foram resolvidos.

Essa é uma medida de progresso muito melhor.

O cemitério nem sempre é ruim

Todo produto, mais cedo ou mais tarde, vai ter recursos que não deram certo.

Isso é normal.

Algumas ideias vão falhar.

Alguns experimentos não vão pegar.

Alguns recursos vão ficar obsoletos.

Isso faz parte de construir software.

O objetivo não é evitar o cemitério de recursos por completo.

O objetivo é aprender com o que vai parar lá.

Se cinco recursos falham pelo mesmo motivo, isso é uma informação útil.

Se os usuários ignoram sempre um certo tipo de funcionalidade, isso é um sinal.

Se remover algo de fato melhora o engajamento, isso é uma lição.

O fracasso ganha valor quando você presta atenção nele.

Considerações finais

Bons produtos não são construídos acrescentando coisas sem parar.

São construídos entendendo o que merece ficar.

Todo recurso deveria conquistar o seu lugar — não porque o time passou semanas construindo, mas porque ele realmente ajuda alguém.

Às vezes, isso significa construir algo novo.

Às vezes, significa melhorar algo que já existe.

E às vezes…

significa abrir o cemitério de recursos e finalmente deixar algo ir.

Porque, em software, menos nem sempre é mais.

Mas o desnecessário nunca sai de graça.