Product discovery é o processo contínuo de descobrir o que construir — validar valor, usabilidade, viabilidade e negócio antes de investir em desenvolvimento — enquanto product delivery é o processo de construir e entregar bem aquilo que foi validado. Times que confundem os dois constroem rápido as coisas erradas; times que fazem discovery sem método viram teatro de pesquisa. Este guia mostra os métodos centrais, os quatro grandes riscos e como rodar discovery contínuo na prática.
Se você já trabalha com experimentação, a lógica é a mesma do nosso guia da área de experimentação de produto: hipótese antes de código, evidência antes de opinião.
O que é product discovery (e o que não é)
Product discovery é a frente do trabalho de produto que responde a uma pergunta: vale a pena construir isso? A outra frente, product delivery, responde a outra pergunta: como construímos isso bem, rápido e com qualidade? As duas rodam em paralelo nos melhores times — o que Marty Cagan, do Silicon Valley Product Group, chama de dual-track agile.
Discovery não é:
- Fazer uma pesquisa grande no início do projeto e nunca mais falar com usuários. Isso é pesquisa pontual, não discovery.
- Validar a solução que o stakeholder mais sênior já decidiu. Isso é teatro de validação.
- Coletar feedback sem critério de decisão. Discovery existe para reduzir risco de decisão, não para acumular opinião.
Discovery é um fluxo contínuo de aprendizado com usuários reais, conectado a oportunidades de negócio. Teresa Torres formalizou isso no conceito de continuous discovery: no mínimo um contato semanal com usuários, conduzido pelo próprio time que constrói o produto, alimentando pequenas decisões — não apenas grandes apostas.
Os 4 grandes riscos de Marty Cagan
O framework mais útil para organizar discovery é o dos quatro grandes riscos, descrito por Marty Cagan no livro Inspired e nos artigos do SVPG. Toda ideia de produto precisa responder a quatro perguntas antes de entrar em delivery:
- Risco de valor: o cliente vai comprar ou usar? É o risco que mata a maioria dos produtos. Resolve-se com entrevistas, testes de demanda e protótipos de valor.
- Risco de usabilidade: o usuário consegue descobrir como usar? Resolve-se com testes de usabilidade em protótipos, não com opinião de comitê.
- Risco de viabilidade (feasibility): a engenharia consegue construir com o tempo, tecnologia e dados disponíveis? Envolve os engenheiros desde cedo, não no fim.
- Risco de negócio (viability): funciona para os aspectos do negócio — jurídico, financeiro, go-to-market, marca? Uma feature que o jurídico barra depois de pronta é discovery mal feito.
O papel do discovery é atacar o risco mais alto de cada ideia com o teste mais barato possível. Se o maior risco é valor, não adianta fazer spike técnico. Se o maior risco é viabilidade, não adianta entrevistar mais usuários.
Os métodos centrais de discovery
Entrevistas com usuários
A base de tudo. Entrevistas de discovery não perguntam “você usaria isso?” — perguntam sobre comportamento passado e contexto real: “conte a última vez que você enfrentou esse problema”. A mesma disciplina de fazer boas perguntas aparece no nosso guia de pesquisa e no processo de UX research aplicado a CRO: observar comportamento vale mais do que coletar opinião.
Jobs to be done (JTBD)
JTBD troca a pergunta “quem é o usuário?” por “qual progresso ele está tentando fazer?”. Ninguém quer uma furadeira; quer o buraco na parede — e às vezes nem o buraco, quer o quadro pendurado. Mapear o job ajuda a separar oportunidades reais de pedidos disfarçados de solução. O pedido “quero um relatório em Excel” quase sempre esconde um job do tipo “preciso prestar contas ao meu chefe sem retrabalho”.
Opportunity solution tree
Ferramenta central do trabalho de Teresa Torres: uma árvore que conecta um outcome de negócio (ex.: aumentar retenção) a oportunidades (dores e desejos descobertos nas entrevistas) e só então a soluções candidatas e experimentos. A árvore força o time a mapear o espaço do problema antes de pular para soluções — e deixa explícito quando alguém está pulando.
Protótipos
Protótipos de discovery existem para testar valor e usabilidade em dias, não semanas. Podem ser telas clicáveis em Figma, páginas fake door, protótipos de concierge (o serviço é entregue manualmente por trás) ou até uma planilha que simula o resultado. O critério é: qual o menor artefato que gera evidência real sobre o risco em questão?
Experimentos
Quando a dúvida é comportamental — “as pessoas vão realmente fazer isso?” — nada substitui medir comportamento real. Testes A/B, fake door e pilotos com subconjunto de usuários fecham o ciclo. A disciplina é a mesma da pesquisa de conversão no modelo ResearchXL: hipótese, métrica definida antes, decisão definida antes.
| Método | Risco que mais mitiga | Quando usar |
|---|---|---|
| Entrevistas com usuários | Valor | Sempre; é a espinha dorsal do discovery contínuo |
| JTBD | Valor | Para reenquadrar pedidos de feature como problemas |
| Opportunity solution tree | Valor e foco | Para organizar oportunidades e evitar pular para soluções |
| Protótipos (Figma, concierge, fake door) | Usabilidade e valor | Antes de qualquer linha de código de produção |
| Experimentos (A/B, piloto) | Valor e negócio | Quando a dúvida é comportamental e mensurável |
| Spike técnico | Viabilidade | Quando a dúvida é tecnológica ou de dados |
Discovery contínuo sem virar teatro de pesquisa
A falha mais comum é transformar discovery em ritual sem consequência: o time entrevista, documenta, apresenta — e constrói exatamente o que já ia construir. Três práticas separam discovery real de teatro:
- Ritmo mínimo semanal. Teresa Torres recomenda contato com usuários toda semana, feito pelo trio de produto (PM, designer, engenheiro). Um time que entrevista 3 usuários por semana acumula 39 pontos de contato em um trimestre de 13 semanas — base de evidência impossível de obter com uma pesquisa única por ano.
- Cada atividade ligada a uma decisão. Antes de rodar qualquer método, escreva: “vamos decidir X com base nisso; se o resultado for Y, fazemos Z”. Sem decisão atrelada, é turismo de pesquisa.
- Assumir que a maioria das ideias falha. O SVPG trabalha com a premissa de que pelo menos metade das ideias de produto não gera resultado. Discovery existe para descobrir isso em dias, não depois de meses de desenvolvimento.
Ferramentas de IA ajudam a escalar a análise — transcrever, codificar e agrupar falas de entrevistas — sem substituir o contato com o usuário. Detalhamos esse ponto no artigo sobre IA em pesquisa qualitativa e UX research.
Exemplo prático
Considere um cenário típico de e-commerce brasileiro: a diretoria pede um app nativo porque “concorrentes têm”. Em vez de abrir um projeto de seis meses, o time roda quatro semanas de discovery. Nas entrevistas, descobre que os clientes não reclamam de canal — reclamam de não conseguir acompanhar a entrega. Um protótipo de página de rastreamento, testado com doze usuários, resolve a dor real com uma fração do custo. O app volta para a árvore de oportunidades com a pergunta certa: qual outcome ele moveria? Discovery não matou a ideia; matou a versão cara da hipótese errada.
Fontes
- Silicon Valley Product Group (SVPG) — artigos sobre product discovery e os quatro grandes riscos
- Product Talk — o que é product discovery (Teresa Torres)
- Product Talk — continuous discovery habits
Perguntas frequentes
Qual a diferença entre product discovery e product delivery?
Discovery responde “o que construir e por quê”, reduzindo os riscos de valor, usabilidade, viabilidade e negócio. Delivery responde “como construir bem”, com engenharia, qualidade e release. Em times maduros, as duas frentes rodam em paralelo: enquanto o delivery entrega o ciclo atual, o discovery valida o próximo.
Quanto tempo deve durar um discovery?
Discovery não é uma fase com início, meio e fim — é um hábito contínuo. Para uma oportunidade específica, ciclos de duas a quatro semanas costumam bastar para testar o maior risco com protótipo ou experimento. Se o discovery de uma única ideia passa de um mês, provavelmente o escopo da pergunta está grande demais.
Quem participa do product discovery?
O trio de produto: product manager, designer e pelo menos um engenheiro. Engenheiro no discovery não é custo extra — é como o risco de viabilidade é testado cedo e como o time inteiro desenvolve empatia real pelo usuário, em vez de receber relatórios de segunda mão.
Discovery contínuo funciona em empresas pequenas?
Funciona melhor ainda, porque a distância até o usuário é menor. O custo mínimo é uma conversa por semana e um protótipo simples. O que não escala é a ausência de discovery: quanto menor a empresa, mais caro é construir a coisa errada.
Artigos relacionados
- Área de experimentação de produto
- UX research e CRO: do comportamento ao experimento
- Pesquisa de conversão: o modelo ResearchXL
- Guia de pesquisa
- IA em pesquisa qualitativa e UX research
- Product Management: o que é gestão de produtos digitais
- Product Analytics: métricas e ferramentas para entender o uso do produto
Quer discutir discovery, experimentação e CRO com outros profissionais brasileiros? Participe da comunidade CRO Brasil.