5 sinais de que seu produto não foi descoberto direito
Backlog cheio de pedidos, ninguém fala com usuário, prioridade no grito e retrabalho constante. Conheça os 5 sinais de que faltou Discovery no seu produto e o que fazer.
Reconhece algum desses no seu time?
O sprint fecha, a feature sai, e três meses depois ninguém sabe dizer se ela mudou alguma coisa. O backlog cresce mais rápido do que o time consegue entregar. E a palavra "urgente" aparece tanto que já perdeu o sentido.
Nenhum desses problemas é de execução. São todos sintomas da mesma doença: o produto não passou por um Discovery de verdade. O time está construindo rápido, mas ninguém validou se está construindo a coisa certa.
Melissa Perri deu nome a isso no livro Escaping the Build Trap (O'Reilly, 2018): a armadilha da construção. Empresas que medem sucesso por quantidade de entregas, e não por valor gerado, viram fábricas de features. Ocupadíssimas, e paradas no lugar.
Aqui vão os cinco sinais mais comuns que encontramos em times que chegam até nós. Conte quantos você reconhece.
1. O backlog é uma lista de pedidos, não de problemas
Abra seu backlog agora. Se ele estiver cheio de itens como "adicionar filtro na tela X" e "botão de exportar PDF", sem nenhuma menção ao problema que cada item resolve, esse é o sinal número um.
Backlog saudável nasce de problemas validados, não de pedidos acumulados. Quando o time só recebe soluções prontas de fora, ele vira um executor de encomendas. E encomendas não têm hipótese, não têm métrica de sucesso e não podem ser invalidadas. Só podem ser entregues.
O teste rápido: para cada item do topo do backlog, pergunte "que problema isso resolve, e como saberemos que resolveu?". Se a resposta não existir, o item entrou sem Discovery.
2. Ninguém fala com usuário há meses
Quando foi a última vez que alguém do time assistiu a um usuário real usando o produto? Se a resposta é "no lançamento" ou "não lembro", o produto está sendo guiado por suposição.
Teresa Torres, autora de Continuous Discovery Habits, defende um mínimo semanal de contato com usuários para qualquer time de produto (Product Talk). Parece exagero até você ver o que uma única sessão de observação revela: atalhos que ninguém previu, funcionalidades ignoradas, gambiarras que o usuário inventou para contornar o que o produto deveria fazer por ele.
O Nielsen Norman Group, referência mundial em pesquisa de usabilidade, mostra há décadas que testar com poucos usuários já expõe a maioria dos problemas graves (NN/g). Ou seja: o custo de descobrir é baixo. O custo de não descobrir é que aparece na conta.
3. Features são lançadas e ninguém mede o que aconteceu
Lançou, comemorou, passou para a próxima. Essa rotina parece produtividade, mas é o terceiro sinal.
A Pendo estima que cerca de 80% das funcionalidades raramente ou nunca são usadas. Sem medir adoção, seu time não tem como saber em qual lado dessa estatística cada entrega caiu. E aí a roda gira: mais features, mais código para manter, mais complexidade, nenhuma evidência de valor.
O teste rápido: escolha as três últimas entregas e pergunte quantos usuários usam cada uma hoje. Se ninguém souber responder em cinco minutos, o ciclo de aprendizado está quebrado.
4. A prioridade é sempre do grito mais alto
Sabe aquela reunião em que a roadmap muda porque um diretor pediu, um cliente grande ameaçou sair ou o concorrente lançou algo? Esse fenômeno tem nome na literatura: HiPPO, a opinião da pessoa mais bem paga da sala (Highest Paid Person's Opinion), termo popularizado pelos estudos de experimentação online de Ron Kohavi, ex-Microsoft e Amazon (ExP Platform).
Opinião de executivo importa, claro. O problema é quando ela substitui evidência em vez de conviver com ela. Times com Discovery funcionando têm critérios de priorização explícitos: impacto no usuário, esforço, risco, alinhamento com objetivo de negócio. Quando o critério é volume de voz, a estratégia do produto muda a cada reunião.
5. O retrabalho virou rotina
Entregou. O usuário não entendeu. Refez. O cliente pediu diferente. Refez de novo. Se cada entrega gera uma fila de ajustes, correções e "não era bem isso", o time está usando o ambiente de produção como laboratório de validação. É o laboratório mais caro que existe.
O trabalho clássico de Barry Boehm sobre economia de software mostra que corrigir um erro de requisito depois da entrega custa ordens de magnitude mais do que corrigi-lo na fase de definição (Software Engineering Economics, 1981). Protótipo descartado custa dias. Feature refeita em produção custa meses, e leva junto a moral do time.
Contou quantos sinais?
Um ou dois sinais são alerta. Três ou mais indicam que o problema não está no time de desenvolvimento, e sim no que acontece (ou não acontece) antes do código: falta processo de descoberta, validação e priorização.
A boa notícia: isso tem conserto, e não exige parar tudo. Um ciclo de Discovery bem conduzido reorganiza o backlog em torno de problemas reais, reconecta o time com o usuário e devolve critério às prioridades. Explicamos como funciona o processo completo no artigo O que é Discovery e por que seu produto precisa, e é exatamente isso que fazemos no nosso serviço de Discovery e Product Owner.
Quer saber quais desses sinais têm solução mais rápida no seu caso? Converse com a IA da Rabelo Digital, aqui no cantinho da tela. Descreva seu cenário e ela mostra o próximo passo. Sem formulário, sem espera.
Deixe um Comentário