Product discovery: como descobrir o que vale construir

Product discovery é o trabalho de descobrir o que vale a pena construir antes de construir. Ele responde quatro perguntas, nessa ordem: qual problema existe, de quem é esse problema, se resolvê-lo gera valor suficiente para alguém pagar, e se a solução imaginada é possível dentro do que a empresa tem. Só depois disso a construção começa.

Este guia é escrito para quem decide investir: fundador, diretor, dono de operação que enxergou um produto dentro da própria empresa. Não é um catálogo de frameworks. É o processo que reduz a chance de gastar seis meses construindo algo que ninguém usa, com os métodos que cabem em uma empresa que não tem time de pesquisa, e com o recorte que quase nenhum material trata: o discovery de quem já tem dado e ferramenta interna funcionando.

O que é product discovery

Product discovery é a fase em que se investiga o problema e se testam hipóteses de solução, com o objetivo de reduzir incerteza antes de comprometer orçamento com construção. É investigação com prazo e critério de parada, e não pesquisa acadêmica: o resultado esperado é uma decisão fundamentada sobre o que construir primeiro.

Vale separar dois termos que costumam ser usados como sinônimo. Discovery decide o que construir. Delivery constrói. Empresas que pulam o primeiro não economizam tempo: transferem o custo do erro para a fase mais cara, que é a de escrever código. Descobrir na semana três que o problema era outro custa uma conversa. Descobrir no mês seis custa o projeto inteiro.

Também vale dizer o que discovery não é. Não é reunião de brainstorm com post-it. Não é o fundador entrevistando dez pessoas que concordam com ele. E não é uma fase que termina para sempre: em produto que já existe, o discovery é contínuo, acontecendo em paralelo com a construção, só que sobre a próxima decisão.

Por que a maioria dos produtos morre antes de nascer

Produto digital falha por três motivos, e apenas um deles é técnico. O primeiro é resolver um problema que ninguém tem com urgência suficiente para mudar de comportamento. O segundo é resolver um problema real de um jeito que o usuário não adota, porque exige esforço maior que o incômodo original. O terceiro é construir algo que funciona e que a empresa não consegue vender pelo que custa entregar.

O padrão comum aos três é o mesmo: a hipótese só foi testada depois de pronta. A pergunta que a empresa fez foi “conseguimos construir isso?”, e a resposta quase sempre é sim. A pergunta que faltou foi “alguém muda o que faz hoje por causa disso?”, que é bem mais difícil de responder e infinitamente mais barata de errar antes.

Existe uma armadilha específica para quem já tem empresa: a familiaridade com o próprio setor cria a sensação de que o problema é óbvio e conhecido. É comum descobrir, na primeira rodada de conversas, que o problema que incomoda o dono não é o que incomoda quem faria o trabalho na ponta.

As quatro perguntas que ele responde

A ordem importa. Empresa técnica costuma começar pela quarta pergunta, porque é a mais confortável de responder. Empresa comercial costuma começar pela terceira. As duas primeiras são as que decidem o resultado, e são justamente as que exigem sair da sala e conversar com quem tem o problema.

O processo, em cinco etapas

Discovery não precisa de cerimônia. Precisa de sequência, prazo e registro do que foi aprendido. Cinco etapas cobrem o caso de uma empresa que quer decidir se constrói.

• 1. Enquadrar o problema. Escrever em uma frase qual incômodo se pretende resolver, de quem, e o que essa pessoa faz hoje na ausência de solução. Se ninguém faz nada hoje, o problema provavelmente não dói o bastante.
• 2. Investigar com quem vive o problema. De oito a doze conversas com pessoas do perfil, focadas em comportamento passado e não em opinião sobre o futuro.
• 3. Olhar o dado que já existe. Registros de atendimento, planilhas de contorno, tempo gasto, taxa de erro. Empresa em operação costuma ter mais evidência do que imagina.
• 4. Testar a solução no menor formato possível. Protótipo clicável, planilha operada à mão, página que descreve a oferta. O objetivo é observar reação real, e não coletar aprovação.
• 5. Decidir e registrar. Construir, adiar ou descartar, com o motivo escrito. A decisão de não construir é resultado válido, e barato.

