O que é Product Discovery?

Product Discovery não tem um inventor único. Marty Cagan difundiu a distinção entre descobrir uma solução eficaz e entregá-la, além dos quatro riscos de produto. Teresa Torres formulou a prática de descoberta contínua com contato frequente entre a equipe construtora e clientes, orientado a um resultado desejado. Essas abordagens se complementam, mas não impõem uma única técnica ou cadência a todas as decisões.

Product Discovery é o trabalho de entender que problema vale resolver e que solução tem chance de produzir o resultado desejado. Teresa Torres o descreve como o trabalho de decidir o que construir, em relação ao delivery, que constrói, publica e mantém o produto. Na prática, a decisão não ocorre uma única vez antes da implementação. A equipe aprende com clientes, dados, protótipos, soluções em uso e efeitos da entrega. Discovery reduz incerteza, mas não oferece certeza absoluta antes de agir.

Comece pelo resultado. Um pedido de funcionalidade pode esconder uma necessidade legítima, mas a primeira pergunta é que mudança se busca. Mais pessoas concluirão uma tarefa? Um processo ficará mais seguro? Clientes encontrarão valor mais cedo? Defina público, linha de base e sinais de progresso quando possível. Sem direção, entrevistas produzem uma lista extensa de assuntos e testes viram demonstrações de ideias preferidas. O resultado deve dar foco sem determinar a solução antecipadamente.

Entenda a oportunidade. Dados de uso, chamados, observação e conversas revelam onde pessoas encontram dificuldade. Uma entrevista aberta sobre uma experiência passada costuma gerar detalhes mais concretos que perguntas hipotéticas como “Você usaria isto?”. O objetivo é identificar necessidades, dores e desejos em situações reais. Um relato individual é evidência situada, não prova da frequência do problema. Procure padrões, segmentos e casos contrários antes de generalizar.

Contato contínuo. Teresa Torres define descoberta contínua como pequenos contatos pelo menos semanais com clientes, conduzidos pela equipe que constrói o produto, em busca de um outcome. Essa cadência é uma proposta específica de prática, não condição para chamar qualquer investigação de discovery. Sua vantagem é manter evidência recente disponível no momento de decisão. Pesquisas maiores e especializadas continuam úteis quando a pergunta exige amostra, técnica ou profundidade diferente.

Quem participa. Produto, design e engenharia precisam compreender o problema e discutir alternativas. Torres usa o trio de produto para acelerar decisões compartilhadas; Marty Cagan enfatiza que avaliar riscos requer competências complementares. Pesquisadores, dados, suporte, operações, segurança e especialistas de domínio entram conforme a pergunta. Concentrar toda descoberta numa área e entregar um relatório pronto a outra diminui a chance de entendimento comum. Participação direta não elimina responsabilidades e técnicas especializadas.

Quatro riscos. Marty Cagan organiza riscos de produto em valor, usabilidade, viabilidade técnica e viabilidade de negócio. Pessoas escolherão usar ou pagar? Conseguirão usar? A equipe pode construir e operar? A solução respeita modelo econômico, regras e compromissos? Cada ideia tem perfil de risco diferente. Uma mudança pequena e reversível não exige o mesmo investimento em descoberta que uma aposta cara e difícil de desfazer. Avalie severidade e consequência antes de escolher testes.

Mapeie alternativas. A Opportunity Solution Tree conecta outcome, oportunidades, soluções e testes de suposições. Ela ajuda a não saltar diretamente de uma meta de negócio para a primeira feature. Uma necessidade pode ter várias respostas, incluindo alterar linguagem, processo, serviço humano ou produto digital. Gerar alternativas permite comparar impacto, esforço, acessibilidade e riscos. Não é necessário preencher uma árvore enorme; o raciocínio deve ser claro o bastante para orientar a próxima decisão.

Escolha a pergunta de pesquisa. Diferentes incertezas pedem métodos diferentes. Para saber por que pessoas abandonam uma tarefa, observação e entrevistas podem revelar obstáculos. Para saber se entendem um fluxo, teste de usabilidade com protótipo pode ajudar. Para verificar impacto de uma mudança em escala, um experimento controlado pode ser útil se houver volume e condições adequadas. Não escolha uma técnica porque está na moda; escolha porque a resposta possível mudará uma decisão concreta.

