Product-led growth encontrou RevOps — e os dois ainda não se entendem

O choque de mundos: por que PLG e RevOps colidem

Sua empresa adotou product-led growth. O produto tem um free tier generoso, os usuários entram sozinhos, exploram funcionalidades sem falar com ninguém e — em teoria — fazem upgrade quando percebem valor. Marketing celebra o volume de sign-ups. Produto comemora a ativação. E vendas olha para o pipeline e pergunta: "Cadê meu lead?"

Do outro lado, a operação de RevOps construiu um sistema lindo de handoff entre marketing e vendas, com lead scoring, SLAs de follow-up e etapas de pipeline bem definidas. Só que metade dos usuários que converteram em clientes pagantes nunca passaram por esse funil. Eles simplesmente usaram o produto, colocaram o cartão de crédito e compraram. O CRM nem sabe que eles existem.

Esse é o choque de mundos. PLG opera com uma premissa filosófica: o produto é o vendedor. RevOps opera com outra: processos, dados e alinhamento entre áreas geram receita previsível. As duas premissas não são erradas — mas quando coexistem sem tradução entre elas, o resultado é caos operacional disfarçado de sofisticação.

E o pior: como os números de vaidade (sign-ups, MAU, NPS do free tier) costumam ser altos em operações PLG, ninguém percebe o problema até que a empresa tenta escalar receita de verdade — com expansão, enterprise ou upsell agressivo — e descobre que não tem infraestrutura para isso.

O que o mercado diz sobre PLG e operações de receita

A narrativa de PLG dominou a conversa de SaaS nos últimos anos. Empresas como Slack, Figma, Notion e Calendly viraram cases canônicos de crescimento impulsionado pelo produto. A OpenView Partners, que popularizou o termo product-led growth, documentou extensivamente como empresas PLG tendem a ter métricas de eficiência superiores: CAC mais baixo, time-to-value mais curto, retenção orgânica mais alta.

Ao mesmo tempo, a Gartner e a Forrester vêm apontando que empresas com função de RevOps formalizada crescem mais rápido do que aquelas sem ela — algo que exploramos em profundidade no nosso guia definitivo de RevOps. O argumento é claro: alinhamento entre áreas, dados unificados e processos padronizados são aceleradores de receita.

Mas aqui está o gap que quase ninguém discute: a maioria das práticas de RevOps foi desenhada para modelos sales-led. Os playbooks, os frameworks de pipeline, os modelos de scoring, os SLAs de handoff — tudo pressupõe que existe um vendedor humano no centro da equação. Quando o produto assume esse papel, o sistema inteiro range.

Não é que PLG e RevOps sejam incompatíveis. É que a linguagem, as métricas e os rituais de cada um foram construídos em silos diferentes. PLG fala em activation rate, time-to-value, product-qualified leads (PQLs), feature adoption. RevOps fala em MQLs, SQLs, pipeline velocity, win rate, pipeline coverage ratio. As duas turmas olham para a mesma empresa e veem realidades diferentes.

Anatomia da fricção: onde exatamente o atrito acontece

O problema não é abstrato. Ele se manifesta em pontos muito concretos da operação. Vou mapear os cinco mais comuns.

1. O CRM não reconhece o PQL

A maioria dos CRMs — incluindo a HubSpot, Salesforce, Pipedrive — foi construída em torno do conceito de lead e oportunidade. Um lead entra por um formulário, um evento, uma campanha. É qualificado por critérios demográficos e comportamentais. Eventualmente vira uma oportunidade com um deal associado.

Em PLG, o "lead" é alguém que criou uma conta gratuita, usou o produto por 14 dias, convidou 3 colegas e atingiu o limite do plano free. Essa pessoa é extremamente qualificada — mais qualificada, aliás, do que a maioria dos MQLs — mas o CRM não sabe disso. O dado de uso do produto mora no backend da aplicação, não no CRM. E sem uma integração robusta, esse sinal se perde.

Resultado: vendas recebe MQLs frios do marketing e ignora PQLs quentes do produto — porque o sistema literalmente não mostra esses PQLs no pipeline. Como discutimos no artigo sobre o mito da single source of truth, o CRM só é útil quando reflete a realidade do negócio. E em PLG, ele frequentemente não reflete.

2. O funil linear não serve

RevOps adora o funil. Awareness → Interest → Consideration → Decision → Closed-Won. É limpo, é auditável, é previsível. Só que em PLG, a jornada não é linear. Um usuário pode:

