Discovery de produto para fundador não-técnico: o que vale, o que não, e como fazer em quatro semanas

Uma fundadora que conhecemos pagou R$ 82 mil por “discovery de produto” no fim de 2024. A entrega foi um Notion de 64 páginas com personas, jornadas, hipóteses, mapas de empatia e três workshops gravados. Tudo bem feito, no padrão dos cursos de produto. Quatro meses depois, ela ainda não tinha software, não tinha escopo, não tinha decisão. Tinha um relatório.

Discovery de produto, em uma linha, é o trabalho de transformar uma intuição de oportunidade em uma decisão de construir, com escopo, custo e prazo defensáveis. Para um time de produto maduro, isso é uma prática contínua de pesquisa e validação. Para um fundador não-técnico que ainda não construiu nada, é outra coisa: é a diligência mínima que separa um briefing sério de um cheque assinado no escuro. Os artigos que dominam essa busca no Google ensinam a primeira versão. A segunda, que é a sua, ninguém escreve.

Este texto é sobre a versão de discovery que serve para o seu caso. Mais curta, mais estreita, e que termina com uma decisão, não com um documento.

Discovery não é pesquisa, é diligência

A palavra “discovery” carrega um problema de tradução cultural. No léxico americano de produto, ela vem do mundo de PMs sêniores em empresas grandes, onde o tempo gasto explorando um problema é justificado pela escala da decisão de roadmap que vem depois. Quando você é fundador não-técnico e ainda não construiu nada, sua decisão não é “qual feature priorizar no Q3”. Sua decisão é “vale construir alguma coisa, com qual escopo, e com qual orçamento”. Isso é diligência, não pesquisa.

Diligência tem critérios objetivos. Pesquisa tem perguntas abertas. As duas se parecem nas primeiras semanas. A diferença aparece quando você tenta encerrar.

A versão que vamos descrever neste artigo é, de fato, um subconjunto disciplinado do que os frameworks tradicionais (Marty Cagan, Teresa Torres, Jeff Patton) ensinam. É a parte que paga aluguel para o seu estágio. O resto, em geral, vai te custar tempo que você não tem.

Onde o discovery típico falha para fundadores

O modelo padrão assume três coisas que o fundador não-técnico não tem: um time multidisciplinar, um produto rodando, e dezenas de usuários disponíveis para entrevista contínua. Tirar essas três premissas do framework e tentar aplicá-lo do mesmo jeito é como pedir para um cardiologista tratar um paciente sem nenhum exame de imagem. Ele continua dando palpites bons, mas perde a ferramenta principal.

As três falhas que vimos repetidas em muitos founders:

A primeira é o discovery sem prazo. Sem deadline rígido, discovery vira o melhor projeto da sua vida. Você sempre encontra mais uma entrevista, mais uma hipótese para validar, mais uma pesquisa de mercado que parece útil. O mês vira três, três viram seis. O capital queima e o software não nasce.

A segunda é o discovery acadêmico. O fundador, geralmente alguém com formação em consultoria ou finanças, gosta de frameworks. Ele ou ela aprende sobre Jobs to Be Done, Double Diamond, Design Thinking, Lean UX e quer aplicar todos. O resultado é um trabalho que parece de mestrado em produto e não responde a pergunta básica: dá para construir, com quem, por quanto, em quanto tempo.

A terceira, e a mais cara, é o discovery sem usuário real. Founders ficam tentados a fazer toda a “pesquisa” com colegas, mentores, e investidores. Essa gente é generosa com opinião e econômica com a verdade. O que eles te dizem em uma chamada de 30 minutos não é o que um cliente real pagaria para resolver. Discovery de fundador exige conversa com pelo menos cinco pessoas que se encaixam exatamente no seu ICP, fora do seu círculo, que não te devem nada.

As cinco perguntas que toda discovery de fundador responde

Em vez de adotar um framework de produto traduzido, propomos cinco perguntas. Elas são pequenas, mas se você não conseguir responder cada uma com uma frase concreta, você ainda não terminou.

1. Quem é a pessoa específica que vai pagar, e por que ela paga hoje pelo problema (mesmo que mal)? Se você não consegue dizer “ela paga R$X por Y, hoje, com a solução Z”, você ainda está com uma hipótese de mercado, não com um cliente. Isso vale para B2B e B2C.

