Existe um padrão que aparece em times de engenharia depois do segundo ou terceiro ano de operação. O roadmap cresce em número de itens entregues a cada trimestre e a velocity se estabiliza num patamar confortável. Nenhuma dessas métricas guarda correlação visível com receita, retenção ou adoção. O time entrega mais do que entregava há doze meses, mas o negócio não cresce na mesma proporção. Em alguns casos, não cresce em proporção alguma. Pra mim, o que se instala aqui é a configuração que John Cutler, product thinker e autor do blog Beautiful Mess, chamou de feature factory: uma organização que otimiza a produção de features como se features fossem, por si só, a unidade de valor do negócio.
A feature factory não nasce de má intenção, mas de um incentivo legível. Throughput é fácil de medir e fácil de comunicar pra liderança, até porque se traduz em gráfico ascendente em apresentação trimestral. Outcome é difícil de medir e demora pra aparecer, até porque depende de variáveis que o time de engenharia não controla, e raramente encaixa no ciclo de review individual. A pressão por visibilidade empurra o time pra métrica que existe, e a métrica que existe é quantidade de coisa entregue. Daí em diante, o sistema reforça a si mesmo. Quanto mais o time entrega, mais backlog é criado pra manter o ritmo, e o discovery vira mero intake de demandas. A conversa sobre se determinada feature deveria existir simplesmente desaparece do processo.
Na minha análise, a feature factory opera com um defeito estrutural na função de custo. O custo contabilizado é o de construir. O custo ignorado é o de ter construído. Cada feature entregue aumenta a superfície operacional do produto de forma permanente, enquanto o benefício esperado é, na maioria dos casos, hipotético e não validado. Em dois ou três anos, o produto acumula centenas de funcionalidades, das quais uma fração pequena é usada de forma recorrente, e o time tem a capacidade de mudança consumida pelo peso do que já foi entregue.
O mecanismo opera em camadas que se reforçam. Num time saudável, uma feature nasce de uma hipótese sobre comportamento de usuário ou impacto de negócio, articulada antes da construção, com critério explícito pra julgar se ela se confirmou. Numa feature factory, a feature nasce de um pedido de stakeholder, que entra no backlog e é priorizado pela combinação de urgência percebida e influência política de quem pediu. O artefato de entrada não contém hipótese, e portanto não há critério posterior pra avaliar se a feature deveria ter existido. Sobre essa substituição se instala uma segunda confusão, entre métrica de sucesso e métrica de entrega. A pergunta "a feature foi entregue no prazo" substitui a pergunta "a feature produziu o efeito esperado". Fechando o ciclo, não existe mecanismo de descontinuação. Features entregues permanecem no produto por tempo indefinido, mesmo quando dados de uso indicam que o custo de mantê-las é superior ao valor que produzem.
Operar com rigor de outcome exige instrumentação e tolerância política pra matar trabalho em andamento quando os dados indicam que a hipótese estava errada. Esse rigor atrita com ciclos trimestrais e com compromissos assumidos publicamente, na pressão de demonstrar progresso contínuo pra board e investidores. Uma organização que abandona a feature factory por completo corre o risco oposto: paralisia analítica e discovery infinito que bloqueiam qualquer entrega antes que o concorrente entregue. Na minha avaliação, o equilíbrio passa por subordinar throughput a outcome, preservando a métrica sem tratá-la como objetivo. Throughput diagnostica saúde de pipeline. Não define sucesso de produto.
O contraponto aparece com frequência nas métricas DORA. Deployment frequency, lead time, change failure rate e time to restore descrevem a saúde operacional do sistema de entrega, e é correto otimizá-las. O erro é tratá-las como proxy de valor. Um time que aumenta deployment frequency de semanal pra diária melhorou a capacidade de entregar, mas só consegue demonstrar que essa capacidade virou valor se correlacionar releases com movimentos em métricas de produto. Sem essa ponte, DORA vira instrumento de feature factory mais eficiente, mas não de produto melhor.
Num caso recente, um time de onze pessoas entregou cinquenta e três itens de backlog num trimestre, com lead time médio de três dias e change failure rate de 4%. A revisão de uso mostrou que onze dessas entregas tinham adoção acima de 10% da base ativa, e sete produziam receita atribuível. As trinta e cinco restantes consumiram cerca de 60% da capacidade do trimestre e passaram a compor a superfície de manutenção permanente do produto. O efeito de segunda ordem apareceu no trimestre seguinte. O tempo pra construir cada nova feature aumentou de forma perceptível, até porque cada mudança precisava considerar interações com funcionalidades que ninguém usava mas que alguém poderia reclamar se parassem de funcionar.
Pra mim, feature factory é, no fundo, uma dívida de clareza convertida em dívida de código. Quando a organização não tem mecanismo pra decidir o que não construir, todo trabalho pedido vira trabalho feito, e todo trabalho feito vira carga operacional. A saída passa por construir a função de custo correta, incluindo no orçamento de cada feature o custo de mantê-la por três anos e o de removê-la quando os dados pedirem. Entregar menos vira consequência do método, mas não é o objetivo. Produtividade em engenharia de produto se mede por quanto do que foi entregue continua justificando sua própria existência doze meses depois.