Ao longo dos últimos anos como trainer da Scrum.org, venho observando um padrão curioso nas turmas de Scrum Masters e Product Owners.
Em algum momento do treinamento, surge uma pergunta recorrente:
“Eu entendi como o Scrum funciona… mas onde entra aquele planejamento inicial que fazíamos no modelo tradicional?”
Essa dúvida normalmente aparece quando as pessoas comparam dois mundos.
No modelo tradicional, existe um esforço grande no início para definir escopo, prazo e direcionamento.
Já no Scrum, aprendemos de forma empírica e incremental ao longo das Sprints.
E é justamente nesse ponto que muitos profissionais não conseguem fazer a conexão.
O problema: começar sem clareza
Modelos tradicionais de projeto sempre começam com muito planejamento:
Definição de escopo
Estimativas de esforço
Definição de orçamento
O Scrum propõe uma abordagem diferente, baseada em empirismo — aprender fazendo, inspecionando e adaptando continuamente.
Mas existe uma tensão real nas organizações.
Na prática, você não pode simplesmente começar a desenvolver “para ver no que acontece”.
Ainda é necessário ter:
Direção
Alinhamento estratégico
Uma ideia mínima de investimento
E é exatamente nesse ponto que muitos times travam.
A peça que falta: Product Discovery
Antes de construir qualquer coisa, precisamos responder uma pergunta fundamental:
Vale a pena construir isso?
Product Discovery é a disciplina que ajuda a reduzir incerteza antes de comprometer tempo, esforço e investimento em delivery.
É durante o discovery que buscamos entender:
Quem são nossos usuários
Quais problemas realmente existem
Qual problema vale a pena resolver
O que é valor — para o cliente e para o negócio
Sem esse entendimento, corremos um risco alto:
Construir soluções eficientes… para problemas errados.
De ideias para hipóteses
Uma mudança importante que o discovery traz é a forma como pensamos o trabalho.
Em vez de dizer:
“Vamos construir essa funcionalidade”
Passamos a dizer:
“Vamos testar se essa ideia faz sentido”
Isso implica em:
Formular hipóteses
Desenhar experimentos
Coletar evidências
Tomar decisões com base em aprendizado
Não em opinião.
Não em hierarquia.
Mas em dados.
Scrum e Discovery não competem — eles se complementam
Muitas vezes, discovery e Scrum são tratados como coisas separadas.
Na prática, eles são complementares.
O Scrum é extremamente eficaz para:
Entregar incrementos
Gerar feedback
Permitir inspeção e adaptação
Mas ele parte de uma premissa importante:
Que já temos algo relevante para construir.
E é justamente isso que o discovery ajuda a garantir.
Ele melhora a qualidade do que entra no Product Backlog.
Empirismo além do delivery
Se olharmos para os pilares do Scrum — transparência, inspeção e adaptação — fica claro que o discovery é uma extensão natural desse pensamento.
Não se trata apenas de inspecionar o que foi construído.
Mas também de inspecionar se estamos resolvendo o problema certo.
Na prática, vejo muitos times altamente eficientes… construindo coisas que não deveriam existir.
E nesse cenário, eficiência apenas acelera o desperdício.
Discovery contínuo e Dual Track Agile
Outro ponto importante: discovery não é uma fase isolada.
Mesmo com o produto em produção, o contexto continua mudando:
Usuários evoluem
O mercado se transforma
Novas oportunidades surgem
Por isso falamos em Continuous Discovery.
Muitos times organizam esse trabalho através do Dual Track Agile:
Um fluxo focado em discovery (entender e validar)
Outro focado em delivery (construir e entregar)
Acontecendo em paralelo.
Isso permite que os times mantenham relevância enquanto continuam entregando valor.
O verdadeiro gap do mercado
Na prática, a maioria dos profissionais aprende muito bem o delivery.
Sabem:
Trabalhar com Product Backlog
Participar dos eventos do Scrum
Entregar incrementos
Mas encontram dificuldades quando precisam:
Definir o problema
Priorizar oportunidades
Validar ideias antes de construir
E é exatamente nesse ponto que o sucesso do produto é determinado.
Conclusão
O Scrum ajuda você a construir da forma certa.
O Product Discovery ajuda você a construir a coisa certa.
E em um ambiente cada vez mais dinâmico e incerto, essa diferença se torna crítica.
Encerramento
Para times que já dominam a execução, aprofundar práticas de discovery e validação pode ser um próximo passo natural na evolução do uso do Scrum — ampliando o foco de “como construir” para também incluir “o que realmente vale a pena construir”.