• Criar conta gratuita (pulando awareness e interest completamente)
• Usar o produto por meses sem falar com ninguém
• Fazer upgrade sozinho em um domingo à noite
• Voltar a ser free e depois fazer upgrade de novo
• Ser um usuário individual que eventualmente puxa a empresa inteira

Esse padrão de "entrar pela porta dos fundos" quebra o funil tradicional. E mais importante: quebra o forecast. Como prever receita quando metade das conversões acontece sem interação humana, sem deal no pipeline e sem estágio de negociação? Quem leu nosso artigo sobre forecasting como teatro já sabe que a previsão de receita é frágil mesmo em modelos sales-led. Em PLG, ela é praticamente ficção.

3. O handoff não existe — ou existe demais

Em sales-led, o handoff entre marketing e vendas é um momento bem definido. O lead atinge pontuação X, é passado para o SDR, que qualifica e agenda com o AE. Existem SLAs, timestamps, notificações.

Em PLG puro, esse handoff não existe. O usuário se auto-qualifica pelo uso do produto. Mas quando a empresa tenta adicionar uma camada de vendas (o famoso "PLG + Sales"), surgem dois problemas:

1. Ninguém sabe quando intervir. Cedo demais e você espanta o usuário que queria autoatendimento. Tarde demais e ele já decidiu (positiva ou negativamente) sem sua influência.
2. Ninguém sabe quem intervém. É o SDR? O AE? O CSM? Produto? Growth? Em muitas empresas PLG, existe uma role chamada "Product Specialist" ou "Growth Rep" que fica numa terra de ninguém organizacional.

4. Expansion revenue fica invisível

PLG naturalmente gera expansion revenue — usuários adicionando seats, times comprando módulos adicionais, upgrade de plano. Mas como esse movimento acontece dentro do produto, ele frequentemente não aparece no CRM como expansion. Aparece como "nova transação" ou nem aparece. RevOps perde visibilidade sobre uma das alavancas mais importantes do modelo.

5. Atribuição vira um pesadelo

Qual canal gerou aquele cliente que entrou pelo free tier, usou o produto por 6 meses, clicou em um e-mail de produto uma vez, e fez upgrade depois de ver um webinar? Marketing quer crédito pelo webinar. Produto quer crédito pela experiência do free tier. Growth quer crédito pelo e-mail de nudge. E a verdade sobre atribuição é que nenhum modelo vai dar a resposta certa — mas em PLG, a confusão é exponencialmente pior porque o produto é simultaneamente canal de aquisição, ferramenta de qualificação e mecanismo de conversão.

A tese: produto é um canal de receita, não um substituto para vendas

A verdade incômoda é que PLG puro não escala para a maioria das empresas. Mesmo os cases mais celebrados — Slack, Zoom, Datadog — eventualmente adicionaram times de vendas robustos para atacar enterprise. O produto abriu a porta, mas quem fechou o contrato de 7 dígitos foi um AE humano com uma proposta customizada.

E aqui está o ponto que poucos querem admitir: a transição de PLG puro para PLG + Sales (ou product-led sales, como alguns chamam) é o momento exato em que RevOps se torna crítico — e é também o momento em que RevOps está menos preparado para atuar.

O produto não substitui vendas. O produto substitui a parte ruim de vendas: cold calls improdutivos, demos genéricas, qualificação por adivinhação. RevOps precisa abraçar o produto como o melhor SDR que a empresa já teve — e construir a infraestrutura em torno disso.

Minha tese é simples: o produto deve ser tratado como um canal de receita dentro da operação de RevOps, assim como marketing é um canal e vendas outbound é um canal. Isso significa que:

1. Sinais de produto precisam entrar no CRM como dados de primeira classe. Não como uma propriedade custom escondida num canto. Como dados que disparam workflows, alimentam scoring e aparecem no pipeline.
2. PQLs precisam ter o mesmo rigor que MQLs e SQLs. Critérios claros de qualificação, thresholds definidos, SLAs de follow-up. "Usuário ativo" não é qualificação — é vagueza.
3. Conversões self-serve precisam ser rastreadas como deals. Mesmo que não tenham passado por um vendedor, precisam existir no pipeline para efeitos de forecast, atribuição e cálculo de CAC.
4. O time de RevOps precisa ter acesso (e fluência) em dados de produto. Mixpanel, Amplitude, Pendo, Heap — ou qualquer ferramenta de product analytics — precisa conversar com o CRM, e alguém em RevOps precisa saber interpretar esses dados.
5. O forecast precisa ter duas pernas: uma para receita sales-assisted e outra para receita self-serve. Juntar tudo no mesmo modelo é garantia de imprecisão.

