A Crawlbase é o cliente número um, então a primeira rodada séria da Knockwire foi apontada para o nosso próprio negócio. Escrevemos um perfil de cliente ideal, o ICP, a partir do que acreditávamos sobre as nossas melhores contas, apontamos o sistema para ele, e depois sentamos e lemos as primeiras cem recusas em ordem. O perfil estava errado em dois lugares. Os dois erros eram visíveis nas empresas que recusamos e invisíveis nas empresas que qualificaram.
01Leia as recusas, não as vitórias
O registro de recusas é a parte deste produto que publica o que foi recusado e por quê. Toda recusa carrega um motivo escrito em vez de um código, o que significa que o registro pode ser lido como prosa em vez de contado, e ler de ponta a ponta é um exercício diferente de rolar a lista de qualificadas.
A lista de qualificadas concorda com você. Ela tem que concordar. Uma empresa qualificou porque bateu com o perfil que você escreveu, então uma página de empresas qualificadas é uma página das suas próprias premissas devolvida com logotipos anexados. As recusas são o único lugar em que o perfil encontra algo que ele não previu. Uma empresa que passa por todos os filtros menos um, com um motivo escrito no filtro que a parou, é um pequeno argumento contra a regra que a parou.
Dois desses grupos não dizem nada sobre nós. Empresa morta é higiene, e sem porta utilizável é um fato sobre um site em vez de um fato sobre o nosso perfil. Os outros três são o perfil sendo testado, e dois deles estavam discutindo conosco por escrito.
02Primeiro erro: tínhamos escrito empresas que precisam de dados
O nosso alvo declarado era empresas que precisam de dados. É o tipo de frase que sobrevive a um workshop porque ninguém consegue discordar dela, e estava errada do jeito que frases amplas costumam estar. Ela admitia gente demais, e os filtros atrás dela passaram a rodada inteira jogando o excedente de volta para fora.
Trinta e quatro das primeiras cem recusas carregavam uma versão do mesmo motivo escrito: aqui o dado é insumo, não produto. Todas essas empresas tinham passado pela checagem de perfil. Uma transportadora que raspa tarifas de transportadoras tem uma necessidade real de dados. O mesmo vale para um varejista observando preços de concorrentes, e para um banco checando listas de sanções. Nos três casos a coleta é uma linha de custo que alguém no financeiro está tentando reduzir, e esse fato define o teto do que eles algum dia vão gastar.
Uma recusa dessas se lê como quase acerto. Trinta e quatro se leem como definição. O filtro de evidência tinha descoberto o atributo que faltava na frase do nosso perfil, e vinha anotando isso em bom português, uma vez por empresa, por duas semanas antes de alguém ler o registro do começo.
As nossas doze maiores contas por receita acumulada não se parecem nada com aquelas trinta e quatro. Cada uma das doze vende um produto de dados. A coleta é o custo da mercadoria delas, e não uma atividade lateral, e é por isso que o gasto delas sobe quando o negócio vai bem em vez de cair quando o orçamento é revisado. Elas se concentram em três famílias de alvo, marketplace, viagens, e dados de pessoas ou de empresas, e cada um desses alvos bloqueia tráfego casual.
Então o alvo não é uma empresa que precisa de dados. É uma empresa cujo produto é dado, que já está raspando, e que está sofrendo com isso. Essa versão é mais estreita, mais afiada, e respondível no momento da leitura, porque você pode olhar uma empresa e ver o que ela vende. Você não pode olhar uma empresa e ver o quanto ela precisa de alguma coisa.
03Segundo erro: contamos cabeças em vez de volume
O segundo erro era mais silencioso e nos custou mais, porque recusava empresas em vez de apenas desperdiçar leituras com elas. Tínhamos colocado um piso de headcount no perfil, na suposição de que tamanho de empresa prevê orçamento.
Tamanho prevê orçamento, fracamente, e na direção errada para este mercado. Várias das contas mais fortes da nossa carteira são times pequenos com volume pesadíssimo: empresas de um produto só em que um punhado de engenheiros roda coleta contínua contra alvos que revidam. Headcount é uma proxy de gasto, e é uma proxy ruim quando o produto é dado, porque o volume vem do alvo do crawl e não do organograma. Oito pessoas indexando um marketplace com milhões de anúncios gastam mais que quatrocentas pessoas que puxam uma lista de preços de concorrente toda segunda-feira.
No registro isso apareceu como contradição, e não como padrão. Quatorze empresas foram recusadas por tamanho carregando evidência forte em todo o resto, então os motivos escritos se liam como argumentos contra si mesmos: qualificada na família de alvo, qualificada na evidência de coleta, abaixo do piso de headcount. Quando você tem uma dúzia de recusas com esse formato, você não tem um piso de headcount. Você tem um bug que ainda não admitiu.
Tiramos o piso e colocamos duas perguntas observáveis no lugar: a família de alvo bloqueia tráfego casual, e a superfície pública sugere coleta contínua em vez de um projeto com data de fim. As duas são respondíveis a partir de evidência que uma fonte de fato devolveu. Nenhuma delas nos pede para adivinhar uma folha de pagamento.
04Um perfil de cliente ideal é uma hipótese
A lição geral é sobre que tipo de objeto um perfil é. Estávamos tratando o nosso como uma descrição de clientes que já tínhamos, quando ele era na verdade uma hipótese: escrita antes da evidência, carregada adiante sem exame, e nunca testada contra aquilo que ela excluía. Uma descrição se confere olhando. Uma hipótese se confere observando o que ela descarta, e um registro de recusas é o registro de tudo o que um perfil descartou, com o motivo junto.
Isso muda o que você faz com as primeiras cem de qualquer coisa. O instinto é ler as empresas qualificadas e decidir se o sistema funciona. A passada útil é ler as recusas e decidir se o perfil funciona. No nosso caso o sistema fez exatamente o que mandaram, duas vezes, e o que mandaram estava errado.
O que nos leva à coisa que nos recusamos a fazer aqui. Não ajustamos o perfil em silêncio pelas costas do operador. Nada neste pipeline calibra sozinho o perfil de cliente ideal a partir do comportamento de aprovação e de recusa, embora o dado para fazer isso esteja bem ali e a demo ficasse excelente.
A razão é que um perfil que se ajusta sozinho torna o registro de recusas ilegível. O registro só vale a publicação se um motivo significar a mesma coisa em março e em janeiro. Se as regras andam por conta própria, ninguém consegue dizer se uma empresa foi recusada porque as circunstâncias dela mudaram ou porque a regra se moveu debaixo dela, e toda recusa histórica vira uma afirmação sobre uma versão do perfil que nunca foi escrita.
Então o sistema propõe e o operador decide. Quando as recusas formam grupo, mostramos o grupo: aqui estão trinta e quatro empresas recusadas pelo mesmo motivo escrito, aqui está o filtro que recusou, aqui está a mudança no perfil que teria deixado elas passarem, e aqui está o que essa mudança teria feito com o resto da rodada. O operador lê e toma a decisão. Uma mudança no perfil de cliente ideal é uma decisão com data e nome, e os dois erros acima foram corrigidos assim, às claras, por uma pessoa.