Neste capítulo, você vai entender o Product Discovery: o trabalho de descobrir qual problema vale a pena resolver antes de pedir ao time que construa uma solução. É a parte do papel do Product Owner que mais evita desperdício e a que mais costuma ser pulada.

Product Discovery é o conjunto de atividades que o Product Owner conduz para reduzir a incerteza sobre o que construir: conversar com usuários, observar o uso, analisar dados, testar hipóteses com protótipos e experimentos baratos. O objetivo não é ter certeza, e sim chegar à Sprint com itens que têm chance real de gerar valor.

Por que descobrir antes de construir

O maior desperdício em produtos não é código mal escrito; é código bem escrito para uma funcionalidade que ninguém usa. Levantamentos como o CHAOS Report, do Standish Group, indicam que boa parte das funcionalidades entregues é usada raramente ou nunca. O discovery existe para reduzir essa fatia, testando a ideia antes de gastar Sprints nela.

Discovery e delivery não são fases sequenciais. Em um time maduro, elas acontecem em paralelo: enquanto os Developers constroem a Sprint atual, o Product Owner e parte do time investigam o que vem a seguir.

Quatro riscos que o discovery reduz

• Valor
  O cliente vai querer isso? Testado com entrevistas, pesquisas e protótipos.
• Usabilidade
  O cliente vai conseguir usar? Testado com protótipos navegáveis e testes de uso.
• Viabilidade
  Conseguimos construir com o que temos? Testado com spikes técnicos junto aos Developers.
• Negócio
  Funciona para a empresa? Testado com análise de custo, canal, marca e aspectos legais.

Técnicas que cabem na rotina

• Entrevistas com usuários: poucas conversas bem conduzidas costumam revelar mais do que uma pesquisa com muitas respostas superficiais.
• Mapa de jornada: desenhar o que a pessoa faz hoje, passo a passo, expõe onde está a dor.
• Protótipos descartáveis: papel, slides ou ferramentas de design; o critério é ser barato de jogar fora.
• Experimentos: uma landing page, um botão que ainda não faz nada, um teste A/B. Medem comportamento, não opinião.

O Product Owner no discovery

Imagine um médico que prescreve antes de examinar. Pode acertar, mas o risco é alto e o custo do erro é de quem toma o remédio. O Product Owner que coloca itens no backlog sem descobrir nada está prescrevendo sem examinar. O discovery é o exame, e é responsabilidade de quem decide o que entra no backlog.

Descobrir o problema leva naturalmente à pergunta do próximo capítulo: para quem, exatamente, estamos resolvendo? É aí que entram as personas e o contexto do produto.