É sprint review. O PM sobe o slide com o resumo do trimestre: quarenta e duas features entregues, velocity 18% acima da meta, todos os tickets críticos do Jira fechados dentro do prazo. O time está visivelmente orgulhoso — e com razão, pelo critério que a empresa usa para medir o próprio trabalho.
Um investidor, presente na reunião, faz uma pergunta simples: “e o que isso fez com a retenção?”
Silêncio na sala. Alguém murmura que vai levantar os números. Ninguém tem a resposta na ponta da língua — porque ninguém estava medindo isso enquanto construía.
Esse silêncio é o sintoma mais claro de um padrão que John Cutler nomeou com precisão cirúrgica: a feature factory. Um time de produto medido — e recompensado — por output, pela quantidade de coisas que saíram, em vez de outcome, pelo problema real que foi resolvido para o usuário ou para o negócio.
O paradoxo central desse padrão é desconfortável: é inteiramente possível ter um dos times de produto mais “produtivos” do mercado, segundo os critérios que a própria empresa usa para medir produtividade, e ainda assim estar destruindo o produto a cada entrega — adicionando complexidade sem adicionar valor, acumulando decisões de design que nunca foram validadas, ocupando o tempo de engenharia com apostas que ninguém testou antes de comprometer recursos.
A diferença entre times de produto medianos e extraordinários raramente é talento individual ou ferramentas melhores. É se a organização opera em modo de fábrica de features ou em modo de descoberta contínua de problemas validados.
O que é uma feature factory, exatamente
Uma feature factory é uma organização de produto onde o roadmap é definido primariamente por solicitações — de vendas, de clientes específicos com poder de influência, do CEO, de movimentos da concorrência — e onde o sucesso do time é medido pela velocidade de entrega, não pela validação prévia de que aquilo resolve um problema real, nem pelo impacto posterior mensurável após o lançamento.
John Cutler observou esse padrão se repetindo em times que, superficialmente, pareciam estar indo muito bem: entregavam rápido, tinham processos de engenharia maduros, raramente atrasavam prazos. O problema não estava na execução — estava completamente ausente a pergunta que deveria precedê-la: por que estamos construindo isso, e como saberemos se funcionou?
É importante reconhecer que esse modelo não nasce de incompetência. Ele é o resultado lógico e previsível de um conjunto específico de incentivos que recompensam visibilidade de entrega em detrimento de validação de impacto. Um roadmap cheio de itens “entregues” é fácil de mostrar num relatório executivo. Um processo de validação que descartou três hipóteses antes de encontrar a certa é mais difícil de comunicar, mesmo sendo o trabalho mais valioso que aconteceu naquele trimestre.
O efeito mais traiçoeiro desse padrão é a ilusão de produtividade que ele gera. Gráficos de velocity sobem. O número de features lançadas por trimestre cresce. Tickets fecham dentro do prazo. Todas essas métricas indicam, superficialmente, que a máquina está funcionando bem — mesmo quando o produto, como experiência completa para o usuário, não está melhorando, e em muitos casos está se tornando mais confuso e mais difícil de usar.
Como uma feature factory se forma sem ninguém decidir conscientemente criar uma
Nenhuma empresa anuncia a intenção de se tornar uma fábrica de features. O padrão emerge organicamente, geralmente a partir de pressões que parecem, isoladamente, perfeitamente razoáveis.
A origem mais comum começa no time comercial. Vendas perde um deal importante porque, segundo o feedback do cliente, “falta uma feature específica”. A pressão para resolver essa perda — totalmente compreensível do ponto de vista de quem está tentando bater meta — coloca o pedido diretamente no roadmap, frequentemente sem qualquer validação de quantos outros clientes, atuais ou potenciais, compartilham esse mesmo problema. Repita esse processo algumas dezenas de vezes ao longo de alguns trimestres, e o roadmap deixa de ser uma teoria coerente sobre como o produto deveria evoluir e se torna uma coleção de promessas pontuais feitas a clientes específicos.
Um segundo mecanismo de origem é a ausência de framework de priorização para o volume constante de feedback que chega de múltiplas fontes — suporte ao cliente, calls de vendas, redes sociais, conversas informais com o time de sucesso do cliente. Sem um critério explícito e disciplinado para avaliar esse fluxo, produto tende, por padrão comportamental humano, a responder ao pedido mais recente ou ao pedido que vem de quem tem mais autoridade hierárquica — o CEO, o cliente mais importante — em vez de responder ao pedido mais validado por evidência. A ausência de research estruturado não é uma escolha deliberada de não fazer pesquisa; é simplesmente o que acontece por padrão quando ninguém constrói o processo que faria diferente.
O terceiro mecanismo é talvez o mais sutil: a assimetria entre o que é fácil de medir e comunicar e o que realmente importa. “Lançamos quarenta features esse trimestre” é uma frase simples, concreta e impressionante para qualquer board. “Validamos, através de doze entrevistas e um teste de conceito, que esse problema específico existe para aproximadamente 60% do nosso ICP, e por isso decidimos investir nele” é uma frase mais nuançada, mais difícil de comunicar rapidamente, e — apesar disso — infinitamente mais valiosa como informação sobre a saúde real do produto. Métricas fáceis de comunicar recebem atenção desproporcional. Métricas que exigem mais contexto ficam de lado, mesmo sendo as que realmente deveriam orientar decisões de investimento.
O custo real de operar em modo fábrica
O primeiro custo visível é um produto progressivamente inchado e incoerente. Cada feature construída para atender a um cliente específico, sem validação de que serve a um público mais amplo, adiciona complexidade à experiência geral. O usuário médio, que nunca pediu aquela funcionalidade, encontra uma interface mais confusa, mais opções desnecessárias, um produto que parece ter perdido o fio da própria narrativa.
O segundo custo é o que podemos chamar de dívida de produto — um paralelo direto à dívida técnica que se acumula quando engenharia prioriza velocidade sobre qualidade de construção. Decisões de design tomadas sem validação prévia frequentemente precisam ser desfeitas meses depois, quando o impacto negativo finalmente se torna visível através de métricas de uso ou de retenção. O custo de desfazer e refazer essas decisões é estruturalmente maior do que o custo de tê-las testado antes de comprometer recursos de engenharia.
O terceiro custo é humano e conecta diretamente com um padrão discutido em outro contexto deste blog: o esgotamento e a saída de talentos seniores do time de produto e design. Trabalhar continuamente entregando, sem nunca ver evidência clara de impacto real, gera nos profissionais mais experientes a sensação de estar numa esteira de produção, não construindo algo com propósito identificável. Esse é precisamente o tipo de ambiente que profissionais seniores — que já viveram esse padrão em outras empresas e reconhecem os sinais rapidamente — têm menos tolerância para permanecer.
O quarto custo, e talvez o mais perigoso por ser o mais silencioso, é a ilusão que mascara o problema central enquanto ele se acumula. Enquanto a empresa continua entregando volume visível de trabalho, raramente alguém pergunta se está resolvendo o problema certo — até que a retenção estagne, o crescimento desacelere sem explicação aparente nos números de topo de funil, e a investigação retroativa revele que o produto se afastou progressivamente das necessidades reais do público que deveria servir.
O que é discovery contínua, de fato
A alternativa a esse padrão tem nome e metodologia bem estabelecidos, articulados com mais clareza por pensadores como Teresa Torres e Marty Cagan: discovery contínua é o processo constante — não pontual, não restrito a uma fase específica antes do desenvolvimento — de testar suposições sobre problemas e soluções antes de comprometer engenharia a construí-las.
A diferença conceitual central é importante e frequentemente mal compreendida: discovery não é uma fase que acontece uma vez, antes da definição do roadmap, como um projeto de pesquisa isolado. É uma atividade paralela e ininterrupta que informa o roadmap a cada ciclo, continuamente, em vez de apenas no início de um grande planejamento trimestral ou anual.
Discovery contínua, bem executada, testa sistematicamente três tipos distintos de risco antes que qualquer linha de código seja escrita para uma solução completa: risco de valor — o usuário realmente quer isso, ou apenas disse que gostaria em uma conversa pontual? Risco de usabilidade — mesmo que o usuário queira, ele consegue de fato usar a solução proposta sem fricção excessiva? E risco de viabilidade — a empresa consegue construir isso de forma sustentável, técnica e economicamente, no longo prazo?
Existe um mito comum que vale desfazer explicitamente: discovery contínua não significa operar mais lentamente. Significa investir tempo de validação relativamente barato — conversas, protótipos, testes de conceito — antes de investir tempo de engenharia muito mais caro na construção de uma solução completa que pode, eventualmente, não resolver o problema que deveria resolver.
Como discovery contínua funciona na prática
A primeira prática estrutural é tratar conversas com usuários como um hábito constante, não como um projeto pontual que acontece apenas antes de grandes decisões. Times que praticam discovery contínua de verdade mantêm uma cadência regular de entrevistas — semanais, mesmo que poucas e curtas — em vez de pesquisas esporádicas e extensas que acontecem apenas quando alguém já decidiu que precisa de “validação” para uma ideia que, na prática, já foi decidida internamente. Esse fluxo constante de sinal direto do usuário reduz drasticamente a dependência do cliente que gritou mais alto como principal fonte de direção do produto.
A segunda prática é prototipagem rápida e teste de conceito antes de qualquer compromisso real de engenharia. Protótipos de baixa fidelidade — mockups clicáveis, fluxos navegáveis sem lógica de backend funcional, até roteiros estruturados de conversa — testam risco de valor e de usabilidade a uma fração do custo de construir a funcionalidade completa. Formatos específicos como testes de concierge, onde a equipe entrega manualmente o valor da futura funcionalidade antes de automatizá-la, ou testes de fake door, onde se mede demanda através de uma chamada para ação que ainda não tem a funcionalidade completa por trás, permitem validar interesse real antes de qualquer linha de código de produção.
A terceira prática é definir critérios de validação explícitos antes de comprometer recursos significativos — uma extensão direta do conceito de pré-mortem discutido em relação a decisões organizacionais mais amplas. Definir, por escrito e antes da construção, o que especificamente precisaria ser verdade para que aquela aposta de produto valesse o investimento, transforma completamente a natureza da conversa interna. Em vez de “vamos construir isso porque o cliente X pediu com insistência”, a conversa se torna “vamos construir isso porque validamos, através de evidência específica, que resolve um problema real para uma parcela relevante e mensurável do nosso ICP”.
A quarta prática, mais estrutural e mais difícil de implementar, é dar a squads de produto autonomia genuína para descobrir soluções, não apenas mandato para entregar especificações já definidas por outra pessoa. Existe uma diferença fundamental entre um squad que recebe um documento de requisitos prontos para implementação e um squad que recebe um problema de negócio bem definido, com contexto suficiente, e autonomia real para investigar qual é a melhor forma de resolvê-lo. Nesse modelo, o papel do PM deixa de ser gerente de backlog — alguém que organiza e prioriza pedidos que chegam de fora — e se torna dono do problema, responsável por entender profundamente a necessidade antes de comprometer qualquer recurso de construção.
Como fazer a transição sem travar a empresa
A tensão mais honesta que precisa ser reconhecida antes de qualquer transição é que discovery contínua exige tempo e estrutura que, no curto prazo, podem parecer atrasar a velocidade de entrega que a organização está acostumada a celebrar. Negar essa tensão, ou prometer que a transição será indolor, mina a credibilidade do processo desde o início. A administração correta dessa expectativa — com a liderança, com o board, com o próprio time — é parte essencial de fazer a mudança funcionar.
A recomendação prática mais eficaz é começar pequeno e deliberadamente contido: escolher uma squad específica ou uma iniciativa específica para operar segundo os princípios de discovery contínua como piloto, em vez de tentar transformar toda a organização de produto simultaneamente. Um piloto bem-sucedido, com resultados mensuráveis, cria o caso de uso interno que facilita a expansão gradual do modelo para outras partes da organização.
Junto com esse piloto, é necessário redefinir explicitamente as métricas pelas quais o sucesso do time de produto é avaliado: de número de features entregues por período para indicadores de outcome — retenção, ativação, expansão de uso — diretamente atribuíveis às iniciativas específicas que foram lançadas. Sem essa mudança paralela de métrica, qualquer tentativa de mudar processo de trabalho encontra resistência estrutural, porque o sistema de incentivos continua recompensando exatamente o comportamento que se está tentando substituir.
Por fim, é essencial educar o board e a liderança comercial sobre o argumento econômico por trás dessa mudança, não apenas o argumento metodológico. Discovery contínua, executada com disciplina, reduz significativamente o desperdício de tempo de engenharia — o recurso mais caro disponível para a maioria das startups — em features que, construídas sem validação prévia, acabam não gerando o impacto esperado. Esse argumento financeiro, apresentado com clareza, tende a ressoar mais com lideranças orientadas a resultado do que um argumento puramente sobre qualidade de processo.
A sprint review da introdução não precisa terminar em silêncio constrangedor. O time de produto verdadeiramente extraordinário não é aquele que entrega mais rápido — é aquele que aprende mais rápido sobre o que realmente vale a pena entregar antes de comprometer recursos para construir.
Uma feature factory pode parecer produtiva por anos antes que alguém finalmente faça a pergunta certa: produtiva em direção a quê?
Da última feature que seu time lançou, alguém validou o problema antes de validar a solução — ou o problema foi simplesmente assumido porque alguém com autoridade suficiente pediu?
Seu time de produto já passou pela transição de feature factory para discovery contínua? O que foi mais difícil de mudar — o processo de trabalho em si, ou a forma como o sucesso do time é medido e comunicado para o resto da empresa? Conta nos comentários — essa transição raramente é linear, e entender como outras equipes navegaram esse caminho ajuda mais do que qualquer framework isolado.
