Experiment board: como unir discovery de mercado e viabilidade técnica em 6 hipóteses antes de escrever código

Um experiment board é um quadro operacional para registrar hipóteses, experimentos, evidências e decisões ao longo do ciclo de produto. Quando aplicado antes da primeira linha de código, o experiment board evita que a equipe trate uma ideia promissora como se já fosse uma oportunidade comprovada.

O problema aparece quando discovery de mercado e análise técnica acontecem em silos. Vendas entrevista clientes, produto desenha jornadas e engenharia estima funcionalidades, mas ninguém reúne essas descobertas em uma única decisão. O resultado costuma ser um MVP tecnicamente viável, porém sem comprador, ou uma demanda real que depende de dados, integrações e requisitos impossíveis para o orçamento disponível.

Um quadro bem estruturado transforma incertezas em perguntas testáveis. Em vez de escrever “empresas precisam de uma plataforma de automação”, você registra: “gestores de operações em empresas com mais de 200 funcionários pagarão por uma automação que reduza o tempo de conferência de pedidos em 30%”.

A diferença é prática. A primeira frase gera backlog; a segunda define público, problema, benefício, indicador e comportamento esperado. O discovery de mercado antes de uma linha de código ajuda a entender o problema, enquanto a análise de viabilidade técnica verifica se a promessa pode ser entregue com dados, arquitetura e operação compatíveis.

Esse método é especialmente útil em produtos B2B, soluções de IA, IoT, saúde, fintech e govtech. Nesses contextos, uma decisão errada não custa apenas algumas semanas de desenvolvimento. Ela pode envolver contratos, integrações com SAP ou ERP, aprovação jurídica, requisitos de segurança, dados sensíveis e compromissos assumidos em projetos apoiados por FAPESC, FINEP ou BNDES.

Um quadro útil não tenta validar tudo ao mesmo tempo. Ele prioriza as incertezas capazes de matar o produto. A seguir está uma sequência de seis hipóteses que pode ser adaptada para um SaaS, uma solução de IA, um produto industrial conectado ou uma aplicação corporativa.

Hipótese 1: o problema é frequente, caro e prioritário. Converse com usuários, gestores e compradores, mas peça exemplos concretos do processo atual. Uma dor relevante costuma aparecer em retrabalho, multas, horas manuais, perda de receita, risco operacional ou atraso de decisões. O artefato mínimo é uma matriz com frequência, impacto, solução atual e orçamento potencial.

O teste não é perguntar “você usaria este produto?”. Essa pergunta produz respostas gentis e pouco confiáveis. Pergunte quando o problema aconteceu pela última vez, como foi resolvido, quem aprovou o gasto e o que aconteceria se nada mudasse nos próximos seis meses.

Hipótese 2: existe um comprador identificável e um caminho de compra possível. Em empresas B2B, usuário, influenciador, área técnica, jurídico e decisor financeiro podem ter critérios diferentes. Mapeie o buying center e confirme se alguém tem autoridade, orçamento e urgência para patrocinar a mudança.

Um sinal mais forte que elogios é o compromisso concreto: apresentar o responsável pelo orçamento, compartilhar requisitos, aceitar um piloto pago ou reservar uma data para avaliação. Para organizar as entrevistas, use um roteiro de discovery para buying centers B2B.

Hipótese 3: a proposta de valor é compreendida sem explicação excessiva. Mostre um fluxo simples, um protótipo de baixa fidelidade ou uma simulação do antes e depois. Observe se a pessoa identifica o problema, entende o resultado e consegue explicar quem usaria a solução.

Meça comportamentos, não entusiasmo. Uma hipótese pode ser considerada promissora quando os entrevistados repetem o benefício com suas próprias palavras, reconhecem a jornada atual e aceitam uma próxima etapa. Em produtos com IA, teste também confiança, necessidade de revisão humana e tolerância a erros.

Hipótese 4: os dados e integrações necessários existem. A solução pode depender de ERP, SAP, sensores, documentos, imagens, APIs ou históricos que o cliente não consegue acessar. Antes de programar, faça um inventário de fontes, proprietários, formatos, frequência de atualização, qualidade e permissões.

O artefato mínimo é um mapa de dados com amostras anonimizadas, contrato de integração ou resposta documentada da API. Se o produto depender de um sistema legado, uma chamada real em ambiente seguro pode revelar mais que semanas de estimativas. Para cenários B2B, veja como usar integrações com ERP e Power BI para provar demanda antes de construir um MVP.

Hipótese 5: a solução atende aos requisitos técnicos críticos. Aqui entra o arquiteto ou engenheiro sênior. A pergunta não é se a equipe consegue criar uma demonstração, mas se consegue entregar o resultado com latência, segurança, disponibilidade, custo operacional e capacidade de manutenção compatíveis com o negócio.