2. Qual é a fricção que ela tolera porque não tem alternativa? O software que vale construir resolve uma fricção real. Não a que ela menciona em primeiro lugar (que é geralmente preço), mas a que aparece quando você pergunta “como você faz isso hoje” e ouve a descrição de um processo manual que ninguém deveria estar fazendo em 2026.

3. Qual é o escopo mínimo que troca um workflow manual por um workflow automatizado, ponta a ponta, para um único caso de uso? Atenção à palavra “ponta a ponta”. Metade do software que fundadores compram resolve só o pedaço bonito do problema e empurra o resto para uma planilha. Isso não é produto, é demo.

4. Qual é a evidência de que sua versão é diferente o suficiente para alguém pagar? Diferente em quê: preço, integração, fluxo, dados, contexto local. Se a sua resposta é “design melhor”, você ainda está procurando. Design melhor sozinho quase nunca é um wedge defensável.

5. Qual é a maior coisa que pode dar errado, e como você saberia em quatro semanas que deu? Toda construção é uma aposta. Discovery termina quando você tem uma hipótese que pode ser falsificada rapidamente, e um plano explícito de como testá-la depois que o código existir.

Se você responder essas cinco em uma página, você terminou. Se você responder em vinte, você fez o discovery errado.

A discovery de quatro semanas: cronograma honesto

Não conhecemos um único bom discovery de fundador que tenha demorado mais que quatro semanas em tempo dedicado. Conhecemos vários que esticaram em tempo total porque o fundador estava acumulando com outras coisas, mas o “tempo focado” raramente passa de um mês útil.

Aqui está o cronograma que recomendamos para um fundador não-técnico que ainda não construiu nada:

Semana 1: Mapa do território. Você desenha o problema com o vocabulário dos seus futuros clientes (não com o seu vocabulário acadêmico de fundador). Lista explicitamente quem são as pessoas que vivem esse problema hoje. Faz cinco a oito conversas curtas (30 minutos), gravadas e transcritas, com pessoas que você não conhece pessoalmente. Pergunta como elas resolvem hoje, quanto pagariam, e o que elas chamaram de “tentei e não funcionou”.

Semana 2: Caso de uso ponta a ponta. Você pega um único caso real de uma das pessoas que entrevistou e desenha o fluxo dela completo, do disparo do problema até a saída desejada. Em papel, em Miro, em Excel, tanto faz. O critério é: alguém que nunca ouviu falar do seu produto consegue ler esse fluxo e descrever o que o software faria. Isso já te força a cortar 40% do que você imaginava no início.

Semana 3: Spec de uma página. Tradução do fluxo em uma especificação curta que descreve o que o software faz, quais decisões automatiza, quais decisões empurra para o usuário, e quais integrações precisa ter para não quebrar no primeiro mês. Essa spec é o documento que vira a base da especificação de produto que você vai entregar para o desenvolvedor.

Semana 4: Diligência comercial. Você usa essa spec para conversar com duas ou três software houses, um freelancer sênior, e (se fizer sentido) um candidato a primeiro dev interno. Não para contratar. Para validar três coisas: o escopo é claro o suficiente para receber um orçamento sério, o orçamento bate com a sua matriz de custo, e o cronograma é compatível com o tempo que você tem antes da próxima janela comercial.

Quatro semanas. Cinco perguntas respondidas. Uma spec de uma página. Três cotações comparáveis. Você não terminou um Notion de 64 páginas, terminou uma decisão.

O entregável: uma especificação que faz o software house parar de te enganar

A maior virtude do discovery curto é o que sai dele. Não é uma apresentação. Não é um relatório. É uma página densa que descreve, no nível de detalhe correto, o que o software vai fazer.

Essa especificação tem quatro blocos, e nada mais:

O objetivo de negócio em duas linhas. Se você gastar mais que isso, você ainda não convergiu.

O caso de uso primário descrito como uma jornada de cinco a oito passos, do gatilho até o resultado. Você pode escrever esse bloco como bullets de comportamento (“o usuário cola o link”, “o sistema valida”, “o sistema pergunta”, “o sistema executa”, “o sistema notifica”). Sem decoração, sem visualização.

