GTM híbrido em cripto: PLG para self-service, sales para enterprise
Todo produto de infraestrutura cripto que dá certo acorda um dia com dois clientes irreconciliáveis na porta. De um lado, o desenvolvedor que descobriu o produto no Discord, integrou a API num fim de semana e quer pagar com cartão sem falar com ninguém. Do outro, a instituição financeira que adora o produto, mas não assina nada sem contrato, SLA, questionário de compliance e três reuniões com o time técnico.
A tentação é escolher um lado. É a escolha errada: os dois públicos são reais, compram o mesmo produto por caminhos opostos, e o projeto que atende só um deixa na mesa ou a escala do self-service ou o ticket do enterprise. A resposta madura tem nome: GTM híbrido, e o playbook está documentado no guia da a16z sobre escalar organizações de go-to-market: product-led growth como motion bottom-up eficiente em custo, vendas como motion top-down para enterprise, e uma estrutura organizacional em que as duas frentes operam como pares, com a adoção bottom-up alimentando o funil top-down.
Este guia traduz o modelo para a realidade cripto: como segmentar o ICP, quando ligar a segunda motion, como conectar os funis e como organizar time e pricing sem que uma motion destrua a outra.
Principais takeaways
Continue por dentro
Um estudo denso por quinzena, direto no seu email.
Os bastidores de por que tokens e projetos crescem. Sem ruído, sem spam.
- Produtos de infraestrutura cripto têm dois compradores estruturais: o self-service que integra sozinho e o enterprise que compra por processo.
- PLG é a motion bottom-up eficiente em custo; vendas é a motion top-down que fecha o que o produto sozinho não fecha.
- O gatilho da segunda motion, segundo a a16z: conversões travando em certa fase do funil PLG, com uso individual que não vira contrato.
- A estrutura recomendada mantém os líderes de PLG e vendas como pares sob um líder comum, com o bottom-up alimentando o top-down.
- Segmentação de ICP com regras de roteamento explícitas é o que impede as motions de se canibalizarem.
Os dois ICPs: por que um só funil não serve
A segmentação começa reconhecendo que os dois públicos diferem em tudo que importa para o desenho do funil:
| Dimensão | Self-service | Enterprise |
|---|
| Quem decide | O próprio usuário técnico | Comitê: técnico, jurídico, compliance, financeiro |
| Ciclo de decisão | Horas a dias | Meses |
| O que avalia | Docs, DX, preço público, comunidade | SLA, segurança, contrato, roadmap, fornecedor |
| Como quer comprar | Sem falar com ninguém | Com dono do relacionamento |
| Ticket | Baixo, em volume | Alto, em poucos contratos |
| O que mata a venda | Fricção no onboarding | Ausência de resposta institucional |
A tabela explica por que as soluções intuitivas falham. Empurrar o enterprise para o checkout self-service não funciona: ele não tem como aprovar a compra sem os artefatos institucionais. Colocar um formulário de "fale com vendas" na frente do desenvolvedor também não: ele fecha a aba e integra o concorrente que deixou testar na hora. Cada público precisa do caminho desenhado para ele, e os dois caminhos precisam coexistir na mesma casa.
Em cripto, a fronteira costuma ser nítida: protocolos, times de produto e desenvolvedores independentes de um lado; exchanges, custodiantes, fintechs reguladas e instituições financeiras do outro. O critério de corte prático combina tamanho da organização, volume de uso projetado e requisitos de compliance.
A motion PLG: o produto como vendedor
Para o segmento self-service, o guia da a16z descreve o PLG como a motion bottom-up mais eficiente em custo. A venda acontece dentro do produto, e a operação de growth trabalha nas condições:
- Time-to-value implacável. A métrica que governa tudo: quanto tempo do primeiro contato até a primeira integração funcionando. Docs impecáveis, sandbox sem cadastro burocrático, exemplos prontos por caso de uso.
- Preço público e baseado em consumo. A a16z registra a ascensão dos modelos de consumo (pay-as-you-use) como tendência do GTM moderno. Para o self-service cripto, é o encaixe natural: o desenvolvedor começa pagando quase nada e a receita cresce com o uso dele.
- Comunidade como canal. Em cripto, a decisão do desenvolvedor se forma no Discord, no GitHub e no X. A operação de PLG trata esses espaços como o funil de fato: presença técnica, resposta rápida, exemplos da comunidade amplificados.
- Instrumentação desde o dia um. Cada conta self-service gera sinal de uso. Esses sinais são o ativo que conecta as duas motions, como se verá adiante.
A motion de vendas: quando e como ligar
O erro clássico é contratar vendas cedo demais (queima caixa vendendo o que o produto ainda venderia sozinho) ou tarde demais (deixa contratos enterprise amadurecerem na mesa do concorrente). O sinal de timing que a a16z documenta é preciso: quando a empresa já tem posição no mercado e as conversões travam em determinada fase do funil PLG, é hora da motion sales-assisted.
Em cripto, esse travamento tem cara conhecida: o produto tem dezenas de integrações pequenas dentro de uma mesma instituição grande, uso crescendo, e nenhum contrato corporativo, porque contrato corporativo não se auto-serve. É o momento em que um vendedor pega os sinais de uso e transforma em processo de venda: mapeia o comitê, produz os artefatos institucionais (segurança, SLA, roadmap), negocia o pacote.
A disciplina essencial: vendas trabalha sobre o PLG, nunca contra ele. O pipeline enterprise mais barato do mundo é a lista de organizações onde o produto já entrou por baixo. Vendas que ignora esses sinais e faz cold outbound puro está pagando caro pelo que a outra motion entregaria de graça.
Conectando os funis: estrutura, roteamento e pricing
A parte difícil do híbrido não é rodar duas motions; é impedir que elas se atrapalhem. Três mecanismos resolvem:
Estrutura de pares. A recomendação organizacional da a16z: manter os líderes das duas frentes como pares, ambos reportando a um líder que garanta que a adoção bottom-up alimente o funil top-down. Subordinar PLG a vendas mata o produto como canal; subordinar vendas a PLG mata a disciplina de processo enterprise. Pares, com dono comum do resultado.
Roteamento com regra explícita. Critérios objetivos e documentados definem o que é lead de vendas: tamanho de organização, volume de uso, requisito de compliance declarado. Tudo abaixo da linha permanece self-service, e vendas não caça ali. Sem a regra escrita, vendas desce o mercado atrás de quota e destrói a economia das duas motions ao mesmo tempo.
Pricing em duas camadas coerentes. Preço público de consumo para o self-service; pacote negociado com SLA e suporte para enterprise, com prêmio justificado pelos artefatos institucionais, não por opacidade. A armadilha dupla: preço enterprise público que assusta o desenvolvedor, ou instituição pagando preço de self-service porque ninguém capturou o valor do contrato.
O guia da a16z acrescenta duas peças ao quadro de expansão: customer success como motor de receita de expansão pós-venda (crítico no enterprise, onde o contrato inicial é a semente, não o teto) e a ascensão de channel sales via marketplaces de cloud como AWS, Google Cloud e Azure, um canal que produtos de infraestrutura cripto com clientela institucional já começam a explorar.
Conclusão
GTM híbrido não é indecisão entre dois modelos; é o reconhecimento de que produtos de infraestrutura têm dois compradores estruturais e de que cada um exige a motion desenhada para ele. PLG entrega escala e sinal; vendas entrega os contratos que o produto sozinho não fecha; a estrutura de pares, o roteamento explícito e o pricing em camadas impedem que uma frente devore a outra. O projeto que domina o híbrido cresce pelos dois lados do mercado enquanto os concorrentes escolhem um.
A Kaleidos desenha operações de go-to-market para projetos cripto e fintech exatamente nessa arquitetura: segmentação de ICP, funil por motion e narrativa que serve às duas frentes. É esse o método aplicado nos projetos que a agência atende. Se o seu produto tem dois públicos e um funil só, fale com a Kaleidos.