Discovery de produto: o que ele entrega antes do código do MVP

Quase todo material sobre discovery de produto começa pelo mesmo lugar: a definição, os benefícios e uma lista de técnicas, de personas a Lean Canvas, de mapa de empatia a protótipo. É um conteúdo útil para quem vai conduzir o processo. Para quem vai pagar por ele, fica faltando a parte que interessa.

Quem contrata um discovery antes de um MVP precisa saber três coisas que raramente aparecem escritas: o que estará na mesa no último dia, quanto tempo aquilo deve durar e qual regra decide se o desenvolvimento começa. É disso que este texto trata, a partir de uma moldura conhecida em gestão de produto, os quatro riscos de Marty Cagan, e de uma proposta concreta de entregável: uma folha de saída.

O que é discovery de produto?

Discovery de produto é a etapa em que a empresa descobre o que vale a pena construir antes de construir. Ela troca suposições por evidências: conversa com quem teria o problema, testa a solução em forma barata (roteiro, protótipo, simulação), verifica se a parte técnica mais incerta é possível e confere se a conta do negócio fecha.

O ponto que costuma se perder é que discovery não é uma fase de documentação. Não se mede pelo número de personas desenhadas nem pela espessura do relatório. Mede-se pelo que ele permitiu decidir: quais hipóteses ficaram de pé, quais caíram e o que, por consequência, entra e não entra na primeira versão do produto.

Em inglês o termo é product discovery, e muita gente no Brasil usa assim mesmo. As duas formas descrevem a mesma coisa.

De onde vem a ideia de discovery?

A palavra se popularizou em gestão de produto de software pelo trabalho de Marty Cagan, fundador do Silicon Valley Product Group (SVPG), e de autores próximos a ele. A ideia central é separar dois tipos de trabalho que antes viviam misturados: descobrir o que construir e construir bem o que foi descoberto.

Antes disso, a prática dominante era a de requisitos: alguém da área de negócio escrevia o que queria, a equipe técnica estimava e construía. O problema desse modelo é que as perguntas mais caras, se alguém quer aquilo e se a conta fecha, só eram respondidas depois do lançamento, quando o dinheiro já tinha sido gasto.

O discovery desloca essas perguntas para antes. Não elimina o risco, mas o torna barato: errar num protótipo de papel custa dias; errar num sistema em produção custa meses.

Qual a diferença entre discovery e delivery?

Discovery responde o que construir; delivery constrói. As duas etapas têm perguntas, saídas e métricas diferentes, e confundir uma com a outra é a origem de boa parte dos projetos que entregam no prazo um produto que ninguém usa.

A coluna de inception entra porque a dúvida aparece muito na busca. Inception é um formato de workshop, popularizado em consultorias de software ágil, para alinhar visão e escopo inicial em poucos dias. Ele pode ser o pontapé de um discovery, mas não o substitui: alinhar o que a equipe acredita não é o mesmo que testar se aquilo é verdade com quem vai usar.

Na prática madura, discovery e delivery correm em paralelo depois que o produto existe. É o que se chama de dual track: uma trilha segue testando as próximas apostas enquanto a outra entrega as que já foram validadas. Antes do primeiro MVP, porém, o discovery vem primeiro, porque ainda não há nada para entregar.

Por que o discovery decide o escopo do MVP?

Porque a principal fonte de desperdício em software não é código malfeito. É código bem feito para uma funcionalidade que ninguém usa. Há um número conhecido sobre isso, e ele precisa ser lido com o ano e o recorte certos.

Dois cuidados com esse dado. Ele é de 2019, não de agora, e não há edição mais recente com o mesmo recorte que permita dizer se o quadro melhorou ou piorou. E a amostra é de empresas de software que já pagam para medir o uso do próprio produto, o que provavelmente as coloca entre as mais atentas do mercado, não entre as mais descuidadas.

Mesmo com essas ressalvas, a direção é clara: a maior parte do que se constrói não é usada. Para um MVP, isso tem uma consequência direta. Cada funcionalidade que entra sem evidência tem mais chance de ser desperdício do que de ser necessária, e o discovery é a etapa em que essa triagem ainda é barata.

É por isso que o produto do discovery não é só a lista do que construir. É, com o mesmo peso, a lista do que não construir agora.

Quais são os quatro riscos que o discovery precisa reduzir?

A moldura mais útil para organizar um discovery é a dos quatro riscos, descrita por Marty Cagan. Ela tem uma vantagem sobre as listas de técnicas: em vez de dizer o que fazer, diz o que precisa estar respondido no fim.