As decisões técnicas que o fundador toma, e as que delega. Existem três ou quatro decisões que afetam o orçamento e que o fundador precisa ser capaz de defender (multi-tenant ou não, integração crítica X ou Y, mobile-first ou web-first, dados sensíveis sob LGPD ou não). O resto, você delega para quem vai construir.

As três coisas que ficam fora do escopo da v1. Discovery bem-feito é tanto sobre o que entra quanto sobre o que fica de fora. Quando você nomeia explicitamente o que está cortando, você corta de verdade. Quando você não nomeia, o software house reabre a conversa quando o orçamento começa a apertar.

Esse documento de uma página é o que diferencia um briefing que um software house pode tabelar de um briefing que vira um contrato T&M sem teto. É o filtro contra orçamento inflado: quando o escopo está claro, fica óbvio quando o número é cobrança honesta e quando é gordura.

Quando você está terminando discovery, e quando está procrastinando

A linha entre “ainda não terminei” e “estou usando discovery para adiar a decisão” é fina. Para a maioria dos fundadores não-técnicos, ela passa por aqui:

Se você está há mais de quatro semanas dedicadas em discovery, você não está mais validando, está adiando. Discovery não fica melhor com mais tempo depois de um ponto. Fica mais redundante. Cada nova entrevista confirma o que as três anteriores já disseram, ou contradiz uma coisa específica que você consegue resolver com uma decisão pequena, não com mais um mês de pesquisa.

Se você não consegue escrever a sua spec de uma página sem voltar para “depende do feedback dos usuários”, você está num loop de validação que não vai terminar sozinho. Spec é o resultado da síntese, não da pesquisa contínua. Em algum momento você fecha o caderno e escreve.

Se você ainda não conversou com nenhuma software house, freelancer, ou candidato a dev por dentro do seu material, você está fazendo só metade do discovery. A diligência técnica e comercial é o que valida que sua spec é construível dentro do orçamento e do tempo. Pular essa parte é como aprovar um plano de viagem sem checar se existe avião para o destino.

E a primeira pergunta da PAA: o que é discovery de produto, então?

Em uma frase: é o trabalho de transformar uma intuição de oportunidade em uma decisão de construir, com escopo, custo e prazo defensáveis. Para um fundador não-técnico, é um exercício de diligência feito em quatro semanas, ancorado em cinco perguntas, com uma spec de uma página como saída.

Não é workshop. Não é hipótese empilhada em hipótese. Não é mapa de empatia. Essas ferramentas existem, são úteis em outras situações, e podem aparecer pontualmente dentro do seu discovery. Não devem ser o discovery.

E as quatro fases do produto?

A PAA pergunta isso porque a internet brasileira de produto fala muito em “ciclo do produto”. Para o fundador, as quatro fases que importam são, em ordem honesta: discovery (você está aqui), decisão de construir, primeira versão real no ar, e iteração com clientes pagantes. A escolha de ferramentas e abordagens dentro da terceira fase só faz sentido depois que a fase 1 entregou uma decisão.

A fase em que a maioria dos fundadores não-técnicos trava é entre 1 e 2. Discovery termina quando você tem evidência suficiente para tomar uma decisão de construir. Se você ainda está coletando evidência, você não saiu de 1.

Como saber que terminou: o teste do envelope

Se um cliente em potencial entrasse na sua sala agora, e você precisasse explicar em três minutos o que vai construir, para quem, com qual diferença, em quanto tempo, e por quanto, você conseguiria? Sem slides, sem Notion, sem voltar atrás para “depende”.

Se sim, você terminou discovery. Pode parar de pesquisar e começar a construir.

Se não, você ainda tem trabalho. Mas o trabalho é fechar uma das cinco perguntas, não recomeçar todas.

Discovery de fundador não é a parte glamourosa do trabalho. Mas é a única parte em que cinco horas de honestidade brutal valem mais que cinquenta horas de framework. A diferença entre os fundadores que constroem e os que ficam em discovery por nove meses geralmente é só essa: os primeiros sabem encerrar.