A etapa dois é a que costuma ser mal executada. A regra que mais melhora a qualidade das conversas é simples: pergunte sobre a última vez que a pessoa enfrentou o problema, e peça que ela conte o que fez. Comportamento relatado é evidência; intenção declarada é ruído.

Os métodos que cabem numa empresa pequena

O último merece atenção porque é o mais subestimado. Antes de construir o sistema que faz X automaticamente, faça X à mão para dez clientes. Se ninguém quiser mesmo assim, o software não mudaria nada. Se todos quiserem, você aprendeu as regras de verdade, incluindo as exceções que nenhum levantamento teria capturado.

Como conduzir uma entrevista de problema

A entrevista é o método mais barato e o mais fácil de executar mal. A diferença entre uma conversa que ensina e uma que confirma o que você já pensava está em três decisões: com quem falar, o que perguntar e o que fazer com o silêncio.

Com quem falar. De oito a doze pessoas do perfil que você suspeita ter o problema, incluindo pelo menos duas que resolveram o problema de outro jeito e uma que decidiu conviver com ele. Quem já contratou uma alternativa é a fonte mais rica que existe, porque a decisão de compra dela já aconteceu e pode ser reconstruída.

O que perguntar. Quatro perguntas sustentam a conversa inteira, e nenhuma delas menciona a sua solução.

• Conte da última vez que isso aconteceu. Data, contexto, o que veio antes e o que veio depois.
• O que você fez? O contorno atual, com os passos e as pessoas envolvidas.
• Quanto isso custou? Em tempo, dinheiro, retrabalho ou desgaste com cliente.
• Você já tentou resolver de outro jeito? O que testou, por que abandonou, quanto pagou.

O que fazer com o silêncio. A resposta mais valiosa costuma vir depois de uma pausa desconfortável. Resista à tentação de completar a frase da pessoa ou de oferecer a alternativa que você já imaginou: no momento em que a sua ideia entra na conversa, a pessoa passa a reagir a ela em vez de descrever a realidade dela.

Uma última regra que economiza semanas: pare quando as conversas começarem a se repetir. A partir da oitava ou nona entrevista, se nada novo aparece, o padrão já se formou, e mais conversas só adiam a decisão. Se, ao contrário, cada pessoa traz um problema diferente, o recorte de público ainda está largo demais, e esse é um resultado tão útil quanto qualquer outro.

Discovery guiado por dado

Empresa em operação chega ao discovery com uma vantagem que startup nenhuma tem: histórico. Antes de qualquer entrevista, vale extrair do que já existe as respostas que o dado dá sozinho.

• Onde o processo trava. Tempo entre etapas, retrabalho, pedido devolvido. Isso aponta o problema com números, não com impressão.
• O que as pessoas pedem repetidamente. Registro de atendimento e chamados são a lista de dores ordenada por frequência.
• Quem já paga por um contorno. Planilha mantida à mão, ferramenta contratada por uma área, hora extra recorrente. Contorno pago é a evidência mais forte que existe.
• Quanto custa o problema hoje. Horas por mês vezes o custo da hora. É esse número que vai justificar o investimento adiante.

Esse levantamento costuma exigir que o dado esteja minimamente organizado, e é aí que discovery encosta em governança de dados e em dashboard de vendas. Quando o dado está espalhado demais para responder qualquer coisa, o próprio diagnóstico vira o primeiro projeto, com o caminho descrito em inteligência de dados para pequenas empresas.

O caso da ferramenta interna que quer virar produto

Existe um discovery diferente de todos os outros: o da empresa que construiu uma ferramenta para uso próprio, viu que ela funciona, e agora se pergunta se aquilo é um produto vendável. A boa notícia é que metade das perguntas já está respondida. A má é que a metade restante é a difícil.

O que já está provado: o problema existe, porque você o tinha; a solução funciona, porque você a usa; e as regras estão corretas, porque a operação depende delas. O que ainda não está provado é se o problema existe fora da sua empresa do mesmo jeito, e é aí que a maioria dos casos falha. Ferramenta interna carrega o processo particular de quem a construiu, e o que parece regra do setor com frequência é decisão da casa.

Nesse cenário, o discovery tem três tarefas específicas. Descobrir quanto do que existe é genérico e quanto é seu. Confirmar com empresas parecidas que o incômodo é o mesmo, e com que gravidade. E entender se elas comprariam software ou se resolveriam contratando alguém, que é a alternativa real na maior parte dos casos. Os critérios completos dessa avaliação estão em quando a ferramenta interna tem potencial de produto e em da ferramenta interna à receita.