Os testes variam conforme o produto. Podem incluir uma prova de conceito de classificação, um teste de carga, uma simulação de dispositivo IoT, um protótipo offline-first ou uma avaliação de autenticação. Em IA, registre qualidade do modelo, custo por operação, tratamento de dados sensíveis, explicabilidade e possibilidade de revisão ou reversão. O NIST AI Risk Management Framework oferece uma referência pública para organizar riscos de sistemas de inteligência artificial.

Hipótese 6: o modelo econômico e operacional fecha. Uma solução pode resolver uma dor real e ainda assim não ser sustentável. Estime quem paga, quanto custa servir cada cliente, qual esforço de implantação é necessário e se o suporte depende de trabalho manual que não escala.

Teste uma faixa de preço, um formato de piloto ou uma proposta de serviço antes de construir cobrança, multitenancy e automações completas. Em projetos financiados, compare também o que precisa ser entregue, medido e comprovado no cronograma, sem confundir recurso disponível com demanda de mercado.

A viabilidade técnica não exige um produto completo, mas exige evidência suficiente para reduzir as principais incógnitas. O primeiro artefato costuma ser um diagrama de contexto: usuários, sistemas externos, dados que entram, processamento e resultado entregue. Ele revela dependências ocultas e ajuda a separar o essencial do desejável.

O segundo é uma prova técnica estreita. Para uma solução de IA, pode ser uma avaliação com conjunto de dados representativo e critérios de erro definidos. Para IoT, pode ser uma simulação de telemetria e conectividade. Para AR ou VR, pode ser um teste de interação com o dispositivo escolhido. Para um SaaS, pode ser uma integração controlada com o ERP do cliente.

O terceiro artefato é uma lista de requisitos não funcionais. Inclua latência máxima, disponibilidade esperada, volume de dados, autenticação, autorização, auditoria, privacidade, recuperação de falhas e custo de infraestrutura. O checklist de requisitos não funcionais para MVPs B2B ajuda a evitar que esses critérios apareçam somente quando o piloto já foi vendido.

O quarto é uma estimativa por faixas, não uma promessa de prazo exato. Registre o que é conhecido, o que depende de terceiros e quais descobertas podem alterar o escopo. Um arquiteto experiente deve explicitar premissas e riscos, em vez de esconder incerteza atrás de uma quantidade precisa de horas.

Em produtos regulados, acrescente uma análise inicial de dados pessoais, retenção, consentimento e controles de acesso. A Autoridade Nacional de Proteção de Dados mantém orientações oficiais que ajudam a estruturar perguntas sobre proteção de dados, embora a avaliação jurídica específica continue sendo necessária.

Por fim, produza um registro de decisão. Ele deve mostrar a hipótese original, evidências coletadas, riscos remanescentes, alternativa considerada e recomendação. Esse documento é útil para o time, para investidores e também para projetos de inovação que precisam demonstrar por que determinado caminho foi escolhido.

O primeiro erro é preencher o quadro com funcionalidades. “Criar painel”, “integrar chatbot” e “adicionar aplicativo móvel” são soluções, não hipóteses. Reescreva cada item como uma crença sobre comportamento, valor ou restrição que possa ser testada.

Outro problema é entrevistar apenas usuários entusiasmados ou contatos próximos. Fundadores tendem a ouvir o segmento que já concorda com a tese. Inclua perfis que não comprariam, decisores financeiros e pessoas que usam a alternativa atual, mesmo que ela seja uma planilha ou um processo manual.

Também é comum validar mercado sem validar operação. Um cliente pode querer o resultado, mas não conseguir fornecer os dados, aprovar o acesso ou mudar seu processo interno. É por isso que entrevistas e provas técnicas devem ocorrer em paralelo nas hipóteses de maior risco.

A equipe pode ainda escolher experimentos sofisticados demais. Treinar um modelo próprio, construir uma arquitetura distribuída ou desenvolver um aplicativo completo antes de confirmar a dor aumenta custo sem necessariamente aumentar conhecimento. Comece pela menor prova que pode derrubar a hipótese.

Por fim, não confunda atividade com aprendizado. O número de entrevistas, telas desenhadas ou testes executados não prova avanço. O indicador correto é a qualidade da decisão: qual incerteza foi reduzida, qual premissa mudou e qual investimento deixou de ser necessário.

Uma boa referência operacional é manter o quadro vivo por ciclos curtos, revisando hipóteses semanalmente durante o discovery. Quando o projeto avançar para o MVP, o guia sobre quando pausar, pivotar ou avançar ajuda a preservar a disciplina de decisão.