A ordem importa. Valor vem primeiro porque é o risco que mais mata produto e o que menos aparece em reunião interna: todo mundo na sala acredita na ideia, senão ela não estaria na sala. Usabilidade vem em seguida, porque só faz sentido testar se alguém entende a solução depois de saber que alguém quer o resultado dela.

Viabilidade técnica costuma ser o risco que a empresa mais teme e o que menos derruba projetos de MVP, porque a maior parte do que um MVP faz já foi feito antes. Ela pesa de verdade quando há integração com sistema legado, dado sensível ou uso de IA em tarefa em que o erro tem custo.

Viabilidade de negócio é o risco esquecido. Ele pergunta se a solução funciona para quem vende, para o jurídico, para o financeiro e para quem vai atender o cliente depois. Um produto que o usuário adora e que o comercial não consegue vender com margem continua sendo um problema.

Quais técnicas de discovery de produto usar para cada risco?

As técnicas que os guias listam são boas. O erro é aplicá-las todas, em sequência, sem perguntar qual risco cada uma reduz. A tabela abaixo faz a ligação e diz qual evidência costuma ser suficiente para dar o risco como reduzido.

Persona, mapa de empatia e jornada do cliente aparecem em quase todos os guias e não estão na tabela de propósito. São ferramentas de síntese, úteis para organizar o que se aprendeu nas entrevistas, mas não produzem evidência sozinhas. Uma persona escrita sem conversar com ninguém é uma suposição com foto. Sobre isso, vale ler como criar persona sem inventar o cliente.

Design thinking também aparece muito como sinônimo. Ele é uma abordagem mais ampla de resolução de problemas centrada nas pessoas; o discovery de produto usa várias de suas ferramentas, mas tem um alvo mais estreito: decidir o que um produto específico deve fazer e se deve existir.

Como fazer discovery de produto na prática?

Não existe um processo único, e desconfie de quem vende um. Mas há uma sequência que funciona na maior parte dos projetos de MVP e que pode ser ajustada ao tamanho do problema.

1. Escreva as hipóteses antes de pesquisar

Liste o que precisa ser verdade para o produto dar certo, uma hipótese por linha, separadas pelos quatro riscos. Isso parece óbvio e quase nunca é feito. Sem hipóteses escritas, a pesquisa vira coleta de opiniões, e qualquer opinião serve para confirmar o que já se pensava.

2. Ordene pelo que mata o projeto primeiro

Para cada hipótese, pergunte: se ela for falsa, o produto morre ou só muda? As que matam vão para o topo. Em geral, são as de valor. Testar primeiro o que é mais confortável, como a interface, é a forma mais comum de gastar o discovery sem reduzir risco nenhum.

3. Converse com quem teria o problema

Entrevistas sobre o comportamento passado, não sobre intenção futura. “Como você resolveu isso da última vez?” informa; “Você usaria um aplicativo que…?” induz. Pare quando as respostas começarem a se repetir, não quando atingir um número redondo.

4. Teste a solução na forma mais barata possível

Um roteiro, um protótipo clicável, uma página de cadastro, uma operação manual disfarçada de sistema. O formato depende do risco: para usabilidade, protótipo; para valor, algo que peça um compromisso real. O post sobre teste de usabilidade em rodadas curtas detalha a parte de interface.

5. Feche a folha de saída e decida

Cada hipótese recebe a evidência coletada e um veredito. O que ficou de pé define o escopo do MVP; o que caiu sai; o que ficou em aberto vira condição ou novo ciclo curto. E a decisão é tomada por quem paga, não apenas por quem pesquisou.

O que o discovery precisa entregar no fim?

Esta é a lacuna dos guias: nenhum diz que documento a empresa tem na mão no último dia. A proposta da Alliance é que seja uma folha, não um relatório de 60 páginas. Relatório longo é lido por quem o escreveu; uma página é lida por quem decide.

A folha tem quatro partes:

1. Os quatro riscos, cada um com a evidência e o veredito. Reduzido, em aberto ou confirmado como problema. Evidência quer dizer algo observado, não opinião de reunião.
2. O escopo do MVP. O fluxo mínimo que permite testar a hipótese principal, descrito em uma ou duas frases, não em lista de telas.
3. A lista do que fica fora. Cada item cortado com o motivo e o sinal que o traria de volta. É a parte mais valiosa e a mais ignorada, pela razão que o dado da Pendo mostra.
4. A decisão. Vai, ajusta ou não vai, assinada por quem responde pelo orçamento.

