Mata uma funcionalidade por trimestre:menos é mais

Mata uma funcionalidade por trimestre: todos os trimestres, descontinua uma funcionalidade — a menos usada do teu produto. A maioria dos produtos carrega uma cauda longa de funcionalidades em que menos de dez por cento dos utilizadores tocam num mês típico, e cada uma delas cobra um imposto sobre todas as alterações futuras que fizeres. Matar uma por trimestre é a disciplina que mantém um produto construído a solo enxuto o suficiente para evoluir durante anos.

Eis porque é que o excesso custa mais do que pensas, como funciona o ritual trimestral, porque é que custa tanto emocionalmente e como distinguir uma funcionalidade morta de um negócio morto.

O custo escondido das funcionalidades que ninguém usa

Olha para a utilização das funcionalidades no teu painel. Para cada funcionalidade do teu produto, que percentagem de utilizadores a usa de facto num mês típico? Faz essa análise uma vez e vais encontrar a cauda longa: funcionalidades em que menos de dez por cento dos utilizadores tocam.

Essas funcionalidades parecem gratuitas. Estão construídas; estão lançadas; estão ali. Mas custam-te continuamente, porque sempre que mudas outra coisa no produto tens de garantir que não estragaste as funcionalidades da cauda longa — e essa manutenção acumula-se ao longo da vida do código. Cada funcionalidade morta é um imposto permanente sobre cada funcionalidade viva.

Para um fundador a solo, o imposto é pior do que para uma equipa, porque tu és o departamento de manutenção inteiro. Uma hora gasta a manter viva uma funcionalidade com cinco por cento de utilização é uma hora que não gastas na experiência que faz crescer a receita.

Mata uma funcionalidade por trimestre: o ritual de matar uma funcionalidade

A disciplina é simples o suficiente para caber num parágrafo. Todos os trimestres: escolhe a funcionalidade menos usada. Comunica a descontinuação ao pequeno número de utilizadores que dependiam dela. Remove-a.

Os resultados são imediatos e cumulativos. O código fica mais simples. O produto fica mais afiado. A carga de manutenção desce. E a próxima funcionalidade que construíres cai num sistema mais pequeno e mais limpo — o que significa que sai mais depressa e parte menos coisas.

Põe-no no calendário como a revisão de métricas de segunda-feira: quatro eliminações por ano, agendadas, inegociáveis. Se esperares até uma funcionalidade estar "obviamente" morta, vais esperar para sempre, porque nenhuma funcionalidade anuncia o seu próprio funeral.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

Porque é que matar funcionalidades é psicologicamente difícil

Isto não é um problema técnico. É emocional. Investiste tempo naquela funcionalidade. Lembras-te da semana em que a construíste e do cliente que a pediu. E há sempre algum utilizador, algures, que se queixa sempre que removes alguma coisa.

Eis a assimetria que prende os fundadores: as queixas por remover algo parecem mais agudas do que as queixas causadas pelo excesso, embora o excesso esteja a fazer mais dano cumulativo. Remover produz um email zangado hoje; o excesso produz um produto mais lento, lançamentos mais lentos e um código que ninguém quer refatorar — espalhados de forma invisível pelos próximos três anos.

Mata na mesma. Os fundadores que conseguem matar as próprias funcionalidades são os que mantêm os produtos enxutos o suficiente para evoluírem. Os que não conseguem são aqueles cujos produtos se tornam museus de decisões históricas. Um museu é ótimo para visitar. É péssimo para manter sozinho.

Mudar de rumo ou ter paciência: quando não é uma funcionalidade, é o negócio

Às vezes, os dados de utilização levantam uma questão maior do que "que funcionalidade morre este trimestre". Às vezes sugerem que o negócio, tal como está constituído, não está a funcionar. Matar uma funcionalidade e matar a direção são decisões diferentes, e os dados dizem-te qual delas tens pela frente:

A disciplina é olhar com honestidade. A tentação é continuar a empurrar o que já existe porque investiste tempo nisso e mudar de direção parece um fracasso. Os dados não querem saber do custo afundado. E mudar de rumo não é fracassar — é aplicar tudo o que aprendeste a uma versão mais afiada da aposta. A maioria dos negócios de sucesso mudou de rumo pelo menos uma vez no início, porque a primeira ideia raramente é a certa, mesmo quando foi validada. A validação diz-te que o problema é real; construir diz-te se a tua solução está certa. A mesma honestidade aplica-se antes de construíres o que quer que seja — é o tema de quando matar uma ideia de negócio.

A disciplina oposta importa tanto quanto esta: saber quando não mudar de rumo. Os fundadores que mudam de rumo de três em três meses nunca constroem nada. Uma estagnação com ativação avariada e muitos cancelamentos é sinal para mudar de rumo; uma estagnação com fundamentos saudáveis é sinal para ter paciência. Se não tens a certeza de qual é o teu caso, faz o diagnóstico com experiências estruturadas — correções repetidas ao onboarding que nunca mexem na ativação são, elas próprias, os dados.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

Como decido que funcionalidade matar?

Pela utilização, não pelo sentimento. Mede que percentagem de utilizadores toca em cada funcionalidade num mês típico, ordena de forma ascendente e descontinua o fundo da lista. A maioria dos produtos tem uma cauda longa abaixo de dez por cento de utilização — essa cauda é a tua fila de eliminações para os próximos trimestres.

E se os clientes se queixarem quando removo uma funcionalidade?

Alguns vão queixar-se — há sempre alguém que se queixa quando removes alguma coisa. Comunica a descontinuação diretamente ao pequeno número que dependia dela, dá-lhes aviso prévio e avança. As queixas por remover parecem mais agudas do que as queixas pelo excesso, mas o excesso faz mais dano cumulativo; um email hoje é melhor do que um produto estagnado daqui a um ano.

Com que frequência devo remover funcionalidades do meu SaaS?

Uma por trimestre. Agendada, como a tua revisão de métricas de segunda-feira. Quatro eliminações por ano chegam para manter a carga de manutenção a descer enquanto o produto continua a evoluir — e são raras o suficiente para que os utilizadores fiéis nunca sintam o chão a fugir-lhes.

Como sei se devia antes mudar de rumo?

Um problema de funcionalidade é local: uma funcionalidade pouco usada dentro de métricas saudáveis. Um sinal para mudar de rumo é sistémico: ativação baixa persistente apesar de correções repetidas ao onboarding, cancelamentos que não respondem ao trabalho de retenção, feedback a apontar para um problema que o teu produto não resolve, ou um mercado mais pequeno do que pensavas. E lembra-te do contrapeso — os fundadores que mudam de rumo de três em três meses nunca constroem nada.