Como saber que o discovery terminou

Discovery sem critério de parada vira eterna pesquisa, e pesquisa eterna é uma forma elegante de adiar decisão. Quatro condições encerram a fase.

• Você consegue descrever o usuário em uma frase específica. Não “clínicas”, mas “clínica de duas a cinco salas, sem gestor administrativo dedicado”.
• Você sabe o que ele faz hoje sem o produto. E quanto isso custa a ele, em tempo ou dinheiro.
• Existe evidência de disposição, não de simpatia. Alguém se comprometeu com algo: tempo, piloto, pagamento antecipado, lista de espera.
• A primeira versão cabe em um escopo pequeno e defensável. Se ainda parece que precisa de tudo para funcionar, o recorte não amadureceu.

Com as quatro respondidas, o passo seguinte é delimitar o que entra na primeira versão, e o método está em como definir o escopo de um produto digital e em o que é um MVP. A partir daí, a construção passa a ser conduzida por roadmap de produto.

Quanto tempo e quanto custa

Um discovery de decisão, para uma empresa que quer saber se constrói, cabe em duas a seis semanas. Menos que isso costuma significar conversas insuficientes; mais que isso costuma significar que ninguém está disposto a decidir.

O custo tem duas naturezas. Existe o custo direto, que é tempo de quem conduz, algumas horas de design para protótipo e, eventualmente, um investimento pequeno em mídia para teste de demanda. E existe o custo de oportunidade, que é o único argumento normalmente usado contra a fase: são semanas em que nada está sendo construído.

A comparação honesta não é entre discovery e começar logo. É entre semanas de investigação e meses de construção na direção errada. Em ordem de grandeza, o discovery costuma custar uma fração pequena do que custa a primeira versão de um produto, cujas faixas estão em quanto custa desenvolver um produto digital e, no recorte de aplicativo, em quanto custa desenvolver um aplicativo.

Sobre quem conduz, há uma escolha com consequência. Discovery feito por dentro é mais barato e conhece o contexto, e carrega o viés de quem já decidiu que a ideia é boa. Discovery conduzido de fora custa mais e faz as perguntas que ninguém dentro da empresa faz em voz alta, porque não tem nada a perder com a resposta. O arranjo que costuma funcionar melhor é misto: alguém de fora conduz as conversas e o registro, e alguém de dentro participa de todas, porque o aprendizado precisa ficar na empresa depois que o trabalho termina.

Os erros que mais custam caro

• Entrevistar quem concorda com você. Sócio, amigo e cliente fiel confirmam a hipótese e não testam nada.
• Perguntar sobre o futuro. “Você usaria?” é uma pergunta cuja resposta educada é sempre sim.
• Apresentar a solução antes de entender o problema. A partir do momento em que a tela aparece, a conversa vira crítica de tela.
• Confundir elogio com demanda. Interesse verdadeiro se manifesta em compromisso, mesmo pequeno.
• Fazer discovery só com quem decide a compra. Quem assina o contrato e quem usa a ferramenta costumam ter problemas diferentes, e o produto precisa dos dois.
• Terminar sem escrever nada. Aprendizado que mora na cabeça de uma pessoa some na primeira mudança de time.
• Tratar como fase única. Produto vivo continua descobrindo; discovery encerrado para sempre é produto que parou de aprender.

Como registrar o que foi decidido

O produto do discovery é um documento curto, de uma a duas páginas, que qualquer pessoa da empresa consiga ler. Ele tem seis blocos, e não precisa de ferramenta nenhuma além de um editor de texto.

Esse documento tem uma função que só aparece meses depois: quando o projeto estiver em andamento e alguém propuser uma mudança grande de rumo, ele é o registro do que se sabia e do que se decidiu. Sem ele, cada nova opinião parece tão fundamentada quanto a decisão original.

Para o passo seguinte à decisão de construir, a leitura é validação de MVP e desenvolvimento de software. Para entender antes se o que existe na empresa é produto ou operação, vale produto digital e negócio digital e o produto digital escondido na sua empresa. E quando a pergunta for como o produto vai se pagar, os caminhos estão em modelos de monetização digital.

Perguntas frequentes