Feature creep: o fundador costuma ser a fonte

Um guia de campo para fundadores não-técnicos que vivem assistindo o produto ganhar features mais rápido do que ganha usuários: o que feature creep de fato é, por que o conselho clássico de “só dizer não” não funciona para você, e o diagnóstico de três fontes mais o teste de uma pergunta que para o problema antes do próximo sprint.

O CEO abriu o laptop e começou a contar. Vinte e três features lançadas nos últimos seis meses. Três delas foram usadas. As outras vinte foram pagas, desenhadas, construídas, testadas, colocadas em produção, e agora teriam que ser mantidas até a empresa morrer ou alguém arrumar tempo para deletar.

Ele olhou para cima. “Já gastei cento e cinquenta mil reais. Como isso aconteceu?”

Nós sabíamos exatamente como tinha acontecido. Tínhamos estado em cada uma daquelas calls. O investidor que sugeriu “vocês precisam de um agente de AI no dashboard”. O cliente flagship que perguntou, numa call de renovação, se o export não poderia também mandar para o Slack. A PM que voltou de um evento com um Notion intitulado “o que aprendemos”. O próprio fundador, numa noite de domingo, vendo o vídeo de lançamento de um concorrente e mandando um print no Slack do time com a legenda: “a gente precisa disso”.

Vinte e três sins. Três que importavam. Os outros vinte eram feature creep.

O que é feature creep

Feature creep é a expansão lenta, quase invisível, do escopo de um produto para além do que tinha sido planejado, alimentada por um acúmulo de decisões individualmente razoáveis. Cada feature adicionada, isoladamente, parece inofensiva. O peso somado delas é o que mata o produto, o orçamento, ou os dois.

O termo vem da literatura de engenharia e de game design dos anos 70 e 80, quando os times começaram a dar nome ao padrão que faz sistemas ambiciosos colapsarem sob o próprio peso. Frederick Brooks escreveu sobre um irmão desse padrão, o second-system effect, há cinquenta anos. O vocabulário é velho. A doença não mudou.

O que mudou foi quem carrega o vírus. Na visão antiga, feature creep era algo que um time de engenharia fazia consigo mesmo quando ninguém estava olhando. Na startup moderna, o time de engenharia tem muito pouco a ver com isso. O fundador é quem aprova as features. O time está só executando.

Se você é fundador não-técnico e o seu produto tem mais features do que os seus usuários têm casos de uso, você não é vítima de feature creep. Você é a fonte.

Feature creep vs scope creep: por que a diferença importa

Os dois termos são usados como sinônimos e não deveriam ser. A solução de um não é a solução do outro.

Scope creep é um problema contratual. Você assinou um SOW com um fornecedor por cinco features, e agora tem nove no build. Alguém disse sim para quatro coisas que não estavam no acordo original. Geralmente você. Às vezes o vendedor. Às vezes um PM que quis ser prestativo. O custo aparece na fatura. A solução é contratual: change order escrita, reorçamento, preço renegociado. A escolha de fixed price vs time and materials que você fez lá no começo define o quanto essa conversa vai doer.

Feature creep é um problema de produto. O produto, ao longo de meses e anos, acumula features pelas quais ninguém briga e que ninguém remove. Não existe um momento único em que a linha foi cruzada. O custo aparece em três lugares, todos invisíveis até deixarem de ser: contas de manutenção que compõem, uma UI que confunde quem entra novo, e um time que cada vez menos consegue entregar a única coisa que realmente importaria porque está ocupado mantendo as vinte que não importam.

Scope creep é uma briga que você pode perder numa única conversa. Feature creep é uma briga que você perde por não ter a conversa. A primeira tem um fornecedor do outro lado da mesa. A segunda tem só você.

As três fontes de feature creep

Depois que você aceita que é a fonte, o próximo passo é parar de pensar em feature creep como uma doença só. São três. Elas chegam idênticas do seu lugar. Todas se apresentam como “a gente também deveria construir X”. A resposta certa depende de qual das três você está olhando.

Fonte 1: pull de cliente (às vezes real)

Um cliente pede a feature. Está usando o produto, esbarrou num limite, quer o limite removido. Essa é a única fonte em que a resposta às vezes é um sim limpo.

A armadilha: um cliente não é um sinal. Vimos fundadores entregarem um build de seis semanas por causa de um pedido que veio de uma única call de renovação, em que o cliente teria renovado de qualquer jeito, e em que nenhum outro cliente nunca pediu a mesma coisa de novo. A feature acaba sendo usada por zero pessoas pelo resto da vida e custa ao time um dev-mês toda vez que o framework por baixo muda.

O teste não é “um cliente pediu”. O teste é “outros cinco clientes vão churnar ou vão se recusar a onboardar sem isso”. Se a resposta for sim, construa. Se a resposta for “olha, esse cliente quer muito”, você está negociando uma feature de contrato customizado, não uma feature de produto. Cobre diferente ou diga não.

Fonte 2: isca de venda (quase nunca real)

