## O que é Feature Creep?**Feature creep** é o acúmulo contínuo e não planejado de funcionalidades em um [produto](https://clubmartech.com.br/significado/produto-minimo-viavel-[mvp](https://clubmartech.com.br/significado/mvp/)/), além do escopo definido. Costuma nascer de boas intenções — pedido de cliente grande, resposta a concorrente, ideia da diretoria — e cobra o preço depois, em complexidade de uso e custo de manutenção. O efeito tem base acadêmica sólida. No estudo *Feature Fatigue*, publicado no **Journal of [Marketing](https://comecandonaweb.com.br/marketing-digital/) Research** em 2005 por Thompson, Hamilton e Rust, três [experimentos](https://clubmartech.com.br/blog/experimentos-[tecnologia](https://clubmartech.com.br/blog/tecnologia-[dados](https://clubmartech.com.br/blog/dados-transformar-volume-acionavel/)-transforme-receita/)-arquitetura-continua/) mostraram que mais funcionalidades **aumentam a capacidade percebida do [produto](https://clubmartech.com.br/significado/produto-minimo-viavel-[mvp](https://clubmartech.com.br/significado/mvp/)/), mas reduzem a [usabilidade](https://clubmartech.com.br/blog/usabilidade-[martech](https://clubmartech.com.br/significado/martech/)-plataformas-[roi](https://clubmartech.com.br/blog/roi-redes-sociais-acao/)/) percebida**. O detalhe que explica o ciclo: **antes de comprar, as pessoas pesam capacidade; depois de usar, pesam usabilidade**. Escolhem produtos mais complexos do que aqueles que de fato as satisfariam — e o mercado lê essa escolha como demanda por mais features, realimentando o ciclo. O efeito foi replicado em três [experimentos](https://clubmartech.com.br/blog/experimentos-tecnologia-arquitetura-continua/) independentes dentro do mesmo estudo.## ⚠️ O “80% das features nunca são usadas” está errado em quase todos os detalhesÉ o dado mais citado sobre o tema, quase sempre atribuído ao **Standish Group** e ao CHAOS Report. A atribuição é falsa e funde duas fontes distintas.
- **O número do Standish é 64%, não 80%** — 45% nunca usadas mais 19% raramente. E não saiu do CHAOS Report: veio de uma **palestra de Jim Johnson na conferência XP de 2002**, na Sardenha, registrada por Martin Fowler.
- **A amostra eram quatro aplicações internas**, de quatro empresas. Nenhum produto comercial. Nunca virou estudo formal revisado por pares.
- **O “80%” é da Pendo, de 2019** — **615 assinaturas** da própria base de clientes, ao longo de três meses. A empresa vende analytics de adoção de produto.
Há ainda um detalhe metodológico que raramente acompanha a citação: no levantamento da Pendo, “feature” é uma **etiqueta configurada manualmente pelo próprio cliente** na ferramenta. O denominador não é padronizado — varia conforme o que cada empresa decidiu marcar.O desdobramento de **“US$ 29,5 bilhões desperdiçados”** também não é medição: é extrapolação dos percentuais da Pendo sobre uma estimativa de receita de nuvem do Gartner. O cálculo pressupõe que a estatística é verdadeira; não a comprova.## O que o estudo real diz — e onde ele se limitaVale usar o *Feature Fatigue* no lugar do número zumbi, inclusive porque os autores são explícitos sobre os limites do próprio trabalho.Os experimentos usaram **130 e 190 estudantes universitários** — público mais à vontade com tecnologia que a média, o que torna o teste **conservador**: o efeito tende a ser mais forte em usuários menos familiarizados. E o produto classificado como “muitas features” tinha **21 funcionalidades**, número modesto perto de categorias reais; os autores citam painéis automotivos com 700 a 800.A recomendação prática que fecha o artigo é direta: **vários produtos especializados com poucas funcionalidades tendem a servir melhor que um produto único com todas elas**.## O que isso muda na práticaTrês consequências. Primeira: **pesquisa de intenção de compra superestima o valor de features** — perguntar antes do uso mede capacidade percebida, não satisfação futura. Segunda: remover funcionalidade pouco usada é decisão de produto legítima, não admissão de erro. Terceira: se o argumento para incluir algo é “um cliente pediu”, vale medir quantos usam depois — o custo do feature creep não aparece no lançamento, aparece na manutenção e na curva de aprendizado de todo novo usuário.## Fontes
- Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing — Thompson, Hamilton e Rust (Journal of Marketing Research, 2005)
- Registro da conferência XP 2002 — Martin Fowler
- Are 64% of Features Really Rarely or Never Used? — Mike Cohn
- 2019 Feature Adoption Report — Pendo (fornecedor de product analytics)
## Exemplos Práticos de Uso
- **Software**: Um aplicativo de gerenciamento de tarefas inicialmente planejado para oferecer listas simples se torna sobrecarregado com funcionalidades extras, como chat interno, calendários complexos e integrações desnecessárias, confundindo os usuários.
- **Automóveis**: Carros que deveriam ser básicos ganham tantos recursos eletrônicos que se tornam menos acessíveis e mais difíceis de operar para o público-alvo.
- **Eletrônicos de Consumo**: Um fabricante de smartphones adiciona recursos desnecessários, como medições específicas para atletas profissionais, em um aparelho voltado ao público geral.
- **Websites**: Um site institucional recebe tantos elementos interativos e seções adicionais que sua navegabilidade e propósito original se perdem.
## Sinônimos e Antônimos Relevantes### Sinônimos:
- Sobrecarga de funcionalidades
- Escopo expandido
- Complexidade não planejada
- Overengineering
### Antônimos:
- Minimalismo funcional
- Escopo controlado
- Design enxuto
## Contexto ou Área de AplicaçãoO conceito de feature creep se aplica a diversas áreas, como:
- **Desenvolvimento de Software**: Expansão de funcionalidades além do escopo inicial.
- **Design de Produto**: Inserção de características que complicam o uso do item.
- **Gestão de Projetos**: Falha em controlar o escopo planejado, resultando em desperdício de recursos.
- **Marketing**: Produtos com funcionalidades irrelevantes que confundem o público.
## Referências e Termos Relacionados
- **Escopo do Projeto**: Definição inicial das entregas e objetivos.
- **Gold Plating**: Adição de funcionalidades desnecessárias por iniciativa da equipe.
- **Gestão Ágil**: Metodologia que ajuda a controlar e priorizar funcionalidades.
- **MVP (Produto Mínimo Viável)**: Estratégia de lançamento com funcionalidades essenciais.
- **UX (Experiência do Usuário)**: Muitas funcionalidades podem prejudicar a usabilidade.
## Notas AdicionaisFeature creep muitas vezes resulta de intenções positivas, como atender melhor os usuários ou superar a concorrência. No entanto, a falta de um controle rigoroso sobre o escopo pode prejudicar o projeto, aumentando custos, complexidade e tempo de entrega.Uma abordagem eficaz para evitar o problema é priorizar funcionalidades com base em metodologias como **MoSCoW (Must have, Should have, Could have, Won’t have)** ou realizar validações contínuas com o público-alvo.
## Ilustração ConceitualImagine que um time de desenvolvimento está criando um aplicativo de pedômetro simples. Durante o processo, adicionam mapas, rastreamento de calorias, planos de dieta, e redes sociais embutidas. O que deveria ser uma ferramenta leve se torna um software pesado, confuso e com pouca aderência pelos usuários.
## Classificação GramaticalSubstantivo masculino (em inglês, usado de forma invariável em outros idiomas).
## Informações sobre Pronúncia/ˈfiː.tʃər kriːp/
## Detalhes Etimológicos
- **Feature**: Do inglês, significa “característica” ou “funcionalidade”.
- **Creep**: Termo inglês que significa “deslizar” ou “avançar gradualmente”, indicando um crescimento sutil e contínuo