A lista do que fica fora merece um parágrafo próprio. Ela protege o MVP da pressão que vem depois, quando alguém lembra de uma funcionalidade “que não pode faltar”. Com a lista escrita, a conversa muda de “por que não tem?” para “qual sinal faria isso entrar?”, e a resposta já está no papel.

O que vem depois da folha é o MVP em si, com o seu próprio contrato de decisão. Esse é outro momento, com outras perguntas: qual métrica, qual piso, qual prazo. Tratamos disso em o critério de parada do produto mínimo viável. O discovery decide o que entra no teste; o critério de parada decide quando o teste terminou.

Quanto tempo dura um discovery?

Não há número de pesquisa que responda isso com honestidade, e a duração depende mais do tamanho da incerteza do que do tamanho do produto. O que dá para dizer é como pensar o prazo.

• O prazo se define antes, como limite, não como estimativa. Discovery sem data tende a crescer até virar pesquisa permanente.
• Ciclos curtos são melhores do que um ciclo longo. Uma ou duas semanas por rodada, com uma folha parcial no fim de cada uma, permitem parar cedo quando o risco de valor já derrubou a ideia.
• B2B costuma demorar mais. Agendar conversa com decisores leva tempo, e a amostra é pequena por natureza. Em compensação, uma carta de intenção vale mais do que dezenas de cadastros.
• Produto com integração ou dado sensível pede prova de conceito. Isso acrescenta tempo, mas é tempo que seria gasto de qualquer forma, só que mais tarde e mais caro.

Na prática da Alliance, um discovery de MVP de escopo moderado costuma caber em algumas semanas. Mas o critério de fim não é o calendário: é a folha estar preenchida com evidência suficiente para uma decisão. Se a resposta chegar antes, ótimo.

Discovery bom não é o que confirma a ideia. É o que deixa claro, cedo e barato, o que ela não precisa ter.

Quais os erros mais comuns no discovery de produto?

• Pesquisar sem hipótese escrita. Sem saber o que se quer refutar, toda entrevista parece confirmar.
• Começar pela interface. Testar telas antes de saber se alguém quer o resultado é polir o que pode não existir.
• Perguntar intenção em vez de comportamento. “Você pagaria?” quase sempre recebe sim. O que alguém já faz para resolver o problema diz mais.
• Ouvir só quem já gosta da empresa. Clientes atuais e conhecidos são gentis demais. Inclua quem não conhece a marca.
• Entregar relatório em vez de decisão. Um documento longo sem veredito devolve a dúvida para quem pagou para resolvê-la.
• Esquecer o risco de negócio. O produto passa em todos os testes com usuário e trava no jurídico, no preço ou na operação.
• Não cortar nada. Se tudo o que foi levantado entra no MVP, o discovery serviu para inflar o escopo, não para reduzi-lo.

Quem deve participar do discovery?

O desenho clássico é um trio: alguém de produto ou de negócio, alguém de design e alguém de tecnologia. Cada um enxerga melhor um dos riscos, e juntos evitam que o discovery vire pesquisa de mercado, exercício de design ou estudo técnico isolado.

Do lado de quem contrata, falta quase sempre uma pessoa: quem vai decidir. Se o dono do orçamento só aparece na apresentação final, a folha de saída chega a alguém que não viu a evidência sendo construída, e a tendência é decidir por intuição de novo. Vale reservar meia hora por ciclo com essa pessoa.

E vale incluir, em algum momento, quem vende e quem atende. São eles que respondem às perguntas do risco de negócio que ninguém mais na sala sabe responder.

Por onde começar hoje

1. Escreva, em uma página, o que precisa ser verdade para o produto dar certo, separado pelos quatro riscos.
2. Marque as hipóteses que, se falsas, matam o projeto. Comece por elas.
3. Agende cinco conversas com pessoas que teriam o problema e não conhecem a sua empresa.
4. Defina a data em que a folha de saída será apresentada e quem decide com base nela.
5. Comece a lista do que fica fora do MVP desde o primeiro dia, e deixe-a crescer.

Se o projeto já está claro e o que falta é transformar a folha em produto, a Alliance faz o desenvolvimento de MVP a partir dela, com o escopo que o discovery deixou de pé. E se a dúvida ainda é anterior, sobre onde o negócio está mais fraco no marketing e na tecnologia, o diagnóstico gratuito de marketing ajuda a enxergar por onde começar.