Discovery técnico vs. discovery de mercado: quando cada um deve acontecer antes de escrever uma linha de código

O discovery de mercado deve vir primeiro quando a maior incerteza está no problema, no público ou no modelo de negócio. Isso ocorre com frequência em startups que têm uma tecnologia promissora, mas ainda não sabem qual segmento sente a dor com mais intensidade ou quem possui orçamento para resolvê-la.

Também é a prioridade quando a solução nasceu de uma hipótese interna, de uma demanda pontual de um cliente ou de uma tendência tecnológica. Um pedido de “aplicativo com inteligência artificial” descreve uma direção, não um problema validado. Antes de escolher modelo, nuvem ou linguagem, você precisa entender qual decisão será melhorada e como o resultado será medido.

Sinais de que o mercado deve ser investigado primeiro incluem ausência de comprador identificado, múltiplos públicos possíveis, preço indefinido, dependência de mudança regulatória e falta de acesso a usuários reais. Se a equipe não consegue listar cinco potenciais entrevistados com contexto semelhante, provavelmente ainda não delimitou o mercado.

A pesquisa deve explorar comportamentos passados, não apenas opiniões futuras. Perguntas como “como você resolve isso hoje?”, “quanto tempo essa alternativa consome?” e “quem aprova a compra?” produzem evidências melhores do que “você usaria este produto?”.

Em vendas B2B, conversar apenas com o usuário final é insuficiente. O usuário pode gostar da ideia, enquanto segurança, compras, jurídico e operações bloqueiam a contratação. O discovery para centros de decisão B2B ajuda a mapear essa cadeia de decisão.

Uma pesquisa de mercado não precisa durar meses. Em uma primeira rodada, de oito a quinze conversas bem selecionadas podem revelar padrões sobre frequência do problema, impacto financeiro, alternativas e barreiras de compra. O resultado não é uma certeza estatística, mas uma decisão melhor sobre qual hipótese testar em seguida.

Uma decisão Go não exige que todas as perguntas estejam respondidas. Ela exige que os riscos mais destrutivos tenham sido reduzidos a um nível compatível com o investimento seguinte. O time deve saber o que ainda é incerto e qual experimento será usado para aprender durante o desenvolvimento.

Avançar faz sentido quando há um problema recorrente, um grupo de compradores acessível, uma jornada inicial compreendida e uma solução técnica plausível. Também é necessário haver uma métrica de resultado, como tempo economizado, redução de erros, aumento de conversão ou diminuição de retrabalho.

Pausar é uma decisão racional quando a evidência de demanda é fraca, o acesso a dados depende de uma autorização indefinida ou o custo técnico não cabe no estágio da empresa. Pausar preserva caixa e permite voltar à hipótese com novas informações. Não é sinônimo de fracasso.

Pivotar significa mudar uma parte central da hipótese, mantendo aprendizados úteis. Uma plataforma criada para automatizar relatórios de operação pode descobrir que o maior valor está em alertas de risco em tempo real. O código inicial talvez seja descartado, mas as entrevistas, critérios e conhecimento do domínio permanecem.

Use um scorecard com escala de 1 a 5 para dor, frequência, urgência, acesso ao comprador, disposição para testar, complexidade técnica e dependências. Não transforme a pontuação em verdade matemática. Ela serve para tornar explícitos os desacordos entre CEO, produto e tecnologia.

Em projetos apoiados por FAPESC, FINEP ou BNDES, o registro deve conectar hipótese, experimento, evidência e entregável previsto. A orientação da FINEP sobre seus instrumentos de apoio à inovação ajuda a compreender que a execução precisa ser compatível com o objetivo aprovado, sem confundir atividade realizada com resultado de negócio.

Um comitê Go/No-Go pode reunir fundador, responsável técnico, produto, comercial e, quando necessário, especialista regulatório. A reunião deve durar o suficiente para revisar evidências, mas não virar uma nova rodada de opiniões sem dados.

Em empresas com backlog extenso, o roteiro híbrido começa por uma triagem das iniciativas. Features que já têm clientes esperando podem exigir uma prova técnica curta; ideias novas, sem comprador definido, devem passar primeiro por entrevistas e prototipação. O objetivo é não tratar todo item do roadmap com o mesmo nível de investigação.

Uma equipe pode organizar um ciclo de duas a quatro semanas. Na primeira, mapeia hipóteses e realiza entrevistas; na segunda, testa protótipos; na terceira, executa spikes técnicos; na quarta, consolida decisões e prepara o backlog com critérios de aceitação. O prazo varia conforme o setor, mas a lógica permanece.

A OrbeSoft aplica essa visão ponta a ponta em projetos de software sob medida, MVPs e produtos com IA, AR/VR ou IoT. A prática combina entrevistas com potenciais compradores, protótipos de baixa fidelidade, análise de concorrência, prova técnica e critérios de Go, No-Go ou Pivot, em vez de assumir que o pedido inicial é o escopo correto.

Essa abordagem é especialmente útil quando há prazo de captação ou edital público. Em mais de 300 projetos realizados na América Latina, nos Estados Unidos e na Europa, a experiência acumulada mostra que a previsibilidade vem de tornar as incertezas visíveis antes de comprometer o time de engenharia.

Para uma empresa financiada, os artefatos também funcionam como memória de governança. Um dossiê com entrevistas, decisões, protótipo, evidências técnicas e backlog priorizado facilita a prestação de contas e a comunicação com investidores, sem prometer que toda hipótese inicial será mantida.

Quando a decisão for avançar, o próximo passo não é necessariamente contratar mais pessoas. Pode ser um projeto fechado com equipe dedicada, uma alocação temporária ou a execução interna de uma parte do trabalho. O playbook para escolher entre squad dedicada, bodyshop e time interno ajuda a conectar a decisão de discovery ao modelo de execução.

O papel do parceiro técnico é questionar premissas com respeito e deixar o time interno mais forte. Na OrbeSoft, a recomendação pode ser construir, reduzir, esperar ou não construir. A qualidade da entrega é medida pela decisão que o trabalho permite tomar, não pela quantidade de código produzido.