Radar de Obras é um produto meu, não um cliente. SaaS/DaaS B2B que coleta editais de licitação pública, filtra, dá score por relevância e entrega as oportunidades curadas via WhatsApp pra fornecedores de material de construção em Mato Grosso. Rodou em produção de abril a junho de 2026; hoje está pausado.
Construí esse case ao contrário do reflexo de designer: nada de abrir o Figma e desenhar tela. A pergunta que importava era anterior. Existe dor real? Quem sente? Vale resolver? Validei o produto inteiro antes da primeira linha de código. O que segue é a decisão de produto primeiro; a interface que ela gerou aparece como prova, não como ponto de partida.
Discovery primeiro,
tela como prova.
Double diamond ao contrário do reflexo: descobrir a dor real, definir pra quem, desenvolver a arquitetura, entregar com loop de qualidade.
8 rodadas até a dor real aparecer
Rodei 8 rodadas de pesquisa de ICP com deep-research e painéis de IA, mais benchmark dos concorrentes. Todos vendem a mesma promessa: "ache o edital". A pesquisa mostrou que esse não é o problema. O lojista até acha o edital; o que ele perde é a oportunidade, porque o balcão consome o dia. A dor não era de busca, era de atenção.
ICP destilado, 16 anti-ICPs, 3 clusters
Destilei a persona do comprador e, mais útil ainda, mapeei 16 anti-ICPs: quem parece cliente mas não é. Saber pra quem você não vende afia o produto tanto quanto saber pra quem você vende. Em vez de "plataforma de licitações" genérica, escolhi 3 clusters pra atacar. Os requisitos passaram a ser centrados num operador leigo: se exige treino, falhou.
Arquitetura que reduz carga cognitiva
Decisão de IA deliberada: separei o painel de negócio do painel de saúde técnica. O lojista vê só oportunidade, score e ação; scraper, fila e logs ficam num painel à parte. Misturar os dois é o erro clássico que afoga o usuário leigo em ruído. O scoring é adaptativo: sobe o que o fornecedor abre e responde, desce o que ele ignora.
No ar, com "Cliente Zero" no loop
Produto entrou em produção. Antes de expor a qualquer pagante, criei o mecanismo "Cliente Zero": eu mesmo na ponta, checando se o filtro entregava sinal e não lixo. É um loop de QA da relevância, não teste de usabilidade. Editais que vazavam o score viravam ajuste no peso. No dia em que alguém pagasse, o WhatsApp dele só receberia oportunidade que valia a leitura.
A decisão virou tela.
Utilitária de propósito: operador leigo, zero treino. Cada tela materializa uma decisão do produto, não enfeite.
Pass A → D, fechado.
O peso do discovery.
IA como copiloto de pesquisa, do discovery ao código
Todo o discovery (deep-research, painéis de decisão com múltiplos modelos), os planos e a própria construção foram conduzidos com Claude Code e agentes. Validar produto com IA como copiloto de pesquisa é o meu jeito de trabalhar.
Produto próprio, sem cliente pagante. O "Cliente Zero" é um QA interno de qualidade do filtro, não teste de usabilidade com usuário externo. Não houve teste A/B nem protótipo em Figma (a especificação era textual). A interface em produção é utilitária de propósito, operador leigo e zero treino; este case mostra a decisão de produto e o discovery que a sustentam, com as telas reais como evidência.