Um prospect numa call de venda diz “se vocês tivessem X, eu assinava amanhã”. Seu head de vendas leva o pedido de volta para o time de produto como bloqueador de deal. O fundador, que neste estágio também é normalmente o head de vendas, autoriza o build.

O prospect nunca assina. Nunca assina porque X não era de verdade o motivo de não ter assinado. X era a versão educada de “não estamos prontos”, ou “o seu preço está errado”, ou “já usamos um concorrente e trocar dá trabalho”. A feature é construída, o deal não fecha, e agora você é dono de X para sempre.

O teste cabe em uma frase: o prospect vai assinar um pedido pago hoje, condicionado à entrega de X em Y semanas, com cláusula escrita de cancelamento se a entrega atrasar. Se sim, você tem um sinal real, e tem um cliente pagante financiando o build. Se não, você tem uma objeção educada disfarçada de pedido de feature. Já rodamos esse teste em dezenas de features “deal-blocker”. A conversão de “ele disse que ia assinar” para “ele assinou quando recebeu o contrato” fica em um dígito baixo.

Fonte 3: inquietação do fundador (a assassina silenciosa)

O fundador está acordado tarde. Tem uma hora de silêncio. Abre o produto, olha, e sente aquela insatisfação de baixa intensidade que vem de ficar olhando demais para o próprio trabalho. O produto parece pequeno demais, simples demais, quieto demais. Ele abre o Slack do time e escreve: “a gente também deveria construir X”.

Essa é a fonte que mais entrega features. Ela não chega disfarçada de pedido de cliente. Chega disfarçada de gosto. O fundador genuinamente acredita que o produto precisa de X para ficar melhor. Às vezes está certo. Na maior parte das vezes, está entediado, e o antídoto para o tédio é construir.

O teste para essa fonte é o mais duro dos três. Espera sete dias. Se a feature ainda está na cabeça do fundador no sétimo dia, e ele consegue nomear três clientes que pediram especificamente por ela na mesma semana, construa. Se qualquer uma das duas condições falhar, arquive o pedido. A gente mantém um canal privado onde esses pedidos vão para morrer. Oitenta por cento nunca ressuscitam. O fundador nem lembra que escreveu a mensagem original.

Por que o conselho clássico (“só dizer não”) não funciona para fundador não-técnico

Todo outro artigo sobre feature creep no fim chega na mesma conclusão: o time deveria dizer não, o PM deveria defender o backlog, o líder de engenharia deveria empurrar de volta. É um conselho ótimo para uma empresa com PM de verdade e líder de engenharia sênior, ambos seguros o suficiente para passar por cima do fundador.

Essa não é a empresa que está assinando os cheques aqui. O fundador não-técnico é quem financia o build, atende os clientes, e aprova o roadmap. O time não tem como passar por cima dele. O time constrói o que mandam construir. Se o time é um parceiro externo ou contratado (que é a maior parte do nosso mundo), a dinâmica é pior, porque o time tem incentivo comercial para dizer sim. Cada sim é mais hora faturável.

Então o conselho “só dizer não” está estruturalmente invertido. Você, fundador, é o único que pode dizer não. Ninguém vai fazer isso por você. A defesa contra feature creep não é um processo que o time roda. É uma disciplina que o fundador constrói.

Essa disciplina tem um nome no nosso trabalho, e ela tem uma pergunta só.

O teste de uma pergunta: o teste dos sete dias

Antes de qualquer pedido de feature entrar no roadmap, o fundador passa o pedido por uma pergunta:

Eu consigo nomear, pelo nome da empresa, três clientes atuais que pediram essa feature nos últimos sete dias, por escrito ou em call gravada?

É só isso. Três clientes. Por nome. Por escrito. Em sete dias.

Se sim, a feature é candidata. Ela ainda tem que passar pela conversa de build, buy ou esperar, mas ganhou o direito de ter essa conversa.

Se não, o pedido vai para a pasta de morte. Não para o backlog. Não para a coluna de “depois”. Para a pasta de morte. O backlog é onde features vão para serem feitas. A pasta de morte é onde elas vão para serem esquecidas.

Esse teste faz cinco coisas úteis ao mesmo tempo. Força o fundador a ancorar o pedido em clientes reais, não no próprio gosto nem na deflexão de um prospect. Coloca um filtro de recência na demanda, então entusiasmos antigos expiram sozinhos. Exige evidência num formato que o fundador pode mostrar ao time, o que mata o padrão de “confia em mim, é o que eles querem”. Trata a isca de venda pelo que ela é: uma objeção educada de prospect não é cliente pedindo, pelo nome, por escrito, na última semana. E torna a inquietação do fundador visível, porque o fundador tem que admitir, em voz alta, que nenhum cliente está esperando aquilo que ele quer construir.

No primeiro mês depois que um fundador adota esse teste, ele tipicamente mata setenta por cento dos pedidos que entrariam no roadmap. No segundo mês, a velocidade do time nos trinta por cento que restaram dobra. No terceiro mês, o produto começa a parecer menor, e os usuários começam a usá-lo mais.

Como evitar feature creep quando o time é externo

