Todo time de produto vive em algum ponto de uma tensão constante: construir o que já foi decidido ou investigar o que deveria ser construído a seguir. Na prática, essa tensão tem nomes — delivery e discovery.
Times que só fazem delivery executam bem mas perdem a conexão com o problema real. Times que só fazem discovery aprendem muito mas nunca entregam. O equilíbrio entre os dois é o trabalho real de um PM.
O que é delivery
Delivery é a execução: construir, testar, lançar o que foi decidido. Envolve refinamento de backlog, sprints, deploys, QA, comunicação de lançamento. É o trabalho que produz o produto que o usuário usa.
Delivery bem feito é mais do que código funcionando. É feature lançada com instrumentação para medir, com comunicação para o usuário entender, e com critério claro do que significa sucesso. Um deploy sem métricas é entrega às cegas.
O que é discovery
Discovery é a investigação: entender o problema antes de decidir a solução. Envolve entrevistas com usuários, análise de dados, testes de conceito, mapeamento de jornada, exploração de hipóteses. É o trabalho que decide o que vai para o backlog de delivery.
Discovery bem feito é mais do que coletar opiniões. É formular hipóteses claras, testá-las com o mínimo de esforço possível e sair com um aprendizado que muda ou confirma a direção. Para entender como conduzir discovery de forma estruturada, veja o artigo sobre como fazer discovery de produto.
Por que os dois precisam acontecer em paralelo
O modelo antigo — discovery no início do projeto, delivery depois — não funciona porque o produto está sempre mudando. O que foi descoberto há seis meses pode não ser mais verdade. Usuários mudam. Concorrentes mudam. O contexto muda.
No modelo moderno, discovery e delivery acontecem ao mesmo tempo, em ciclos sobrepostos. Enquanto o time está entregando a solução de hoje, o PM está descobrindo o problema de amanhã. Isso garante que o backlog nunca fique vazio e que o que entra no backlog sempre tem base em aprendizado recente.
A metáfora dos dois trilhos
Marty Cagan popularizou a ideia dos dois trilhos: um trilho de discovery onde o PM e o designer exploram problemas e testam soluções, e um trilho de delivery onde o time de engenharia constrói o que foi validado. Os dois andam em paralelo. O discovery alimenta o delivery — sempre com pelo menos um sprint de antecedência.
Como saber se o seu time está desequilibrado
Se o time está construindo features sem conseguir dizer qual problema cada uma resolve, há pouco discovery. Se o time está sempre em reuniões de alinhamento mas raramente lança algo, há pouco delivery. O diagnóstico é simples: olhe para os últimos três meses e separe as atividades em "aprendemos algo" e "entregamos algo". Se o equilíbrio está muito para um lado, é hora de corrigir.
O papel do PM no equilíbrio
O PM é o responsável por garantir que os dois trilhos existam e que se alimentem mutuamente. Isso significa proteger tempo de discovery mesmo quando há pressão de delivery, e proteger tempo de delivery mesmo quando há muitas perguntas abertas no discovery.
Na prática, significa ter rituais separados para cada trilho. Revisão de sprint para delivery. Sessões de síntese de pesquisa para discovery. Reuniões de backlog refinement que conectam os dois — onde o que foi aprendido no discovery vira critérios de aceite no delivery. Para entender como o PM garante qualidade no backlog, veja o artigo sobre como priorizar o backlog.