Teste suposições. Uma solução envolve hipóteses sobre interesse, compreensão, capacidade de entrega e operação. Identifique a mais arriscada e pense em um teste proporcional. Um protótipo pode mostrar se pessoas conseguem usar um fluxo, mas não garante que adotarão o produto ao longo do tempo. Uma página de interesse pode indicar intenção, mas não equivaler a compra. Registre antes do teste o que seria sinal favorável, desfavorável e inconclusivo para reduzir interpretação conveniente depois.

MVP e experimento. Um MVP pode permitir aprendizagem sobre valor com investimento limitado, desde que entregue uma experiência mínima coerente e não prejudique usuários. Nem todo teste precisa de software em produção; alguns demandam protótipo, atendimento manual ou análise. Uma versão pequena não é automaticamente um experimento: ela precisa de hipótese e observação. Construir menos sem aprender apenas reduz escopo da entrega, não reduz incerteza de produto.

Dados quantitativos. Funis, retenção, eventos e resultados de negócio ajudam a dimensionar problemas e observar efeitos. Defina população, período e qualidade da instrumentação. Uma taxa agregada pode esconder que um grupo específico sofre mais. Uma medida que melhora pode ter sido afetada por campanha, sazonalidade ou mudança no mix de clientes. Segmentação e comparação ajudam, mas nem sempre permitem atribuir causalidade. Use o número como evidência para investigar, não como sentença automática.

Dados qualitativos. Histórias, observação e feedback explicam como pessoas interpretam uma experiência e por que uma solução falha. Não converta uma citação memorável em prioridade universal. Busque casos que contradizem a hipótese, registre contexto e compare com dados de comportamento. A pesquisa qualitativa pode identificar riscos que não cabem no painel, como perda de confiança ou barreiras de acessibilidade. Seu valor está em melhorar o modelo do problema e propor perguntas melhores.

Discovery e delivery juntos. Delivery gera soluções utilizáveis e evidência real. Discovery ajuda a escolher, ajustar e descartar apostas. Não são dois times que passam trabalho por uma fronteira rígida. Durante implementação, uma limitação técnica pode abrir alternativa melhor; após publicação, comportamento observado pode revelar novo problema. O dual-track agile nomeia a coexistência de aprendizagem e entrega, mas cada organização precisa coordenar capacidade sem manter fila infinita de ideias testadas que nunca chegarão aos usuários.

Decisões explícitas. Ao fim de uma investigação, registre o que a equipe decidiu: prosseguir, adaptar, testar outra alternativa ou parar. Anote evidências e limites, não apenas uma etiqueta “validado”. Uma entrevista pode apoiar que a dor existe, mas não que a solução escolhida é viável. Um teste de usabilidade pode mostrar compreensão, mas não valor de negócio. Separar afirmações impede que a palavra validação encubra saltos lógicos entre problema, solução e resultado.

Prioridade e capacidade. O trabalho de descoberta compete por tempo com manutenção, suporte e entrega. Proteja uma cadência sustentável e concentre perguntas em poucas oportunidades relevantes. A liderança precisa explicitar resultado e limites, oferecer acesso a clientes e aceitar mudança de plano diante de evidência. Se contratos, bônus e roadmaps punem qualquer desvio da lista original, a pesquisa vira cerimônia que não altera decisões. A autonomia para aprender deve vir com responsabilidade por qualidade e impacto.

Ética e inclusão. Recrute pessoas de grupos que possam experimentar o produto de modo diferente, respeitando privacidade e consentimento. Não use um resultado médio para ignorar danos a uma minoria. Em contextos de saúde, finanças, educação ou serviços públicos, erros podem ter consequências relevantes. Prototipagem rápida não justifica prometer uma funcionalidade inexistente sem transparência ou coletar dados além do necessário. A escolha do teste deve considerar risco para participantes e clientes.

Limites da descoberta. Nem todo item precisa de entrevistas, árvore e experimento. Corrigir um erro evidente ou cumprir uma obrigação conhecida pode exigir execução direta e verificação técnica. Em outros casos, a consequência de errar é grande e justifica pesquisa profunda. Discovery também não é garantia de sucesso: pessoas podem mudar de comportamento e mercados podem mudar. Seu papel é tornar a aposta mais informada e permitir adaptação cedo.

