- A maioria dos usuários usa apenas cerca de 20% dos recursos de um aplicativo que realmente precisa, e esses 20% são diferentes para cada pessoa
- Os 80% restantes dos recursos podem até ser vistos como elementos de distração, gerando desconforto ou insatisfação
- Se você mirar com precisão em um mercado de nicho, pode construir uma base de usuários forte
- Casos como Kagi, Figma e Notion, que resolveram bem os 20% ignorados pelas grandes empresas e criaram mercados altamente fiéis, mostram uma nova oportunidade de mercado
- VS Code, Slack e Discord apoiam extensibilidade e personalização para que os próprios usuários otimizem seus 20%
- O ponto central não é criar um produto para todo mundo, mas sim uma ferramenta que satisfaça profundamente a parte que cada pessoa deseja, e esse é o caminho para evitar o problema do inchaço de funcionalidades
Experiências da infância e a forma de usar software
- Quando era criança, o autor frequentemente quebrava o computador ao apagar arquivos inúteis para gerenciar 2 GB de armazenamento
- Depois de apagar arquivos importantes do sistema como
.ini, precisava reinstalar o Windows e o Office 97 do zero
- O pai insistia para que ele garantisse a instalação do Excel, mas para o autor o Excel não passava de uma ferramenta para colar tabelas no Word
- Entre os inúmeros recursos do Excel, apenas copiar e colar tabelas tinha significado para ele
- Uma pessoa próxima também só usava o Excel como controle de gastos domésticos, sem tocar nas outras funções
Os 20% diferentes de cada um
- Existe uma 'regra 80/20' no uso de software: a maioria dos usuários usa apenas 20% do conjunto total de recursos
- Mas os 20% em que cada usuário se concentra são diferentes, e cada um considera a parte que usa a mais importante
- Ex.: usa tabelas no Word, mas não mala direta; usa tabelas dinâmicas no Excel, mas não scripts; não usa animações no PowerPoint
- Atualizações que adicionam novos recursos ou mudam a UI fazem surgir reclamações de que o aplicativo ficou mais lento ou ganhou funções desnecessárias
- Os 80% dos recursos que não são usados podem até ser vistos como elementos que atrapalham o fluxo de trabalho dos 20% realmente importantes
O desejo por um resultado perfeito
- Esse fenômeno não aparece só na Microsoft, mas igualmente em outras empresas de TI
- Por exemplo, quando alguém quer uma busca exata por palavras-chave no Google Search, resultados relacionados e desnecessários podem acabar gerando insatisfação
- Do ponto de vista da empresa, isso pode ser tratado como uma "demanda de 1% dos usuários", mas 1% de 1 bilhão de pessoas são 10 milhões — um mercado enorme
- A Kagi atacou o mercado com diferenciação em busca focada em qualidade, sem anúncios e com proteção de privacidade, especializada em um pequeno mercado ignorado pelo Google
- Ao explorar brechas deixadas por empresas gigantes, torna-se possível formar um mercado de nicho que satisfaz pequenos grupos de usuários
- Não é necessário satisfazer todo mundo; é possível adotar uma estratégia de satisfazer perfeitamente a experiência dos 20% de um grupo específico
Encontrando os 20% esquecidos
- Muitas empresas inovadoras focam intensamente em grupos específicos de usuários que as grandes empresas deixam passar
- A Figma se concentrou em superar a Adobe na parte de design colaborativo, e a Notion se estabeleceu como uma ferramenta híbrida otimizada para necessidades específicas de certos usuários
- Softwares bem-sucedidos ganham mais recursos com o tempo, mas nesse processo surgem nichos em que os 20% de certos usuários acabam ficando soterrados
- Softwares de código aberto têm força nessa área porque permitem criar builds customizadas especializadas em fluxos de trabalho específicos
- Por exemplo, é possível desenvolver uma versão leve do Blender voltada apenas para visualização arquitetônica
Projetando para os 20% certos
- Essa filosofia é bem implementada no VS Code
- Os recursos básicos se concentram em edição de texto simples, mas por meio de extensões é possível montar o ambiente de desenvolvimento que cada pessoa quiser
- É uma estrutura em que todos os usuários podem customizar seus próprios 20%
- As integrações do Slack e os bots do Discord seguem o mesmo princípio, permitindo que os usuários personalizem diretamente sua experiência
- É difícil prever desde o início quais serão os 20% de todos os usuários, mas, ao oferecer extensibilidade e customização, cada pessoa pode chegar ao seu uso ideal
Conclusão: em vez de um produto para todos, foco nos '20% necessários' de cada um
- Tentar fazer tudo bem acaba levando a um software mais pesado e que gera mais insatisfação
- O importante é focar em fazer com que cada funcionalidade funcione perfeitamente para o usuário específico que a procura
- Como os usuários inevitavelmente usarão apenas parte do total de recursos, é mais eficaz se concentrar em tornar certas funcionalidades realmente excelentes
- É preciso reconhecer que o software pode ser usado de formas que não foram previstas e planejar aceitando essa diversidade
- Em vez de empurrar tudo para o usuário, desenvolver com foco apenas nas partes verdadeiramente amadas leva a uma satisfação maior
2 comentários
Sempre colam isso na lei de Pareto sem pensar;; não poderia ser 15% também? kkk
Comentários do Hacker News
Em uma empresa SaaS onde trabalhei, uma vez tentamos fazer uma análise com base apenas no subconjunto de funcionalidades que os usuários realmente usavam. Queríamos reduzir a complexidade do produto para alguns tipos centrais de usuário e também remover recursos incômodos. No fim, tirando a tela de login, os 20% que cada um considerava importantes eram totalmente diferentes. O resultado da análise não foi muito diferente de uma amostragem aleatória ponderada
Concordo muito. Mas, quando você começa a vender o produto para clientes enterprise, a situação muda completamente. A falta de uma única “funcionalidade higiênica” pode fazer um negócio fracassar. E o conjunto de funcionalidades indispensáveis varia de uma empresa para outra. “Funcionalidade higiênica” é uma metáfora para o mínimo essencial que todo mundo precisa, como um banheiro
É um texto parecido que me faz lembrar dos posts do blog do Spolsky
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
Eu mesmo fiz alguns apps de hobby e às vezes penso em polir e publicar. Mas sinto que publicar em si não faz sentido nenhum porque não tenho a menor vontade de divulgar ou promover meus apps. Na verdade, a razão maior é que não tenho nenhuma vontade de implementar os outros 80% de funcionalidades que eu mesmo não uso
No marketing existe o conceito de Pareto Modificado. Não é 80/20, e sim 60/20. Os 20% de heavy users consomem 60% do valor do produto, e os 80% de light users consomem 40%. Não é uma fatia pequena o bastante para ser ignorada, então também é preciso dar atenção aos usuários ocasionais
value-paretos-bottom-80
É mais ou menos assim. Na prática, é muito mais importante que o usuário “perceba” que o software pode resolver o problema dele. Se você quer fazer alguém gastar dinheiro, o software precisa passar a sensação de que potencialmente também pode resolver vários outros problemas do usuário. Esses outros problemas podem estar ligados a funcionalidades que ele nem usa diretamente. Por exemplo, num software 3D, um sistema de rigging pode ser usado por 2% dos usuários durante apenas 1% do tempo, mas sem isso pode haver gente que nem consideraria avaliar o produto
Como eu não tenho talento para prever como meu trabalho vai ser usado na prática, prefiro apenas pavimentar os caminhos já revelados, algo muitas vezes descrito pela metáfora de “Desire paths”
the-road-most-traveled-by-paving
Concordo com a ideia de que “em vez de tentar impedir que funcionalidades cresçam, precisamos aceitar que o software pode ser usado de maneiras inimagináveis”. Por isso, acho que interoperabilidade é o elemento mais importante do software. Minha impressão é que o principal problema do texto é a natureza fechada dos formatos de arquivo de cada software e de cada versão. Não me importo de combinar várias ferramentas, mas o problema é que elas não conseguem colaborar bem em um pipeline. O sonho Unix é realmente difícil
Em apps de certo porte, quase nunca todas as funcionalidades têm 100% de uso. Pela minha experiência, quase toda aplicação tem algo entre 10% e 30% que fica totalmente subutilizado. Isso acontece principalmente porque ou a funcionalidade está escondida de um jeito que só a equipe de desenvolvimento entende, ou o workflow é péssimo e ineficiente, ou então a funcionalidade é tão básica que as empresas que realmente precisam dela nem têm capacidade financeira para comprar aquele software
Sim, mas muitos usuários valorizam 20% diferentes das funcionalidades, então é preciso manter tudo para preservar a base atual de usuários. Ainda assim, eliminar recursos quase nunca usados que consomem muito tempo de manutenção ou desenvolvimento melhora o ROI
Mas os usuários não necessariamente valorizam os mesmos 20%. Outra questão é que, antes de usar de fato um app, o usuário mal sabe que funcionalidades ele tem. A decisão de instalar é baseada não nas funcionalidades reais do app, mas nas funcionalidades que a pessoa espera que ele tenha antes de instalar. Essa é uma diferença importante. Você pode investir em funcionalidades, mas na prática só vai colher o resultado depois de conquistar o usuário.
Isso é especialmente importante na hora de fazer um MVP. Na maioria dos casos, o que impede a instalação e o uso contínuo não é a falta de funcionalidades. Normalmente é comunicação, marketing, ou simplesmente a ausência de valor que atraia o usuário. Sair adicionando funcionalidades não resolve esses problemas. Parece simples, mas muita empresa deixa isso passar.
O MVP mais simples de todos é nem implementar nada e primeiro tentar fazer as pessoas se cadastrarem antecipadamente. Assim você consegue validar se a mensagem está sendo comunicada direito. Se a pessoa se cadastrar e depois se decepcionar, pelo menos a mensagem funcionou.
Só que, fazendo isso, você acaba lançando um MVP que ainda não entrega o que prometeu, e existe o risco de gerar frustração com uma promessa inacabada. Além disso, muitas funcionalidades na verdade podem nem ser necessárias, especialmente em SaaS, onde há muitos recursos que não são importantes o bastante para justificar pagamento real. Em vez de tratar as exigências do cliente imediatamente como requisitos obrigatórios, é essencial entender com clareza se ele realmente considera aquilo “valioso”, se de fato pagaria por isso e se aquilo resolve uma dor realmente importante. Entender por que o cliente fez o pedido é muito mais importante do que sair construindo a funcionalidade na hora