Nenhum desses pontos exige criar um framework novo ou reinventar a roda. Exige tratar o produto com a mesma seriedade operacional que já damos a marketing e vendas. E é exatamente isso que a maioria das empresas PLG não faz.

De sinais de produto a pipeline qualificado: o fluxo que falta

Se o produto é um canal de receita, ele precisa ter um fluxo operacional definido — da mesma forma que marketing tem fluxo de lead nurturing e vendas tem fluxo de pipeline. Vamos construir esse fluxo.

Passo 1: Definir o PQL com critérios mensuráveis

Um Product-Qualified Lead não é "alguém que usou o produto". É alguém que atingiu um conjunto específico de marcos de ativação que correlacionam com propensão a pagar. Exemplos concretos:

• Criou conta + completou onboarding + convidou pelo menos 2 colaboradores
• Usou feature X mais de 10 vezes nos últimos 14 dias
• Atingiu 80% do limite do plano free (storage, seats, API calls)
• Acessou a página de pricing 3+ vezes
• Empresa tem mais de 50 funcionários (dado firmográfico cruzado)

O segredo está na combinação. Nenhum desses critérios isoladamente significa muito. A combinação é o que produz sinal. E isso é exatamente a mesma lógica do lead scoring combinando fit e engagement — só que os sinais de engagement vêm do produto em vez de vir do marketing.

Passo 2: Integrar dados de produto no CRM

Este é o passo técnico que separa empresas que falam de PLG das que fazem PLG funcionar. Você precisa de um pipeline de dados que traga eventos de produto para dentro do CRM em tempo real ou near-real-time.

Na prática, isso envolve:

• Ferramenta de product analytics (Amplitude, Mixpanel, Pendo, PostHog) capturando eventos
• Camada de integração (Segment, RudderStack, ou integração direta via API) enviando eventos qualificados para o CRM
• Propriedades custom no CRM que recebem esses dados: "data de ativação", "features usadas", "número de colaboradores convidados", "% do limite usado"
• Workflows automatizados que, quando um contato atinge os critérios de PQL, criam um deal automaticamente e notificam o rep responsável

Na HubSpot, por exemplo, isso pode ser feito via Data Hub (antigo Operations Hub) com código custom para sincronizar dados, ou via integrações nativas com ferramentas como Segment. A chave é que os dados de produto não podem ser um add-on — precisam ser cidadãos de primeira classe no CRM.

Passo 3: Definir o modelo de intervenção

Com PQLs identificados e no CRM, a próxima pergunta é: quem faz o quê, e quando?

Segmento do PQL	Ação	Responsável	Timing
Usuário individual, empresa <20 pessoas	E-mail automatizado de nudge para upgrade	Automação (Marketing/Growth)	Quando atinge 80% do limite free
Usuário individual, empresa 20-200 pessoas	Outreach consultivo: "Vi que seu time está usando X, posso mostrar como Y funciona?"	Product Specialist / Growth Rep	Quando 3+ pessoas da mesma empresa usam
Múltiplos usuários, empresa 200+ pessoas	Qualificação enterprise: discovery call, proposta customizada, security review	AE Enterprise	Quando 5+ usuários ativos ou um admin corporativo cria conta
Usuário que fez downgrade ou cancelou	Sequência de reengajamento com oferta contextual	CS / Automação	48h após downgrade

Esse modelo reconhece que nem todo PQL precisa de um vendedor humano. Usuários pequenos podem converter via self-serve. Mas contas com potencial enterprise precisam de intervenção — e essa intervenção precisa ser informada pelo uso do produto, não por um cold call genérico.

Passo 4: Bifurcar o forecast

Receita self-serve e receita sales-assisted têm dinâmicas completamente diferentes. Jogar tudo no mesmo modelo de forecast é como somar bananas e abacates.

• Self-serve: forecast baseado em volume (quantos sign-ups → taxa de ativação → taxa de conversão free-to-paid → ticket médio). É um modelo estatístico, não um pipeline de deals.
• Sales-assisted: forecast baseado em pipeline tradicional (deals em estágio X com probabilidade Y). Aqui os métodos clássicos funcionam — weighted pipeline, commit/upside, etc.

