Existe uma frase aparecendo em calls de venda.
Um cliente ouve o pitch inteiro, entende tudo, e responde com calma: por que pagar pelo seu produto se eu já consigo o resultado sozinho?
A reação natural é defensiva. Você explica integrações, contexto, memória, casos de uso. E o cliente devolve a única frase que importa: eu entendi, mas o resultado eu já tenho.
Isso não é objeção de preço. É um sinal estrutural. O cliente parou de comprar acesso para descobrir valor. Ele agora testa o valor antes de comprar acesso. E o primeiro modelo de negócio a sentir isso foi o per-seat.
Per-seat venceu por um motivo que quase ninguém diz em voz alta.
Durante mais de vinte anos, cobrar por usuário foi a melhor decisão de monetização do software enterprise. E funcionou por uma razão específica: o valor de um sistema era proporcional ao número de pessoas que o usavam. Mais gente no CRM significava mais dados, mais histórico, mais integração com o fluxo da empresa. Cada usuário adicionava tanto quanto consumia.
Por baixo disso existia uma premissa mais profunda. O humano era o único caminho de avaliação disponível. Para saber se o produto resolvia o problema, alguém precisava abrir, usar e experimentar. Era assim que valor era descoberto.
Essa premissa sumiu. Hoje o comprador descreve o problema para um modelo, manda sua documentação e seu pricing, e pede uma comparação contra alternativas, incluindo construir internamente. O trial deixou de ser o único caminho de avaliação. Em muitos casos, deixou de ser o principal.
A premissa quebrou em dois lugares ao mesmo tempo.
O primeiro é estrutural. Quando parte do uso passa a ser mediada por agentes operando sem humano direto, o seat perde significado. Um agente executa milhares de operações em um dia. Qual é o seat desse agente? A previsibilidade que era vantagem do modelo vira fricção, porque o cliente sente que paga por capacidade que ora sobra, ora estoura.
Isso já aparece nos números. A Atlassian reportou queda em seat counts pela primeira vez não por perder clientes, mas porque agentes começaram a fazer o trabalho que antes exigia gente. O sinal chega disfarçado de churn de seat. Na prática, é substituição de trabalho humano por automação.
O segundo problema é competitivo. Quando o comprador usa um modelo de uso geral para avaliar se precisa do seu produto, ele compara com uma assinatura que resolve dezenas de problemas ao longo do dia. O custo marginal de tentar resolver mais um problema ali é baixo. Se o resultado que você entrega pode sair como subproduto de algo que o cliente já paga, seu argumento de seat dedicado enfraquece antes da primeira conversa.
O mercado precifica vulnerabilidade antes de precificar realidade.
A Chegg construiu um negócio de bilhões vendendo acesso pago a respostas. Quando estudantes passaram a obter as mesmas respostas de graça em modelos de IA, o trial virou substituição. A empresa tentou reagir lançando um produto baseado no mesmo tipo de modelo que o cliente já usava. Não funcionou. Ser wrapper do que o cliente acessa de graça não é estratégia.
O detalhe importante não é o colapso de uma empresa. É a velocidade. O mercado não esperou a substituição acontecer. Ele reprecificou a percepção de que o moat encolheu. Percepção se move antes da realidade, e o preço acompanha a percepção.
O que sobra quando o acesso deixa de ser o produto.
A pergunta certa não é literal. Apagar o código de qualquer empresa séria não resulta em zero. O ponto é outro: se hoje, com modelos públicos, um cliente competente tentasse obter o resultado que seu produto entrega sem comprar você, quanto ele conseguiria? E o que impede ele de conseguir o resto?
O que impede é o seu moat real. E ele quase nunca é o código.
Em abril de 2026, pesquisadores publicaram uma análise do código-fonte do Claude Code. A estatística que resume tudo: cerca de 1,6% corresponde à lógica de decisão da IA. Os outros 98,4% são infraestrutura operacional. Permissões, validação, recuperação, execução, controle. O modelo é a parte commodity dentro do produto. O moat é tudo que não é o modelo.
Sobram duas posições defensáveis. Contexto, que é o que o modelo não tem: dados de operação real, compliance auditado, integrações negociadas, memória acumulada na sua operação específica. E infraestrutura, que é o que o modelo não executa: a engenharia que garante que o resultado aconteça com previsibilidade, custo conhecido e validação antes de qualquer ação crítica.
A unidade de cobrança precisa virar o resultado.
Se o cliente consegue validar o resultado antes de comprar, cobrar por acesso perde sustentação. O que faz sentido é capturar parte do valor gerado. Você não cobra pela porta que o cliente abre. Cobra pelo que ele recebe do outro lado.
O Fin, agente de suporte da Intercom, cobra por ticket efetivamente resolvido. O cliente paga pelo problema resolvido, não pelo direito de tentar resolver. O alinhamento de incentivo é entendido em segundos, e a adoção cresce justamente porque o cliente consegue justificar o pagamento internamente.
Mas trocar a unidade de cobrança sem entender custo é como escalar no escuro. Em produto agêntico, margem não é consequência de contrato nem de desconto. É decidida na arquitetura: qual modelo roda em cada etapa, o que é validado antes de executar, quanto custa cada operação de ponta a ponta.
A conta que precisa fechar é simples de enunciar e difícil de sustentar. Receita por resultado menos custo por resultado. Se essa margem não for positiva e consistente, nenhuma estratégia de crescimento resolve. Crescer receita antes de entender custo por operação é o ponto onde a maioria dos produtos de IA quebra a margem sem perceber.
O diagnóstico cabe em uma pergunta.
Antes de qualquer reposicionamento, existe um teste, e ele precisa ser honesto. Retire mentalmente o modelo e o código do seu produto. O que sobra de concreto? Dado que só você tem, compliance implementado, integrações que exigiram negociação, clientes com processo construído em torno de você.
Se quase nada sobra, você não tem um moat. Você tem uma interface. E interface deixou de proteger valor no momento em que o resultado se separou do produto.
Esse é o começo do Outcome-Led Growth. Não como técnica de marketing, mas como mudança no que você mede, no que você constrói e no que você se permite cobrar. O resto do framework existe para operacionalizar essa virada. O ponto de partida, porém, é essa única pergunta.
Isso não é sobre IA. É sobre o que a IA virou.
Quando IA deixa de ser diferencial e vira infraestrutura, o jogo muda de lugar. Produto vira meio. Resultado vira fim. E quem controla o resultado tende a capturar valor.
O modelo conversa. A infraestrutura executa. E é exatamente nessa camada, entre contexto, validação e execução confiável em produção, que um resultado deixa de ser replicável com um prompt. Não é onde a maioria do mercado está olhando. É onde a bs3 trabalha.
A velocidade dessa transição depende de tecnologia, adoção e acaso. A direção não depende de nenhum deles.
Seu produto é resultado, ou apenas uma forma de chegar nele?