Discovery operacional para startups setoriais: do know-how ao MVP

Discovery operacional para startups setoriais é o processo de investigar como o trabalho realmente acontece antes de transformar conhecimento especializado em produto digital. Em vez de começar por uma lista de funcionalidades, você observa decisões, exceções, documentos, sistemas, responsabilidades e improvisos que sustentam a operação diariamente.

Uma tese setorial costuma nascer de uma experiência legítima. Um gestor de franquias percebe desperdícios entre unidades. Um profissional de saúde identifica falhas na jornada de atendimento. Um especialista em agronegócio conhece uma rotina manual que consome horas. Uma instituição de ensino enxerga baixa adesão em treinamentos. O risco aparece quando esse conhecimento é convertido diretamente em código, sem separar problema recorrente de preferência pessoal.

O objetivo do discovery não é produzir um relatório extenso. É reduzir incertezas críticas com evidências suficientes para decidir o que testar, o que adiar e o que não construir. Ao final, a equipe deve saber quem sofre com o problema, em qual contexto, com que frequência, qual alternativa usa hoje e qual mudança justificaria adoção ou pagamento.

Uma pesquisa com 8 a 12 pessoas pode revelar padrões relevantes quando os participantes ocupam papéis diferentes e relatam acontecimentos concretos. O número, sozinho, não valida um mercado. A qualidade da amostra, a recorrência dos comportamentos e a disposição de mudar ou pagar são mais úteis do que opiniões positivas sobre uma ideia.

Esse cuidado é especialmente importante em startups setoriais. O produto precisa respeitar regras, vocabulário, sazonalidade, integrações e níveis de risco específicos. Em saúde, por exemplo, privacidade e rastreabilidade entram no desenho desde o início. A validação de requisitos regulatórios em MVPs ajuda a evitar que uma descoberta comercial seja inviabilizada por uma restrição operacional ignorada.

Boas entrevistas de discovery operacional investigam comportamento, contexto e consequência. Perguntas abstratas como “você usaria esta solução?” geram respostas educadas, mas fracas para decisão. Prefira perguntas que levem a pessoa a narrar um episódio real, com começo, meio, fim e resultado.

Comece pelo processo: “Qual foi a última vez que você executou essa tarefa?”, “O que aconteceu primeiro?”, “Quais informações você precisava consultar?”, “Quem precisou aprovar?” e “Em qual etapa o trabalho parou?”. Essas perguntas revelam fluxo, dependências e pontos de espera sem induzir uma resposta.

Depois, investigue frequência e impacto: “Quantas vezes isso acontece em uma semana?”, “Quanto tempo a equipe gasta?”, “Que tipo de erro aparece?”, “O que acontece quando ninguém resolve?” e “Qual indicador piora?”. Procure números aproximados, registros, planilhas e chamados. Uma estimativa baseada em memória é um sinal para buscar evidência, não uma métrica definitiva.

Explore as soluções existentes. Pergunte se a equipe usa planilha, mensagens, ligações, ERP, formulário, planilha compartilhada ou conferência manual. O improviso atual é um concorrente. Se o operador criou uma rotina alternativa, descubra o que ela resolve e por que ainda não foi substituída.

Para entender a compra, converse com o gestor: “Quem autoriza uma mudança?”, “Qual orçamento poderia financiar um teste?”, “Que resultado justificaria continuar?”, “Quais áreas precisam aprovar acesso aos dados?” e “Qual seria o maior motivo para interromper o projeto?”. Em vendas B2B, usuário, comprador, influenciador e responsável por segurança raramente são a mesma pessoa.

As perguntas devem mudar conforme o setor. No agronegócio, investigue sazonalidade, conectividade, deslocamento e dependência de clima. Em saúde, explore consentimento, acesso, auditoria e responsabilidade clínica. Em educação, observe matrícula, engajamento, avaliação e integração com ambientes de aprendizagem. Em franquias, compare a operação ideal da franqueadora com a prática das unidades.

A pesquisa UX com decisores B2B antes de codificar complementa esse roteiro ao tratar de recrutamento, contexto de decisão e evidências de adoção. O ponto central é não confundir familiaridade com o setor com conhecimento comprovado do problema.

Considere uma startup para franquias que pretende criar um painel de desempenho. As primeiras entrevistas podem mostrar que o problema não é falta de indicadores, mas o tempo gasto conciliando vendas, estoque e metas entre sistemas diferentes. O MVP talvez precise começar com uma rotina de consolidação e alertas para uma decisão específica, não com um painel completo para toda a rede.

No agronegócio, um especialista pode propor uma solução sofisticada de previsão. O discovery operacional pode revelar que produtores não conseguem registrar dados de campo de forma consistente por causa de conectividade intermitente e rotinas móveis. Antes de treinar um modelo, faça um teste com captura offline, sincronização posterior e validação de poucos eventos críticos.

Em saúde, uma equipe pode acreditar que o ganho está em automatizar triagem. As entrevistas precisam esclarecer quem toma a decisão, quais dados são autorizados, como ocorre a revisão profissional e qual é o procedimento quando a recomendação está incompleta. Um MVP responsável pode começar como apoio à organização de informações, com supervisão explícita, antes de sugerir qualquer conduta.

Na educação, a hipótese “alunos abandonam porque a plataforma é ruim” é ampla demais. Observe matrícula, primeiro acesso, entrega de atividades, comunicação com tutores e momentos de abandono. Um protótipo que testa lembretes contextualizados para uma etapa específica pode gerar aprendizado mais rápido do que uma plataforma inteira.

Esses exemplos mostram por que o conhecimento setorial precisa ser decomposto. Know-how é uma vantagem para formular hipóteses e reconhecer exceções, mas não prova que uma solução será adotada. A validação acontece quando usuários mudam seu comportamento, gestores autorizam um teste e a organização aceita medir o resultado.

O protótipo de baixa fidelidade é adequado quando a dúvida principal está na compreensão do fluxo, na linguagem, na ordem das decisões ou na utilidade percebida. Ele funciona bem antes de definir arquitetura, especialmente quando diferentes perfis precisam revisar a mesma jornada. Uma tela simples pode revelar que o usuário espera uma informação que a equipe nunca considerou.

O teste manual, também chamado de concierge, serve quando a equipe quer verificar se o resultado tem valor mesmo sem automação. Um analista pode consolidar dados, preparar uma recomendação ou executar uma etapa nos bastidores. O limite é não esconder custos operacionais que tornariam o modelo inviável depois.

O piloto pago faz sentido quando a questão é compromisso. Pagamento não garante sucesso, mas mostra que existe orçamento, patrocinador e disposição para assumir uma mudança. Defina duração, escopo, acesso, indicador de sucesso e regra de encerramento. O artigo sobre piloto pago ou gratuito para validar um MVP B2B ajuda a comparar os sinais de cada formato.

Não transforme o piloto em desenvolvimento sob encomenda sem limite. Se cada cliente pedir uma operação diferente, você estará validando capacidade de prestação de serviço, não um produto repetível. Registre quais partes são essenciais ao segmento, quais são configurações e quais devem permanecer fora do primeiro MVP.

Uma regra prática é começar pelo experimento mais barato que responda à dúvida mais perigosa. Se ainda não está claro se a equipe entende o processo, faça entrevistas e protótipo. Se o problema é conhecido, mas não há prova de adoção, faça um teste operacional. Se existe interesse, mas falta compromisso, desenhe um piloto pago com critérios objetivos.