RevOps precisa apresentar os dois modelos para o board, com suas premissas explícitas. E precisa ser honesto: o forecast self-serve vai ter uma margem de erro diferente do forecast sales-assisted.

Case study: a empresa de SaaS que tinha 40.000 usuários free e não sabia vender

Imagine uma empresa de SaaS B2B que oferece uma ferramenta de gestão de projetos. Produto sólido, mercado competitivo (Asana, Monday, ClickUp como referências do segmento). A empresa tem um modelo freemium: até 10 usuários e 5 projetos, grátis. Acima disso, planos a partir de R$ 49/usuário/mês.

Em meados de 2025, a empresa tinha um cenário invejável — e um problema grave:

• 40.000 contas no plano free
• Cerca de 12.000 contas ativas nos últimos 30 dias
• Taxa de conversão free-to-paid de 2,1% — dentro da faixa esperada para freemium
• Faturamento: R$ 4,2 milhões ARR (cerca de 840 contas pagantes)
• Time de vendas de 4 AEs que faziam outbound tradicional, sem conexão com dados de produto
• NPS de 62 — bom, mas sem tradução em upgrade

O board queria chegar a R$ 10 milhões de ARR em 18 meses. A conta não fechava com a taxa de conversão atual. O CEO pediu para contratar mais 6 AEs. O VP de Produto disse que o caminho era melhorar a experiência do plano free para gerar mais conversão orgânica. O marketing queria mais budget para gerar MQLs via conteúdo e anúncios.

Todos estavam errados. Ou melhor, todos estavam parcialmente certos — mas ninguém estava olhando para o problema real.

O diagnóstico

Uma análise mais cuidadosa dos dados revelou:

1. Das 12.000 contas ativas, 1.800 tinham mais de 8 usuários — ou seja, estavam a 2 usuários do limite do plano free. Essas contas eram PQLs óbvios, mas ninguém estava abordando elas.
2. Dessas 1.800, 340 pertenciam a empresas com mais de 200 funcionários — potenciais contas enterprise. O ACV potencial dessas contas era de R$ 30.000-80.000/ano, não R$ 588 (plano básico individual).
3. Os 4 AEs ligavam para MQLs que vieram de e-books e webinars. Taxa de conversão desses MQLs: 3,8%. Enquanto isso, as 340 contas enterprise ativas estavam literalmente usando o produto todos os dias — e ninguém sabia.
4. Expansion revenue das contas pagantes existentes era de apenas 5% do ARR. Não porque clientes não queriam expandir, mas porque o processo de adicionar seats era confuso e o CRM não rastreava sinais de expansão. Como discutimos em nosso artigo sobre expansion revenue, essa é uma das alavancas mais baratas e mais negligenciadas.

A intervenção

A empresa contratou uma pessoa de RevOps (a primeira) e deu a ela um mandato claro: conectar dados de produto com a operação de receita em 90 dias. Veja o que foi feito:

Mês 1: Infraestrutura de dados

• Integração entre o backend do produto (que rodava eventos via Segment) e a HubSpot, que era o CRM da empresa
• Criação de propriedades custom no CRM: "usuários ativos", "projetos criados", "data da última sessão", "% do limite utilizado", "features premium acessadas"
• Definição dos critérios de PQL: conta com 8+ usuários ativos, 80%+ do limite utilizado, pelo menos 1 tentativa de acessar feature premium. Empresa com 50+ funcionários pontuava mais alto
• Investimento nessa fase: aproximadamente R$ 35.000 (ferramenta + horas de desenvolvimento + configuração do CRM)

Mês 2: Processo e capacitação

• Os 4 AEs pararam de receber MQLs de e-book. Passaram a receber PQLs com contexto completo: "Essa empresa tem 12 usuários ativos, criou 28 projetos nos últimos 30 dias, acessou a funcionalidade de relatórios (premium) 7 vezes e está a 2 seats do limite"
• Novo playbook de abordagem: em vez de "Oi, vi que você baixou nosso e-book sobre gestão de projetos", a mensagem era "Notei que seu time de 12 pessoas está usando bastante os relatórios — aqui está como o plano Pro resolve o limite que vocês estão atingindo"
• SLA definido: PQL com score acima de 70 deveria receber contato em até 4 horas úteis
• Para contas menores (abaixo de 50 funcionários, PQL score entre 40-70), a abordagem era automatizada: sequência de e-mails com oferta de trial do plano pago

