Localhub · Product design ponta a ponta · 2026
Ninguém quer um CRM
Passei vinte anos construindo produto para CVC, Natura e Porto. Quando fui construir o meu, parti de uma hipótese que parecia óbvia: o negócio local precisa de um CRM. O trabalho de descoberta derrubou isso na primeira semana. A dor que faz um dono de clínica abrir a carteira não é organizar contato. É perder cliente que já estava na mão.
Este case é sobre o que muda num produto quando você aceita que a sua premissa está errada.
- Papel
- Founder, product designer e engenheiro. Descoberta, arquitetura de informação, design system, implementação e operação em produção.
- Time
- Trabalho solo, com IA como par de programação. Clientes reais como banca de validação.
- Restrições
- Um só executor, orçamento zero de mídia, e um público sem paciência para software. Se exigir treinamento, morreu.
Comecei modelando a hipótese, não perguntando
Queria chegar nas conversas com hipótese formulada em vez de pergunta genérica. Montei cinco personas por segmento (saúde, advocacia, estética, pet e contabilidade), escrevi um roteiro de exploração no formato do Mom Test, e usei personas sintéticas para pressionar as hipóteses e achar onde elas quebravam. Isso é geração de hipótese, não evidência. Serviu para eu saber o que perguntar.
A evidência veio de três fontes reais.
A primeira foram as conversas de prospecção. Toquei pessoalmente a prospecção da Localhub, o que virou mais de trezentas conversas com donos de negócio local. Não são entrevistas formais e não vou chamar de pesquisa de campo. São conversas comerciais, com o viés que isso carrega. Mas é onde eu ouvi a mesma frase repetidas vezes.
A segunda foram clientes reais em operação. Trimat, G13, Patriot Insights e uma clínica odontológica entraram no sistema e me deram o comportamento real de uso, não o declarado.
A terceira foi o comportamento do próprio produto. Depois de rodar, o banco virou a minha melhor fonte de pesquisa. Volto nisso, porque foi ele que me contrariou de novo.
O que derrubou a hipótese
Ninguém pediu CRM. O que aparecia era sempre a mesma cena: o cliente mandou mensagem, ninguém respondeu a tempo, e ele foi para o concorrente. A dor não é falta de organização, é resposta lenta. E a segunda dor, quase tão frequente, é orçamento que foi enviado e morreu sem ninguém voltar nele.
Deixei de desenhar um lugar para guardar contato e passei a desenhar um sistema que não deixa ninguém sem resposta. A promessa do produto virou literalmente isso: nenhum cliente esquecido.
Organizei os achados numa árvore de oportunidades e priorizei três. A primeira foi resposta lenta. A segunda, resgate de orçamento parado. A terceira eu chamei de quebra de cicatriz: quase todo dono já tinha sido queimado por alguma agência ou algum sistema antes, e chegava desconfiado. Essa terceira não virou funcionalidade nenhuma. Virou decisão de posicionamento e de copy, e foi a mais difícil de aceitar, porque não dá para resolver com tela.
As decisões, e o que cada uma custou
O dono não vai abrir um painel
A persona que mais aparecia não senta na frente do computador. Ela atende, e olha o celular entre um cliente e outro.
A tela principal não é dashboard, é uma lista do que fazer agora. Chama “Meu dia” e responde uma pergunta só, qual é a próxima ação. Todo o design system nasceu mobile primeiro e em modo escuro.
O dashboard executivo com gráfico, que era o que eu queria fazer e o que todo concorrente mostra na home. Ele existe, mas não é a porta de entrada. Perdi a tela bonita e ganhei uso diário.
Reativar base fria vale mais que prospectar
Quando cruzei a dor de orçamento parado com o que os clientes tinham no banco, ficou claro que o dinheiro já estava lá dentro. O negócio local acumula base morta há anos.
O agente de vendas nasceu com o núcleo em reativação de base, e prospecção virou complemento. É contraintuitivo, porque prospecção vende mais fácil como promessa.
Posicionar o agente como máquina de prospecção, que era o pitch mais atraente comercialmente e o que o mercado esperava ouvir.
Automatizar mensagem queima o número do cliente
Aqui a pesquisa foi técnica e o achado veio de fora do usuário: envio ativo em massa no WhatsApp derruba o número. E o número do dono é o ativo dele, não meu.
Construí um guardrail que recusa envio para quem não deu opt-in, com rampa diária de volume e atraso de digitação. A cadência adia em vez de queimar. O produto ficou deliberadamente mais lento do que poderia ser.
Automação de Instagram. A API existe, mas eu não tinha aprovação da Meta, e mandar DM por caminho não sancionado colocava a conta do cliente em risco. Virou copiloto: o sistema escreve a mensagem e a pessoa envia. Vendia melhor como automático. Ficou como assistido.
Onde o dado me contrariou de novo
Semanas depois de tudo no ar, fui ao banco levantar números e achei um comportamento que eu não esperava: cinquenta e um leads tinham gerado mais de doze mil inscrições em cadência, uma média de duzentas e quarenta por lead, e todas as execuções estavam sendo recusadas pelo guardrail de opt-in.
Duas leituras saíram dali. A primeira é que o guardrail funcionava: recusou mais de doze mil tentativas de envio em vinte e quatro dias para proteger o número dos clientes. A segunda é que o motor estava errado, porque insistia em contatar quem ele já sabia que não podia contatar, e o dado dizia que quase todos os leads da base não tinham opt-in.
O desenho estava certo na trava e errado no fluxo.
Corrigi na origem: quem não pode receber não entra mais na régua, e quando falta permissão a inscrição encerra com estado próprio em vez de insistir. Aproveitei para separar, no diário que o cliente lê, recusa deliberada de falha técnica. Governança funcionando estava sendo exibida como sistema quebrado.
No mesmo levantamento achei que o motor de intenção estava incapaz de classificar qualquer lead como quente, por um teto de pontuação abaixo do próprio limiar. Também corrigido.
O que está no ar, e o que eu não vou afirmar
O sistema está em produção com doze contas provisionadas, incluindo clientes pagantes, e opera todo o ciclo do negócio local: captação, pipeline, agenda, cadência, e-mail, documento com assinatura e cobrança. São noventa e quatro tabelas, todas com isolamento por linha e mais de trezentas políticas de acesso, mantidas por uma pessoa.
Não vou apresentar métrica de conversão aqui. O produto é novo, o volume transacional real ainda é pequeno, e o número que eu poderia mostrar viria em boa parte de conta de demonstração. Prefiro dizer o que sei sustentar.
O mais útil foi o mais desconfortável
A minha descoberta estava certa sobre a dor e errada sobre o comportamento. As pessoas descreviam o problema como falta de organização e agiam como quem tem problema de permissão e de tempo. Só o dado de uso revelou isso, e ele só apareceu porque eu fui olhar depois de lançar.
Se eu recomeçasse, teria instrumentado o comportamento antes de escrever a primeira tela, e não depois de ter o produto rodando.