O risco é mais alto quando o time que constrói o produto não é interno. Já vivemos isso dos dois lados: como o time que recebe a mensagem de Slack no domingo à noite, e como o operador que costumava mandar essas mensagens.

Os movimentos defensivos que funcionam:

• Um canal para pedidos de feature, uma cadência para triagem. Se pedidos de feature podem cair em qualquer conversa (DM de Slack, e-mail, corredor, call de venda), todos pesam igual, o que quer dizer que nenhum recebe escrutínio de verdade. Escolha um canal. Triagem semanal. O que não sobreviveu uma semana provavelmente não era real.
• Briefs escritos, não mensagens de Slack. Toda feature que sobrevive ao teste dos sete dias ganha um brief de uma página antes de ser construída. O brief obriga o fundador a articular o cliente, o caso de uso, a métrica de sucesso, e o custo de não construir. Algo como um quarto das features que sobrevivem ao teste de sete dias não sobrevive à escrita do brief.
• Um roadmap em que o time pode empurrar de volta. O fundador ainda é dono do roadmap. Mas o time ganha o direito de sinalizar os custos de segunda ordem de cada feature nova: que capacidade existente vai ficar mais lenta, que bug conhecido vai deixar de ser arrumado, que conta de manutenção está sendo assinada. O fundador pode passar por cima do alerta. Não pode estar desavisado dele.
• Um item permanente de “deletar” no roadmap. A cada trimestre, uma fatia razoável do tempo de build vai para remover features que não foram usadas nos últimos noventa dias. O produto encolhe de propósito. É o único contrapeso direto ao peso acumulado de cada sim anterior. Ninguém gosta de construir esse item. Todo fundador que fez agradeceu depois.

O custo de não fazer isso

Raramente encontramos um fundador não-técnico cujo produto é pequeno demais. Encontramos muitos cujo produto é grande demais e cuja empresa é pequena demais para mantê-lo.

Cada feature lançada é uma conta permanente de manutenção. O framework atualiza, a API de que a feature depende muda, o serviço terceirizado depreca um endpoint, o navegador muda a regra de renderização. Cada um desses eventos é de graça para as features que não existem. Cada um deles é hora faturável para as features que existem. A matemática compõe em silêncio. Dois anos para frente, metade da capacidade do time vai para manter o produto vivo em vez de levá-lo adiante, e o fundador não entende por que a velocidade desabou.

A velocidade desabou porque o fundador passou dois anos dizendo sim. O time fez exatamente o que mandaram. Construiu. Agora está preso mantendo. Nesse ponto, o fundador costuma começar a ouvir uma palavra diferente do time: rewrite. Essa conversa quase sempre é a errada. A certa é a conversa sobre deletar.

O trabalho para desfazer isso é real e sem glamour. Deletar features. Rodar o teste dos sete dias em tudo que é novo. Escrever briefs. Triagem em cadência. O produto encolhe, a conta encolhe, e a empresa começa a conseguir entregar a uma ou duas coisas que de fato moveriam o negócio. É o tipo de trabalho mais barato que existe, e é o tipo que quase ninguém faz até já ter pago pelo alternativo uma vez.

O CEO da abertura desse artigo fechou o laptop. Deletamos nove das vinte features sem uso ao longo do trimestre seguinte. O time entregou a única feature que estava enterrada na fila havia quatro meses — aquela que, quando olhamos os dados seis semanas depois, tinha movido retenção em onze pontos.

O produto estava esperando ele parar de construir.

FAQ

O que é feature creep em termos simples?
Feature creep é o que acontece quando um produto vai acumulando features devagar, passando do ponto em que alguém consegue dizer por que cada uma existe. Não é uma decisão ruim. São dezenas de decisões com cara razoável que somadas resultam num produto caro demais de manter e confuso demais para quem entra novo.

Qual a diferença entre scope creep e feature creep?
Scope creep é problema de contrato: trabalho extra entrando num build que já estava acordado por escrito. Solução: change order ou SOW renegociado. Feature creep é problema de produto: features se empilhando no roadmap ao longo do tempo, sem um momento único de decisão. Solução: uma disciplina rodada pelo fundador, não uma cláusula contratual.

Como evitar feature creep?
Passe todo pedido de feature por uma pergunta antes: você consegue nomear três clientes atuais que pediram isso, pelo nome da empresa, por escrito, nos últimos sete dias. Se não, o pedido vai para a pasta de morte, não para o backlog. Combine isso com um único canal para pedidos, triagem semanal, briefs escritos antes de qualquer build, e um item permanente de deletar no roadmap. O fundador é quem precisa cumprir tudo isso. Ninguém mais pode.

Por que fundador não-técnico causa mais feature creep do que técnico?
Dois motivos. Primeiro, o fundador não-técnico não sente diretamente o custo de cada feature nova: a atualização do framework, a mudança de API, o plantão. O preço fica invisível até estar enorme. Segundo, construir parece produtivo de um jeito que podar não parece, então o movimento padrão quando o fundador fica inquieto é adicionar em vez de remover. A combinação é o que produz um produto com quarenta features e três que importam.