Recrutamento e amostra. Encontrar participantes convenientes pode distorcer o entendimento. Clientes muito ativos costumam responder mais facilmente, mas talvez não representem quem abandonou o produto ou nunca conseguiu começar. Defina que grupos importam para a decisão e procure situações contrastantes. Em entrevistas exploratórias, busque variedade de experiências e sinais recorrentes; não interprete poucas conversas como uma pesquisa estatística. Em um experimento quantitativo, confira volume, segmentação e possibilidade de comparar grupos. Recrutar pessoas de suporte ou de comunidades próximas pode ser um início prático, desde que a equipe registre o viés e planeje formas de ouvir quem ficou invisível.

Repositório de aprendizagem. Sem registro leve, o time repete perguntas e transforma lembranças pessoais em fatos. Guarde a hipótese, a pergunta, o método, a população observada, evidências, limites e a decisão tomada. Um mapa de oportunidades pode apontar para esse material. Não é preciso produzir relatórios extensos após cada conversa; notas claras e acessíveis bastam para que outra pessoa entenda de onde veio a conclusão. Atualize o registro quando dados novos contradisserem uma crença antiga. O objetivo não é arquivar tudo, mas permitir que o conhecimento sobreviva à troca de pessoas e apoie escolhas futuras.

Aprendizagem após entrega. Volte ao outcome definido no início. O que mudou, para quem e com que efeitos colaterais? Compare sinais com a linha de base e relatos com a hipótese inicial. Se a solução foi usada mas não gerou benefício, investigue por que; se houve benefício parcial, considere segmento ou contexto. Registre o que ficou sem resposta. O ciclo termina com uma decisão melhor sobre o próximo investimento, não com um selo permanente de validação.

Exemplo hipotético: um produto de cursos digitais recebe o pedido “criar notificações diárias para aumentar conclusão”. A equipe define primeiro o outcome: aumentar de 30% para 45% a proporção de novos estudantes que concluem a primeira aula em sete dias, sem elevar pedidos de cancelamento. Entrevistas e observação mostram problemas diferentes: algumas pessoas não encontram um caminho inicial, outras não conseguem reservar tempo e outras temem conteúdo avançado. Notificação pode ajudar uma parte, mas não responde automaticamente a todas.

O time escolhe investigar a dificuldade de escolher a primeira aula. Desenha três alternativas: recomendação por objetivo, página de orientação e aula curta de demonstração. Testa protótipos com estudantes de perfis diferentes e descobre que a recomendação confunde quem não sabe formular objetivo. A página simples ajuda pessoas a escolher, mas exige linguagem mais clara para iniciantes. Esses testes indicam compreensão da proposta; ainda não comprovam que mais estudantes concluirão a aula.

Uma versão enxuta da página é entregue a um grupo limitado. No exemplo, a conclusão sobe de 30 para 39 em cada 100 estudantes comparáveis. Os pedidos de suporte caem de 25 para 20 por 100; cancelamentos permanecem estáveis. A equipe verifica se os grupos eram comparáveis e observa comportamento na semana seguinte. Os valores são ilustrativos, sem pretensão de evidência universal. O outcome ainda não alcançou o alvo, mas a evidência justifica ajustar a linguagem e testar a recomendação em outro segmento.

Antes, a lista de entregas começava com uma solução sugerida. Depois, a investigação tornou visíveis a oportunidade, alternativas, riscos e medida de sucesso. A equipe não precisou descobrir tudo antes de construir: aprendeu com protótipos e com uso real. Também não chamou o experimento de sucesso completo apenas porque publicou a página. Esse encadeamento é o núcleo do Product Discovery.

Discovery ajuda a decidir qual problema resolver e qual solução tem chance de funcionar. Delivery constrói, publica e mantém uma solução utilizável. A distinção é de perguntas e atividades, não de departamentos isolados ou fases que nunca se encontram. Aprendizados durante a construção podem alterar a hipótese; uso após a publicação pode alterar a prioridade. Ambos contribuem para o outcome, e nenhum substitui o outro.

Cursos K21 recomendados