Mês 3: Forecast bifurcado

• Receita self-serve: modelada estatisticamente com base na taxa histórica de conversão free-to-paid, ajustada pelo volume de contas atingindo limites
• Receita sales-assisted: pipeline tradicional com PQLs enterprise — deals criados automaticamente quando uma conta enterprise atingia score de PQL
• Report semanal para o board com as duas linhas separadas

O resultado (6 meses depois)

• Taxa de conversão free-to-paid subiu de 2,1% para 3,4% — impulsionada pelas sequências automatizadas para PQLs menores
• Pipeline enterprise surgiu do nada: 48 deals qualificados nos primeiros 90 dias, com ACV médio de R$ 42.000
• Win rate dos PQLs enterprise: 34% — vs. 3,8% dos antigos MQLs de e-book
• Expansion revenue subiu de 5% para 14% do ARR — porque sinais de uso geravam alertas automáticos de expansão
• ARR no mês 6 da intervenção: R$ 6,8 milhões, ritmo que projetava ultrapassar R$ 10M no prazo planejado
• Investimento total nos 6 meses: R$ 180.000 (pessoa de RevOps + ferramentas + integração + horas de desenvolvimento). ROI projetado no primeiro ano: 7,2x

O ponto crucial: a empresa não contratou mais 6 AEs. Não aumentou o budget de marketing. Não mudou o produto. Apenas conectou os dados que já tinha aos processos que já precisava ter.

As métricas que precisam existir entre PLG e RevOps

Um dos maiores sintomas do desalinhamento entre PLG e RevOps é que cada área acompanha métricas diferentes e declara sucesso em dimensões que a outra não reconhece. Produto comemora ativação. Marketing comemora MQLs. Vendas comemora pipeline. E ninguém tem uma visão unificada de como a receita realmente aconteceu.

Para resolver isso, existe um conjunto de métricas que precisa ser definido, acompanhado e discutido conjuntamente. Não são métricas novas — são pontes entre métricas existentes:

Métrica	O que mede	Quem é responsável	Por que importa para o alinhamento
PQL-to-Paid Rate	% de PQLs que convertem em clientes pagantes (self-serve ou sales-assisted)	RevOps + Produto	Equivalente ao MQL-to-SQL, mas para o canal de produto. Se essa taxa é baixa, o problema pode estar nos critérios de PQL ou na intervenção
Time-to-PQL	Tempo médio entre sign-up e atingimento de critérios de PQL	Produto	Análogo ao ciclo de vendas. Se demorar demais, onboarding precisa melhorar. Se for rápido demais, os critérios podem estar frouxos
Self-serve revenue %	% da receita total que vem de conversões sem intervenção humana	RevOps	Mostra quanto o produto realmente "vende" sozinho. Se cai, pode indicar que self-serve está quebrando. Se sobe, pode indicar que vendas não está agregando valor
Sales-assist uplift	Diferença de ACV entre conversão self-serve e sales-assisted para o mesmo perfil de cliente	RevOps + Vendas	Justifica (ou questiona) a existência do time de vendas. Se o ACV é 3x maior com intervenção, vendas agrega valor. Se é o mesmo, vendas está desperdiçando recurso
Expansion-from-product rate	% de expansion revenue que originou de sinais de produto (vs. vendedor proativo)	CS + RevOps	Mostra se o produto está gerando sinais de expansão que a operação captura
Blended CAC por canal	CAC calculado separadamente para aquisição via produto, marketing e vendas outbound	RevOps + Finanças	Revela a eficiência real de cada canal. PLG tipicamente tem CAC menor, mas se a infraestrutura para suportá-lo é cara, pode não ser tão eficiente quanto parece

Essas métricas não precisam ser acompanhadas em dashboards separados. Idealmente, vivem no mesmo report semanal/mensal que RevOps já apresenta — só que com a dimensão "produto como canal" adicionada.

A métrica mais reveladora, na minha experiência, é o sales-assist uplift. Ela responde a pergunta fundamental: o vendedor agrega valor ou apenas adiciona custo? Se um usuário que converte sozinho paga R$ 49/mês e um que converte com ajuda de um AE paga R$ 200/mês (porque o AE montou um pacote com mais seats e funcionalidades), o AE está gerando 4x mais receita por conversão. Isso justifica o investimento em sales-assisted. Mas se o ACV é similar, a intervenção é desperdício.