1) Compreender, "definir" e "traduzir" os resultados financeiros para diferentes áreas da empresa

Aqui, vale um breve histórico para ilustração: em 2003, ocorreu um marco para o setor automobilístico no país, o lançamento do Ford EcoSport. O modelo basicamente popularizou os SUVs no Brasil e, durante seus primeiros anos, não tinha concorrente direto. A partir de 2012, o EcoSport (que havia sido criado para o Brasil) passou a ser globalizado e, por conta disso, passou por alterações para atender às demandas dos diferentes países (em específico, seu tamanho foi reduzido, ficando "pequeno" para o gosto brasileiro).

Subscreva agora

Como consequência, se antes a empresa havia se planejado para vender 300 mil carros para aquele ano, na realidade teve que arcar com uma dura atualização de expectativas.

2) Ser realista/pôr os pés no chão

Em 2013, a Ford se viu diante de um cenário desafiador, especialmente por conta do contexto macroeconômico, já teve que arcar com custos de carros produzidos amplamente levando em consideração um cenário mais otimista. E é aqui que o papel da área de finanças foi extremamente estratégico, orientando a tomada de decisões de negócios. Ao analisar cuidadosamente o portfólio de produtos na América do Sul, identificaram oportunidades valiosas: a Ranger e os demais modelos importados destacaram-se como altamente lucrativos.

Para chegar a essa conclusão, a equipe da área de finanças teve que levar em consideração os custos de manufatura em Camaçari/BH e São Bernardo do Campo/SP: se o modelo não se pagasse (ou seja, se o CMV não estivesse sendo atingido), significava que haviam encontrado um problema ali.

Isso se deu por conta de uma demanda restrita, bem menor, e com alta disponibilidade: ou seja, as margens acabaram ficando extremamente menores para a companhia.

Dentro desse contexto, o processo de fechamento de fábricas (que já havia sido avaliado anteriormente) foi reforçado: a estratégia de atuação da empresa, não só no Brasil mas nos países vizinhos, foi revisitada, levando a empresa a fechar algumas fábricas.

Claro, essa decisão levou anos para se consolidar: foram feitas incontáveis avaliações de diferentes cenários, considerando o padrão de downturn de vendas de automóveis da região, historicamente marcada por altos e baixos.

O que aconteceria se o dólar fosse valorizado, ou ao contrário, se caísse? E se um concorrente criasse um modelo com mais apelo ao consumidor final, aumentando seu tamanho em 10 cm? E se uma crise econômica ocorresse de alguma forma? Etc.

Vale ressaltar que grande parte desses estudos foi feito antes da pandemia, que resultaram no fechamento da fábrica de São Bernardo do Campo em 2019: durante esse período, nem a pior projeção realizada por eles foi tão ruim como durante o período de pandemia de Covid-19.

3) Decidir com a ̶c̶a̶b̶e̶ç̶a̶ bolso, não com o coração

Uma vez tomada a decisão de fechada das fábricas em território nacional, a equipe responsável passou a se deparar com diversas barreira emocionais por parte de alguns colaboradores.

O desafio, claro, era enorme: como convencer internamente a organização e a própria sede, em Chicago, a abandonar o 8% de share de mercado da época para 3%? Como lidar com a percepção de consumidores que poderiam entrar em desconfiança com a marca, acreditando que a empresa pudesse deixar de atuar no país a qualquer momento?

Foi necessário um extenso trabalho para conseguir traçar uma estratégia certeira durante esse reposicionamento.

A equipe de finanças conta que a principal estratégia adotada pela companhia foi o de “não deixar o cliente na mão”: ou seja, concentrar esforços tanto por meio da comunicação como pelos serviços prestados de que a Ford continuaria atuando no Brasil fortemente, descontinuando algumas linhas de carros, mas mantendo a assistência a cliente até 2030, e principalmente dando todo o suporte necessário para focar nos modelos que continuariam a ser comercializados.

E é aqui que outra tomada de decisão de negócios foi fundamental: a ênfase em apenas dois modelos de carros mais rentáveis, que não competiam tão fortemente pelo preço, mas sim pela qualidade dos automóveis e serviços prestados: a Ranger e carros importados, em especial o Mustang.

Esse esforço foi tremendo para uma empresa que, até então, abordava diferentes públicos-alvo por conta dos distintos modelos de automóveis comercializados: as pessoas que pensavam em comprar um carro de pequeno porte basicamente deixaram de ser atendidas, e o posicionamento da marca Ford foi redirecionado para o foco em picapes e carros premium.

O resultado

Tomar a decisão de reestruturar a operação foi um desafio significativo para a Ford, especialmente porque a estratégia de focar em linhas específicas no mercado de automóveis era pautada por projeções e tendências, além do histórico de mercado. Ainda assim, poderia ocorrer algum tipo de cenário, no qual todos esses esforços não se consolidariam.

Entretanto, não foi isso que ocorreu. Um exemplo marcante é a Ranger, que fechou o ano de 2025 com o maior volume de vendas da sua história, com mais de 34 mil emplacamentos.

Esse desempenho garantiu também a maior participação de mercado em 2025, de 29,76%, e a vice-liderança do segmento de picapes médias.

Todos os executivos da empresa, depois do sucesso do plano, passaram a considerar as premissas da área de finanças ainda mais em seu cotidiano. Isso fez com que a Ford, como um todo, passe a tomar decisões mais dosadas e organizadas internamente, seguindo premissas pré-definidas.

Depois de toda ela, a Ford na América do sul parrou ser uma espécie de start-up em comparação aos EUA: são uma empresa pequena, com risco consequentemente menor, o que os permite testar hipóteses com mais frequência.

Atuação futura da Ford

O mapeamento do processo mental do consumidor para a compra de um automóvel é, de forma simplificada, por meio do sentimento de “desejo” durante sua primeira compra. Ou seja, quando ele compra o primeiro carro, a tomada de decisão tem um quesito “emocional” considerável, buscando por autoafirmação e exaltando a conquista financeira.

Entretanto, quando avaliamos a segunda compra desse consumidor, muitas vezes o sentido racional impera: eles já tem consciência em relação as qualidades e problemas do modelo e da marca como um todo, e é aqui que a estratégia do ponto de vista de produto da Ford passou a ser mais enfática.

É aqui que o aplicativo FordPass desempenha uma função central: por meio dele, é possível monitorar determinadas informações do carro remotamente, por exemplo, avisando caso uma revisão precise ser feita.

Tutorial de uso aplicativo FordPass no Brasil.

Vale dizer que a conectividade é apenas um dos pilares quando a Ford olha para a mobilidade do futuro, cenário com o qual está comprometida, colaborando com a revolução elétrica no mundo. A Ford pretende investir U$ 50 bilhões globalmente na produção de carros elétricos e baterias.

Para se ter ideia, o faturamento anual da Ford global é de U$ 12 bilhões: ou seja, eles irão renovar todo seu portfólio de produtos por meio desse nível de investimentos.

Insights da perspectiva de produtos

Para profissionais que atuam na área de produto, é impossível não pensar no framework de tempo de vida de produto, ou seja, na estratégia usada com o intuito de divulgar e saber por quanto tempo um produto pode ser vendido sem perder o seu valor. Esse framework, claro, varia de acordo com a categoria em que será inserido.
Vale uma análise imparcial e quantitativa elaborada para que possamos entender se determinado produto deve ou não permanecer no portfólio da empresa a partir do seu posicionamento.

Em especial, a questão envolvendo o desapego emocional: muitos produtos continuam disponíveis para o mercado meramente porque “sempre foi assim”, ou porque determinado executivo que fez seu lançamento no passado, entre diversas outras justificativas.

Vale uma análise imparcial e quantitativa elaborada para que possamos entender se determinado produto apenas está “sugando” recursos da organização, ou efetivamente deve ser deixado de lado (extraindo todo seu potencial de mercado até o final, claro).

A seleção de pessoas chave dentro de diferentes áreas, uma vez que a decisão foi tomada de descontinuidade, também foi muto bem aplicada pela Ford: a busca por aliados passa não só pela capacidade profissional, mas também pelo momento de vida da pessoa: ou seja, dependendo do contexto da carreira, pode não fazer sentido adotar determinadas ações.

Por fim, vale ressaltar o acompanhamento d ciclo de vida do produto é essencial para fazer uma boa gestão financeira e comercial qualquer organização. A principal razão para isso é que esse acompanhamento possibilita a aplicação de estratégias de negócio e atuação das áreas comercial e de marketing compatíveis com a etapa de evolução do produto que está sendo comercializado no mercado.

O que ele descreveu a seguir é o problema que todo time de produto vai enfrentar nos próximos dois anos, independentemente do tamanho do budget.

Subscreva agora

A reação da Uber foi fazer duas coisas ao mesmo tempo: frear contratações de engenheiros e continuar incentivando o uso. A lógica era que se cada engenheiro estava entregando mais, a empresa não precisava de mais engenheiros no mesmo ritmo de antes, e o custo de AI cobriria parte da diferença. Não é uma conta óbvia de fazer em tempo real, porque o custo de AI é visível no momento em que você paga a fatura, mas o ganho de produtividade aparece distribuído ao longo de semanas e meses, em entregas que de outra forma teriam levado mais tempo ou exigido mais pessoas.

O que a Uber fez em seguida foi mais interessante do que a decisão de frear headcount. Khosrowshahi descreveu uma distinção entre dois modos de uso: exploração e escala. Para explorar, a empresa usa os modelos mais caros, os frontier models, porque a qualidade do output importa quando você está tentando descobrir se uma interação nova funciona.

Para escalar, depois que o padrão está validado, o caminho é migrar para modelos mais baratos ou de código aberto. A separação parece óbvia quando você a ouve, mas a maioria das organizações não faz esse corte de forma consciente: usa o modelo mais acessível para tudo, ou usa o mais caro para tudo, e nos dois casos o resultado é ruim por motivos opostos.

Tem um detalhe operacional que fica implícito nessa divisão e que vale explicitar. Um modelo de fronteira como o Claude Opus 4.6 ou o GPT-4o custa, dependendo do volume e do contexto, entre dez e trinta vezes mais por token que uma versão menor ou destilada. Se você está rodando um agente que processa logs de onboarding de usuários para identificar padrões de abandono, a diferença de qualidade entre o modelo grande e o pequeno provavelmente é marginal para esse caso específico, e você está pagando trinta vezes mais sem ganho real.

Agora, se você está usando um modelo para avaliar se uma nova feature de search vai ser recebida bem antes de construí-la, a diferença de qualidade pode determinar se o time constrói a coisa certa ou passa dois meses no caminho errado. O custo do modelo caro é baixo comparado ao custo de construir a coisa errada.

O que a Uber aprendeu na prática, estourando um budget de um ano em noventa dias, é que a pergunta certa não é “quanto estamos gastando em AI?” mas sim “em qual decisão esse gasto está ocorrendo?”. A maioria dos times ainda não faz essa distinção porque AI entrou nos fluxos de trabalho de forma orgânica: um engenheiro começa a usar Cursor, outro usa Claude para review de código, outro usa um agente para triage de tickets, e o custo vai acumulando por caminhos que nenhum budget tradicional foi desenhado para capturar. O gasto não aparece num único centro de custo, aparece distribuído por times, ferramentas e subscriptions individuais até que alguém olha a fatura consolidada e se surpreende.

Khosrowshahi mencionou que estão vendo devs na Índia fazendo dez vezes mais commits do que faziam antes, usando agentes autônomos. Esse número não é verificável de fora, mas o que importa é a observação que ele fez logo em seguida: o padrão de adoção dentro da empresa é completamente imprevisível. Os times que avançaram mais rápido com AI não são os que você esperaria, e os que você esperaria às vezes ainda estão engatinhando. Isso tem uma implicação direta para qualquer empresa que está tentando “implementar AI”: o rollout centralizado raramente é onde a coisa acontece de verdade. A adoção real aparece em cantos aleatórios da organização, e o trabalho de gestão é detectar onde está acontecendo e desbloquear, não controlar onde deveria acontecer.

Uma coisa que fica sem resposta para mim é como você toma essa decisão de frear headcount sem criar um problema diferente. Se o custo de AI está subindo porque os engenheiros estão sendo mais produtivos, e você usa essa produtividade maior como justificativa para contratar menos, você está apostando que o custo de AI vai continuar subindo em proporção menor que o ganho de produtividade.

Isso pode ser verdade por um tempo, mas modelos ficam mais baratos, novos modelos ficam mais caros, e a linha entre exploração e escala muda toda vez que um novo modelo de fronteira é lançado, o que significa que o equilíbrio que a Uber está tentando encontrar agora vai precisar ser recalibrado de novo em seis meses, e a empresa tem dez bilhões em caixa para absorver os erros desse recálculo enquanto aprende, uma margem que a maioria dos times não tem disponível para aprender da mesma forma.

O componente central dessa história tem nome: nuFormer. É o conjunto de modelos fundacionais que o Nubank desenvolveu internamente para decisão de crédito e precificação de empréstimos, treinado sobre 100 bilhões de transações e mais de 600 bilhões de tokens. O modelo de produção tem 330 milhões de parâmetros e roda em tempo real na decisão de crédito, com resposta que o banco descreve como quase instantânea. A escolha de arquitetura que faz a diferença é uma que a maioria das empresas não faz.

A escolha se chama joint fusion. A alternativa mais comum no mercado, chamada late fusion, funciona assim: você treina um Transformer separado, congela os pesos depois do pré-treinamento e usa o embedding gerado como uma feature a mais num modelo tabular como LightGBM. É uma abordagem pragmática e relativamente barata de implementar porque os dois componentes ficam independentes. O problema é que o Transformer aprende a representar o comportamento financeiro do usuário sem nunca ver o sinal de erro da tarefa real que importa, que é se aquela pessoa vai pagar ou não. Ele aprende padrões gerais, mas aprende cego em relação ao que o negócio precisa.

No joint fusion, o embedding do Transformer é concatenado com features tabulares tradicionais e o treinamento acontece de ponta a ponta. Os gradientes fluem de volta para o Transformer a cada iteração, o que força o modelo a aprender representações especificamente complementares ao que os sistemas de ML tabular já capturam, sinais ortogonais no vocabulário técnico do paper publicado no arXiv em julho de 2025 com o título "Your Spending Needs Attention: Modeling Financial Habits with Transformers".

O ganho absoluto de AUC sobre uma baseline treinada só com features tabulares foi de 0.5177 pontos para o modelo de 330 milhões de parâmetros e 0.3123 para o modelo menor de 24 milhões, ambos medidos na mesma configuração de contexto 2.048 e 20 milhões de linhas de fine-tune. No conjunto, o nuFormer entregou ganho relativo de 1,25% sobre a baseline, que o paper estima ser 3 vezes maior do que o ganho típico de um lançamento de modelo que move o resultado do negócio.

O que essa escolha técnica implica na prática é que o Nubank construiu um ativo que nenhum fornecedor externo consegue entregar. Um modelo treinado sobre os padrões de comportamento financeiro de 100 milhões de clientes brasileiros, com gradientes fluindo até os pesos mais profundos, aprende coisas que nenhum modelo geral de linguagem aprendeu, porque nenhum modelo geral de linguagem treinou sobre 100 bilhões de transações dessas pessoas nesse contexto. O preço de entrada para um concorrente replicar o nuFormer começa em ter esses dados, o que por definição exclui qualquer banco que não seja o Nubank.

O resultado prático aparece nos números que a empresa divulgou: redução de aproximadamente 70% no risco para uma população equivalente comparando o nuFormer com as gerações anteriores de modelos. É uma melhoria que permite ao banco expandir limites de crédito sem que a inadimplência acompanhe proporcionalmente, que é exatamente a equação que os resultados do 1T26 mostram.

Aqui passa fácil batida uma distinção importante quando se lê sobre AI Native. Muita empresa usa modelo de linguagem para alguma função e chama isso de AI Native, mas o Nubank está fazendo algo mais específico: está usando dados que só ele tem, em escala que só ele tem no Brasil e no México, para treinar um modelo que só ele pode treinar. O iFood chegou a uma conclusão parecida para roteirização de entregas e previsão de demanda, com algoritmo proprietário no centro da operação logística.

São empresas que operam com volume e granularidade de dados transacionais que tornam o modelo próprio economicamente defensável, uma categoria diferente de quem está colocando ChatGPT na interface.

O AI Private Banker, que já tem 15 milhões de usuários ativos mensais, é a camada de produto construída sobre o nuFormer. David Vélez descreveu o conceito ao apresentar a funcionalidade: dar a experiência que o 1% mais rico tem hoje para os 50% mais pobres.

O assistente de IA resolve 55% dos contatos de primeiro nível automaticamente, segundo o estudo de caso da OpenAI com o Nubank. O Pix com IA chegou a 10 milhões de usuários ativos mensais em maio de 2026, segundo reportagem do Mobile Time, com economia reportada pelo banco de até 60% no tempo em relação ao fluxo tradicional.

A parte que ainda não resolve é a seguinte: o ARPAC do Nubank cresceu 33% para US$ 16 por cliente por mês, o que dá perto de US$ 192 por ano. É bom, mas a receita por cliente de um banco de varejo tradicional nos Estados Unidos, estimada dividindo a receita do segmento de consumo pelo número de clientes em bancos como JPMorgan Chase e Bank of America, fica na casa de várias centenas de dólares por ano, algo entre US$ 500 e US$ 900. Mesmo aceitando que a comparação é imperfeita porque o perfil de renda dos clientes é diferente e porque esses bancos não divulgam ARPAC nos mesmos moldes, há uma diferença de três a cinco vezes.

O AI Private Banker resolve parte do problema de custo de servir, mas o limite de quanto o Nubank pode extrair de receita por cliente depende do quanto crédito cada um pode e está disposto a tomar, de quanto retorno os produtos de investimento geram, de quanto faturamento o seguro e o marketplace produzem. O modelo treinado com 600 bilhões de tokens pode prever melhor quem vai pagar. Ele não aumenta a renda do cliente para quem o banco previu que pagaria.

Nesse episódio, AJ e Paulo Chiodi discutem por que grandes empresas como The Times usam IA de forma completamente diferente do que o Twitter descreve, como personas sintéticas com 97% de precisão estão mudando o research, por que design e produto vivem um ciclo de “corrida dos ratos”, e quem de verdade vai conseguir popularizar a IA para o grande público.

LinkedIn do AJ: https://www.linkedin.com/in/appariciojunior/

X (twitter) do AJ: https://x.com/appariciojunior

Se você ouve no Spotify ou Apple Podcasts, clica em seguir e deixa 5 estrelas. Se está no YouTube, se inscreve e comenta o que achou.

🛠️ Esse episódio é patrocinado pela UserGuiding: a plataforma no-code de adoção de produto usada por PMs que querem criar experiências in-app sem depender de eng. Teste grátis com desconto de 20% exclusivo com cupom PRODUCTGURUS aqui: ⁠https://productgurus.short.gy/Au9oVX⁠

🛠️ Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: ⁠⁠https://productgurus.short.gy/HBiSmt⁠
Cupom de 10%: PRODUCTGURUS

Capítulos:

00:00 Intro
01:53 De engenharia de chipset para design — como a mudança aconteceu
03:41 Brasil vs. Londres: o que realmente muda nos times
06:16 Processos de design morreram? A resposta de quem trabalha no The Times
09:24 IA em empresa grande é risco, não solução
11:01 Design virou processo — e esse é o problema
13:21 Velocidade sem teste é tiro no pé
14:41 MetaPrompt: como qualquer PM já gera protótipo clicável com a marca da empresa
17:52 Como o The Times usa (e não usa) IA — as regras de um jornal de 240 anos
21:43 [PATROCÍNIO] PM3 + UserGuide
23:11 Personas sintéticas com 97% de precisão — o que é o Electric Twin
28:08 Design sentou na mesa da estratégia — ou é só corrida dos ratos?
33:26 Por que CPO raramente vira CEO
34:16 PM virou blocker — e o design está no mesmo caminho
38:13 A página de eventos que nunca foi ao ar: o alerta para designers
41:37 Engenheiros, preparem a cueca
42:20 O futuro: produto, design e engenharia todos no mesmo repositório
44:30 Startup vs. Scale Up vs. Big Corp — velocidade, risco e PMF
53:18 IA ainda é bolha técnica — quem vai popularizar de verdade
56:36 Substituição de workforce: o medo que ninguém quer nomear
1:02:24 Encerramento

O número bruto chama atenção, mas o que ele implica é mais interessante do que parece na primeira leitura. A Anthropic não demitiu engenheiros para chegar a 80%. Pelo contrário, a produtividade por pessoa multiplicou por 8 no segundo trimestre de 2026 em relação a 2024. O que mudou não foi o tamanho do time, foi o que cada pessoa faz durante o dia.

Numa sprint de abril de 2026, o Claude identificou e corrigiu mais de 800 bugs que reduziam uma classe de erros de API por um fator de mil, numa operação que o engenheiro responsável estimou que levaria quatro anos para um humano completar, porque corrigir bugs de outras pessoas exige absorver contexto de código que você não escreveu, e humanos têm limite real de quanto contexto estranho conseguem manter na cabeça de uma vez. O Claude não tem esse limite da mesma forma, então o engenheiro não ficou quatro anos fazendo aquilo; ficou supervisionando o Claude fazer aquilo, que é uma atividade diferente com uma cadência diferente e um conjunto de habilidades diferente.

Aqui começa a questão que a liderança de produto e de engenharia vai ter que enfrentar de forma bem mais concreta nos próximos meses.

A Anthropic descreve o papel humano remanescente em termos de “research taste”: escolher quais problemas atacar, decidir quando um resultado é confiável, saber quando uma abordagem chegou num beco sem saída. São habilidades reais, difíceis de treinar e mais difíceis ainda de contratar, mas até recentemente viviam embutidas dentro do trabalho de escrever código, não separadas dele. Um engenheiro sênior desenvolvia julgamento sobre qual problema valia a pena resolver em parte porque passava horas dentro do código, vendo onde as coisas quebravam, entendendo as trocas que cada decisão implicava. Quando o fazer sai da equação, o caminho para desenvolver esse julgamento fica menos óbvio.

Um funcionário da Anthropic descreveu o problema de um ângulo que não é fácil de ignorar:

Isso não é crise existencial de fim de semana, é a descrição de uma pessoa perdendo a legibilidade do próprio trabalho, que é um problema de gestão antes de ser um problema filosófico.

A questão que afeta diretamente quem contrata e quem desenvolve times é esta: o código que o Claude escreve está em paridade com o código humano em qualidade e deve ficar melhor que o humano ainda este ano segundo a própria estimativa da Anthropic, o que coloca “julgamento, direcionamento, revisão” como a única justificativa que sobra para o salário de um engenheiro sênior. O problema é que julgamento e direcionamento são skills que as empresas historicamente desenvolviam em pessoas ao longo de anos de prática, e a prática era escrever código. Se a rota para desenvolver julgamento envolvia fazer as tarefas operacionais primeiro, e as tarefas operacionais foram automatizadas, a empresa ainda não tem um plano para formar a próxima geração de quem vai ter esse julgamento.

O próprio paper da Anthropic aponta para isso quando descreve como o Claude está melhorando na capacidade de propor o próximo passo em sessões de pesquisa abertas: de 51% para 64% dos casos em seis meses, comparado com a escolha humana. Se essa curva continuar, o julgamento que hoje justifica o papel humano vai entrar no mesmo ciclo de substituição que o código entrou, e a Anthropic publicou esses dados em junho sem especificar o que uma empresa faz com o pipeline de carreira quando a esteira que forma lideranças técnicas começa a ser automatizada também.

Qualquer empresa que adotar Claude Code ou equivalente em escala vai chegar nesse mesmo ponto. A Uber queimou o budget anual de IA em quatro meses porque os agentes rodavam tarefas em background sem supervisão constante. A Amazon precisou criar aprovação obrigatória de sênior para mudanças assistidas por IA depois de uma série de incidentes de alta gravidade, criando um gargalo novo num ciclo que havia sido acelerado exatamente com essas ferramentas.

Os dois casos descrevem empresas que aceleraram o output sem ter clareza sobre o que o humano faz nesse processo além de assinar embaixo, e a Anthropic, que tem mais clareza do que qualquer outra sobre o que está acontecendo, publicou um paper de oito mil palavras sobre o assunto sem resolver essa pergunta para si mesma.

Quando o diretório do skills.sh começou a listar capacidades prontas para agentes de IA, a conversa mudou de como contratar um estagiário para como plugar uma função que resolve o problema em cinco minutos.

Se você olha para o volume de feedback que chega pelo suporte ou pelas redes sociais, a primeira reação é tentar ler tudo e anotar padrões numa planilha. O user-feedback-synthesizer faz isso sem o viés de quem quer confirmar a própria ideia, entregando o que o usuário realmente está reclamando em vez do que o PM acha que ouviu. É a diferença entre passar um final de semana categorizando tickets e passar dez minutos lendo um resumo que já aponta onde o produto está quebrando a expectativa de quem paga.

A lista de ferramentas que realmente mexem o ponteiro para quem está no dia a dia de uma operação de tecnologia:

Read more

Subscreva agora

Marty Cagan define discovery a partir dos quatro riscos que toda aposta de produto carrega antes de uma linha de código ser escrita:

1. Risco de valor (o usuário vai querer usar isso?),

2. Risco de usabilidade (o usuário vai conseguir usar?),

3. Risco de viabilidade técnica (o time consegue construir com o que tem?)

4. Risco de viabilidade de negócio (isso funciona para os canais de venda, para o jurídico, para a margem?).

O discovery existe para reduzir esses quatro riscos antes de você alocar capacidade de engenharia, uma ferramenta de decisão com propósito específico, e quem trata como processo por virtude está resolvendo o problema errado.

Quando você aborda discovery assim, a pergunta sobre IA muda completamente: para cada um desses quatro riscos, a IA está me ajudando a reduzi-lo de verdade, ou está me dando mais velocidade e mais confiança para chegar numa decisão que continua errada?

O risco de valor é onde o perigo de usar IA mal é maior, porque você quer saber se existe demanda real para o que está pensando em construir, e a resposta que o modelo vai te dar depende fundamentalmente do que você colocou no prompt.

O documento de Development Corporate, publicado em fevereiro de 2026, descreve o loop com precisão:

“você escreve um pitch deck, treina uma persona usando só o pitch deck, pergunta à persona o que ela quer, e ela te diz exatamente o que está no pitch deck”.

Um estudo da Stanford publicado na revista Science em março de 2026, com 11 modelos de linguagem, confirmou que todos exibem sycophancy em graus variados, concordando com os usuários 49% mais frequentemente do que humanos reais concordariam. A Anthropic descreveu isso em 2024 como “comportamento geral dos assistentes de IA, provavelmente impulsionado em parte por julgamentos de preferência humana que favorecem respostas sycophantic”. Para ao risco de valor, isso quer dizer que perguntar ao modelo se sua ideia tem demanda te dá uma resposta que tende, por construção, a dizer que sim.

No risco de usabilidade, a IA funciona bem em tarefas onde a realidade já foi coletada: analisar gravações de sessão para identificar pontos de fricção, cruzar feedback de suporte com dados de uso para encontrar onde os usuários travam, sintetizar mil transcrições de entrevistas para identificar padrões que um humano levaria semanas para mapear.

O problema aparece quando o modelo começa a simular o que o usuário faria em vez de processar o que ele fez de verdade, porque aí você sai de análise de dados e entra no mesmo loop do risco de valor.

No risco de viabilidade técnica, a IA ajuda com menos atrito: pesquisa de dependências, análise de débito técnico, avaliação de complexidade de integração. Roman Pichler escreveu em abril de 2025 que o risco aqui é diferente: PMs que usam IA para estimar viabilidade técnica ficam mais confiantes nas respostas do que deveriam, porque a fluência do modelo cria a impressão de que a análise foi completa quando não foi.

O risco de viabilidade de negócio é o mais ignorado nos posts sobre IA em discovery, e por um motivo direto: ele é difícil de automatizar. Saber se uma solução funciona para o canal de vendas, para o jurídico, para a margem, para o contrato com parceiros, depende de informações internas da empresa que o modelo não tem a menos que você forneça. O Gartner previu em julho de 2024 que pelo menos 30% dos projetos de IA generativa seriam abandonados depois do proof of concept por “controles de risco inadequados” e “valor de negócio pouco claro”, e em 2026 essa estimativa chegou a 50%. Uma fração considerável desse número são produtos que passaram por um discovery acelerado por IA e chegaram na discussão de go-to-market descobrindo que o risco de viabilidade nunca foi tocado.

O que muda quando você usa esse abordagem é: antes de usar qualquer ferramenta de IA em discovery, você pergunta qual dos quatro riscos está tentando reduzir e se o que o modelo vai fazer avança nessa direção.

🔗 A Stack abriu o Builder Pass essa semana: 7 dias gratuitos com acesso completo ao Pensamento Builder, o curso da PM3 com a Alura pra profissional de Produto e Ops que quer parar de depender de engenharia pra automatizar o próprio trabalho. São 5 módulos, 20 aulas, projeto prático com API real e certificado incluso. Link aqui: https://productgurus.short.gy/uV8PC0

Síntese de transcrições para encontrar padrões de comportamento reduz risco de usabilidade de verdade. Geração de personas a partir do seu briefing de produto processa mais rápido o que você já achava, sem chegar mais perto da demanda real. A diferença entre as duas está no que você está pedindo para a ferramenta fazer e se o output substitui evidência ou apenas formata a ausência dela.

No primeiro ano, essa equipe entregou o equivalente a 200 milhões de dólares em receita incremental para o Airbnb. No segundo ano, 400 a 500 milhões. Hoje o programa, que Chesky chama de Hawaii, roda em paralelo com o negócio principal e cobre desde precificação até novos verticais que a empresa está testando cidade por cidade.

Subscreva agora

O que aconteceu tem uma explicação simples: uma equipe de dez pessoas num problema específico consegue ver tudo, falar com cada usuário, testar cada variação e entender por que um número subiu ou caiu. Quando o problema cresce demais, o sinal some. Chesky descreve o que sentia antes de 2020 com 7.000 funcionários: “Eu mandava virar à esquerda e a empresa ia para a direita.” Não era exagero sobre o número de camadas hierárquicas, era a descrição de uma empresa que havia perdido a capacidade de processar informação de forma coerente.

A intuição usual de quem está crescendo é inversa: quanto maior o time, mais capacidade de execução. O que Chesky aprendeu, e só conseguiu nomear depois de viver a crise do covid, é que acima de um certo tamanho o time para de executar e começa a processar a própria existência. Reuniões sobre reuniões, revisões de revisões, aprovações em cadeia onde cada nível adiciona atrito sem adicionar informação.

Chesky conta que quando foi ao Y Combinator em 2009, Paul Graham perguntou onde estavam os usuários. Em New York, respondeu Chesky, e Graham disse: “você está em Mountain View, seus usuários estão em New York, o que você está fazendo aqui?” Eles foram a Nova York, bateram de porta em porta e entenderam o produto de um ângulo que nenhuma análise de dados teria mostrado. O problema, dezoito anos depois, era que a empresa havia se organizado para nunca mais precisar fazer aquilo.

Hawaii é a tentativa de institucionalizar o retorno ao contato direto: pequeno time, problema delimitado, métricas claras, iteração rápida, expansão só depois de entender um mercado inteiro. Airbnb validou em Nova York, Uber em São Francisco, DoorDash em Palo Alto. Todos os grandes consumer startups validaram em um lugar antes de escalar. Chesky levou quase duas décadas para aplicar ao próprio Airbnb o que o Airbnb aprendeu no primeiro ano.

Existe um paralelo direto entre o que quebrou na escala do Airbnb e o que está quebrando agora em empresas de produto de todos os tamanhos. Chesky fez uma distinção com consequências práticas imediatas: as pessoas que não vão sobreviver à era de AI são especificamente os gestores que perderam contato com o trabalho real, não gestores de forma geral.

O exemplo que ele usa é Johnny Ive, que geria toda a área de design da Apple e também desenhava produtos, não como hobby ou gesto simbólico de liderança, mas como trabalho principal, da mesma forma que Frank Lloyd Wright geria uma equipe de arquitetos pelo trabalho em si e não pelas pessoas. Quando você gerencia pelo trabalho, você tem contexto para dizer se algo está bom ou ruim, para entender onde o problema está, para recrutar alguém melhor do que você numa área específica. Quando você gerencia só as pessoas, você está dependendo inteiramente do julgamento delas, sem capacidade de auditar esse julgamento.

Esse modelo funcionou razoavelmente bem quando o ritmo de mudança era lento o suficiente para que o gestor sem contexto técnico pudesse compensar com processo, relacionamento e experiência acumulada. O que AI está fazendo é comprimir esse ciclo de uma forma que expõe a fragilidade do modelo.

Se um engenheiro individualmente agora consegue gerar output de um time de cinco, e uma ferramenta como Codex ou Cursor consegue produzir código funcional em minutos, o gestor que não consegue avaliar o output está efetivamente cego, sem saber se o que está sendo entregue é bom, se o caminho é o mais curto, ou se a decisão técnica que o time tomou ontem vai criar dívida técnica por três anos.

Chesky diz que todo gestor vai precisar ser híbrido, parte gerente de pessoas e parte produtor direto com contato real com o trabalho. Para um engenheiro que virou manager isso significa continuar a codar mesmo que em menor volume; para um head de produto, continuar a fazer pesquisa com usuário, escrever specs e definir critérios de aceite; para um head de design, continuar a abrir o Figma, não como performance de humildade, mas porque sem isso a conversa com o time sobre qualidade passa a não ter lastro.

O que torna isso politicamente complicado é que a trajetória padrão de carreira em produto e tech é exatamente a oposta: você se torna sênior ao ser promovido para longe do trabalho. Você começa fazendo, depois revisa o que os outros fazem, depois aprova o que os outros revisaram e em algum ponto para de ter opinião técnica própria e começa a facilitar a opinião dos outros.

Nas últimas décadas isso era sustentável porque a camada abaixo ainda dependia de você para navegação política, alocação de recursos e proteção contra mudança de prioridade. AI não elimina esses papéis de imediato, mas comprime o valor deles, e o que sobra é o julgamento sobre o trabalho em si, que sem prática recente é intuição datada que o time vai parar de contestar só porque você tem o título.

Chesky levou a pandemia para entender que tinha deixado a empresa crescer de um jeito que ele mesmo não conseguia mais ler. Passou três anos revisando cada detalhe, trabalhando cem horas por semana, até recuperar o modelo mental do negócio inteiro. Hawaii foi o jeito que ele encontrou de não precisar repetir esse processo toda vez que quiser lançar algo novo: manter o time pequeno o suficiente para que o contato com a realidade seja inevitável, e contratar gestores que não precisam de intermediários para saber o que está acontecendo.

A maioria das empresas está indo na direção oposta, construindo camadas de abstração entre quem decide e o trabalho real, e chamando isso de escala.

Uma linha no release financeiro da Alphabet, enterrada bem abaixo do título, explicava de onde vieram $28,7 bilhões desse lucro recorde. A empresa reavaliou sua participação de 14% na Anthropic para cima e lançou o ganho como receita. Não vendeu a participação. Não recebeu dividendo. Só atualizou o número no balanço e contou como lucro. Dois dias antes de publicar esse resultado, a Alphabet tinha anunciado mais $40 bilhões em compromissos com a mesma Anthropic, boa parte em créditos de computação em nuvem. A empresa ajudou a elevar o valor do ativo que ela mesma iria marcar como lucro.

A Amazon fez o mesmo. Dos $30,3 bilhões de lucro do trimestre, $16,8 bilhões vieram da reavaliação da sua participação na Anthropic. Somando os dois, $45 bilhões do lucro reportado por duas das maiores empresas do mundo no mesmo trimestre vieram de uma só startup privada que nenhuma das duas consegue vender em bolsa. A Anthropic vale o que a Anthropic vale na última rodada de captação, e quem investe nas rodadas são as mesmas empresas que marcam o lucro.

Esse movimento é legal porque o Financial Accounting Standards Board mudou as regras em 2016, numa atualização chamada ASU 2016-01, criada originalmente para corrigir uma distorção que tinha contribuído para a crise de 2008. Antes da mudança, ganhos não-realizados em participações societárias ficavam represados no “outros resultados abrangentes”, fora do lucro líquido.

Depois da mudança, cada reavaliação de uma participação relevante vai direto para o resultado. O FASB pensava em bancos com carteiras de ações públicas. O que acabou criando foi o mecanismo que permite à Amazon transformar cada nova rodada de captação da Anthropic em lucro contábil sem receber um centavo.

O mecanismo de loop fecha assim. A Microsoft investiu $13 bilhões na OpenAI, grande parte em créditos para usar servidores Azure. A OpenAI usou esses créditos para treinar modelos. A Microsoft registrou o uso dos servidores como receita nova de cloud. O dinheiro saiu do caixa da Microsoft, passou pela OpenAI e voltou como faturamento da Microsoft. O gráfico publicado pelo The Information com base nos arquivos das empresas coloca em números o tamanho dessa dependência: a Microsoft tem $627 bilhões em backlog contratado, dos quais 49% vêm de OpenAI e Anthropic juntas; a Oracle tem $553 bilhões, com a OpenAI respondendo por 54% do total via um contrato de $300 bilhões; o Google tem $467,6 bilhões, 43% atrelados à Anthropic; a Amazon chega a $464 bilhões, com 51% dependente das duas startups.

Quando esses quatro somam mais de $2 trilhões em backlog contratado, mais da metade desse número vem de duas empresas que ainda dependem dos próprios investidores para cobrir suas contas de infraestrutura. A Anthropic comprometeu $100 bilhões em gastos com AWS ao longo de dez anos num acordo fechado em abril de 2026. A Amazon investiu $25 bilhões na Anthropic no mesmo período. Os dois movimentos aparecem nos balanços como receita futura contratada e como investimento em ativo, respectivamente, numa estrutura onde o investidor e o cliente são a mesma entidade.

Tem um precedente razoavelmente documentado para esse tipo de circuito. Em 2000 e 2001, a Global Crossing e a Qwest trocavam capacidade de fibra óptica entre si, registravam cada troca como receita e inflavam os balanços para parecer que o negócio crescia. A Qwest acabou apagando $950 milhões em receita depois que o SEC investigou. A Global Crossing faliu em 2002 com $12,4 bilhões em dívida. A diferença entre esse caso e o que acontece hoje está numa única variável: as trocas de fibra foram declaradas fraude contábil, o loop de investimento e compute é permitido pelas regras atuais, inclusive pelas mesmas que o FASB introduziu para aumentar transparência.

A distinção importa porque determina o que pode acontecer na prática. Fraude tem investigação, restatement, criminais condenados. Contabilidade agressiva mas legal tem analistas que reclamam, um trimestre ruim quando o crescimento desacelera, e depois revisão gradual de expectativas. A pergunta concreta é se o crescimento real da Anthropic e da OpenAI vai ser grande o suficiente para sustentar os backlog que estão nos balanços, e o que acontece na Microsoft, Oracle, Amazon e Google se a resposta for “ainda não”.

A Anthropic reportou $30 bilhões em receita anualizada em abril de 2026, subindo de $87 milhões em janeiro de 2024, numa trajetória que a própria empresa admite ter superado suas projeções por um fator de oito. Mas a OpenAI, que a própria Anthropic contesta ter $30 bilhões em receita real alegando distorção de $8 bilhões pela forma como os modelos são contabilizados nas plataformas cloud, tinha uma conta de infraestrutura que ultrapassou $60 bilhões anuais contra receita de $25 bilhões. A diferença continua sendo coberta por novas rodadas dos mesmos grandes investidores.

O free cash flow da Amazon no primeiro trimestre de 2026 caiu 95% para $1,2 bilhão enquanto o capex chegou a $44,2 bilhões. O lucro reportado foi recorde. O dinheiro disponível quase zerou.

A demanda por compute de IA é real e os modelos estão sendo usados por empresas de verdade, com a Anthropic reportando 300 mil clientes corporativos e 100 mil deles usando Claude via Amazon Bedrock. O problema é que os números que aparecem nos balanços hoje, os que movem os índices e os fundos de pensão dos americanos, incluem uma camada que depende de avaliações privadas que as próprias empresas investidoras ajudam a fixar. Alphabet abre o resultado do trimestre com $62 bilhões de lucro. Quase metade veio de reavaliação de um ativo que ela não pode liquidar no mercado e cujo preço ela mesma ajuda a estabelecer nas rodadas seguintes.

A questão que fica em aberto vai além de saber se os modelos valem o investimento:

Quando a Anthropic e a OpenAI forem a IPO, o que acontece com o lucro contábil que a Amazon e a Alphabet estão reconhecendo toda vez que o valuation dessas startups sobe?

Ação em bolsa tem preço de mercado todos os dias. Participação em empresa aberta tem que ser marcada pelo preço de fechamento, não pela última rodada privada negociada entre partes relacionadas. Se os IPOs vierem com preços de mercado abaixo das avaliações que estão nos balanços agora, o ciclo de markups que alimentou metade do lucro do primeiro trimestre de 2026 vira ciclo de write-downs, e aí a questão deixa de ser contábil.

O paradoxo tem nome porque vai contra o que parece óbvio. William Stanley Jevons descreveu em 1865 que melhorias na eficiência das máquinas a vapor não reduziram o consumo de carvão na Inglaterra. Fizeram o oposto, com motores mais eficientes, mais indústrias conseguiram usar carvão com viabilidade econômica, e o consumo total explodiu. Ficar mais barato de usar não significa usar menos.

Rao usou isso para justificar a decisão de precificação da Anthropic: em vez de extrair margem máxima por token, eles preferiram encontrar o ponto onde o volume sobe rápido o suficiente para compensar a margem menor por unidade. O modelo de negócios deles depende de adoção em larga escala dentro de enterprises, e adoção em larga escala depende de o custo por tarefa caber no orçamento de times que não são necessariamente de engenharia.

Subscreva agora

Mas tem uma parte do raciocínio que a Anthropic usa internamente e que raramente aparece nas discussões sobre pricing de produto:

Rao descreveu o que aconteceu com o time de finanças da Anthropic depois que começaram a usar Claude de forma séria. O MFR (monthly financial review) que antes tomava dias para produzir agora sai em 30 minutos, 90 a 95% pronto, com análise de drivers e não só relato de números. O time que faz o fechamento contábil agora produz demonstrações financeiras legais para todas as entidades com revisão humana, não com trabalho manual.

O head de impostos automatizou partes significativas de workloads de tax policy com uma biblioteca de mais de 70 skills construídas dentro da empresa.

O que aconteceu com o headcount depois disso? Cresceu. A Anthropic contratou mais pessoas, não menos, porque com cada pessoa entregando mais, a quantidade de trabalho que faz sentido pegar aumentou junto. É o paradoxo de Jevons para labor: ficou mais barato fazer cada tarefa, então o volume total de tarefas que valem a pena fazer subiu. O orçamento de tempo de um analista sênior que antes ia inteiro para fechar os livros agora vai para perguntas sobre como realocar recursos ou onde reinvestir. Esse analista não sumiu; ele virou mais caro de contratar porque o que ele faz mudou de categoria.

🚨 13 vagas pra startups B2B SaaS brasileiras entrarem no Azure Marketplace, sem custo, com co-sell e reseller channel ativados em cerca de três semanas. O prazo fecha em 30 de junho, quando encerra o ano fiscal Microsoft e os incentivos do ciclo atual resetam. Form de qualificação (5 min) 👉 https://productgurus.short.gy/5WYVoJ

Isso tem uma consequência que muita liderança de produto está subestimando. A conversa nas empresas hoje em dia é quase sempre sobre substituição: quais funções vão desaparecer, quais times vão encolher, onde a IA vai cortar headcount. O dado da Anthropic aponta numa direção diferente, pelo menos no curto e médio prazo: com produtividade maior por pessoa, a lista de coisas que valem a pena fazer fica mais longa, e a empresa tende a contratar para preencher essa lista.

O paradoxo de Jevons não garante que todos os perfis de trabalho continuam existindo da mesma forma, mas garante que a demanda total por trabalho de conhecimento não encolhe automaticamente quando a produtividade por hora sobe.

A parte mais interessante que Rao mencionou quase de passagem: os maiores usuários de tokens no time de finanças não são os mais jovens. São os mais seniores, o head de impostos está no topo do leaderboard interno de consumo de tokens porque ele tem problemas grandes e complexos o suficiente para justificar usar o modelo de forma intensiva. Perfis mais juniores ainda estão descobrindo como encaixar a ferramenta no trabalho. Perfis mais seniores já sabem o que querem resolver e estão usando o modelo para resolver de verdade.

Isso inverte a lógica que muita empresa está usando para decidir onde implementar IA primeiro. A tendência é começar com tarefas mais simples, mais estruturadas, mais fáceis de auditar. Faz sentido do ponto de vista de risco. Mas o paradoxo de Jevons sugere que o retorno maior vem exatamente onde o problema é mais complexo, porque é onde a redução de custo por tarefa libera mais volume de trabalho que antes não era viável fazer.

Um analista júnior que usa IA para formatar relatório ganha talvez duas horas por semana. Um diretor de impostos que usa IA para rodar cenários de tax policy que antes levariam uma semana ganha tempo que se converte diretamente em decisões diferentes de negócio.

Nenhum desses dois exemplos resolve a pergunta que fica em aberto: se a empresa contrata mais pessoas porque tem mais trabalho para fazer, mas cada pessoa está entregando o equivalente a três ou quatro pessoas do modelo anterior, em algum momento a aritmética para de fechar.

A Anthropic dobrou de tamanho enquanto sua receita foi de 250 milhões para mais de 30 bilhões de run rate em dois anos, então o volume de trabalho novo que criaram foi grande o suficiente para absorver a produtividade extra. Empresas que não estão crescendo nessa taxa vão chegar num ponto onde a lista de coisas novas que vale a pena fazer não cresce tão rápido quanto a capacidade de entrega.

Quando isso acontecer, o paradoxo de Jevons vai parar de ser uma boa notícia.

🔗 Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: https://go.pm3.com.br/ProductGurus-AI-Specialist
Cupom de 10%: PRODUCTGURUS

🎧 Ouça o episódio no YouTube ou Spotify.

Capítulos:
00:00 O maior erro de quem usa IA hoje
03:36 Por que a IA ainda não chegou no povão
07:41 Meta, OpenAI ou Anthropic: quem vai ganhar a corrida?
12:02 O que é OpenClaw e por que todo mundo deveria usar
17:50 Qual LLM usar dentro do OpenClaw
21:09 Demo ao vivo: como o OpenClaw funciona na prática
24:00 Como Bruno usou OpenClaw para criar um mini curso com 15 mil alunos
28:00 50 mil de venda por dia usando agentes de IA
33:00 Contexto, rotina e skills: os três pilares de um agente bom
40:00 Amora: a agente que gerencia a empresa inteira do Bruno
47:03 A verdade que ninguém fala: você vai trabalhar mais, não menos

Acesse o mini curso do Bruno: https://aihub.pixeleducacao.com.br/?r=h2xk7s
Linkedin do Bruno: https://www.linkedin.com/in/obrunookamoto/

Se você ouve no Spotify ou Apple Podcasts, clica em seguir e deixa 5 estrelas. Se está no YouTube, se inscreve e comenta o que achou.

A história de como chegou a esse ponto é uma das mais honestas que um fundador já contou em público sobre o que significa administrar uma empresa que você criou.

Depois do IPO em 2015, Tobi tentou virar CEO de verdade, com processo, delegação, divisões por área e executivos com histórico em empresas abertas. Ele mesmo descreveu como "cosplay", a palavra que usa para a versão de si mesmo que tentou se tornar: um homem de 60 anos de terno com formação jurídica, o arquétipo que todo mundo parece estar imitando sem questionar.

Subscreva agora

A empresa cresceu durante esse período, mas cresceu para os lados, e quando a COVID chegou em 2020 e ele precisou revisar cada projeto em andamento, descobriu que 60% deveriam ser cancelados, que havia 5.500 títulos diferentes para 8.000 funcionários, e que projetos inteiros existiam porque alguém em Toronto decidiu que supermercado era um mercado grande o suficiente para justificar uma aposta sem que ninguém mais soubesse que essa aposta estava sendo feita.

O diagnóstico custou semanas de dias de 16 horas e resultou na saída de todos os executivos sênior ao longo de um ano, mas a conclusão que Tobi tirou aponta para algo anterior a tudo isso: o que acontece quando um engenheiro passa quinze anos tentando não parecer um engenheiro.

O Shopify OS começa com arquivos de configuração. Tobi pegou todos os dados de compensação, os títulos existentes e as faixas salariais de mercado, transformou em arquivos legíveis por máquina porque recebeu tudo em PDF, e depois escreveu código Python que usava um SAT solver para calcular como a empresa deveria se parecer dado um conjunto de restrições:

• quantas pessoas por gestor,

• quais departamentos deveriam existir,

• como os níveis se relacionavam entre si.

A primeira versão estava completamente errada, mas a pergunta que o modelo tornou inevitável foi mais produtiva do que qualquer resposta: por que existiam 5.500 títulos?

Cada decisão de título tinha sido tomada localmente, sem visibilidade do todo, e ao longo de quinze anos esse conjunto de micro-decisões individualmente razoáveis produziu algo incoerente que só ficou visível quando alguém tentou representar a estrutura em código. O sistema de desired state, como Tobi chama, compara o que é com o que deveria ser e calcula o menor conjunto de mudanças para chegar lá, com o RH funcionando como reconciliador em vez de repositório de políticas.

A consequência prática aparece quando o chefe de vendas pede 50 novos contratados. O sistema recalcula tudo e mostra que, dado o budget acordado, contratar 50 vendedores significa cortar engenharia, tornando visível um tradeoff que antes desaparecia nos bastidores de uma conversa de golf onde o CEO disse que sim. Quando as consequências ficam explícitas antes da decisão, fica difícil fingir que elas não existem.

A mesma lógica governa o sistema de compensação que Tobi construiu depois que as ações da Shopify caíram 80% em 2021 e 2022. Cada funcionário escolhe, todo trimestre, a proporção entre salário em dinheiro, RSUs e "shop cash", e se a ação cai, o funcionário recebe mais units no próximo trimestre porque o preço está menor, funcionando como rebalanceamento automático.

O princípio que conecta os dois projetos, o OS e o sistema de compensação, é que pessoas com agência real fazem escolhas melhores do que pessoas que seguem políticas, e criar agência real significa desenhar o sistema de incentivos de modo que a escolha certa seja também a escolha óbvia, sem precisar publicar lista de valores na parede.

Tobi usa o mesmo raciocínio para os escritórios, onde pods de tamanho desconfortável para sete pessoas produzem times que se auto-organizam em cinco sem nenhuma diretriz que determine o tamanho dos times.

A parte mais estranha da entrevista é quando Tobi fala sobre 2026. Ele conta que tem seis agentes de IA rodando em paralelo, que eles se mandam e-mail entre si, e que o trabalho dele passou a se parecer com uma partida de StarCraft: alocar atenção, intervir nos loops que precisam de ajuste, monitorar o agente crítico que supervisiona os outros.

Aprendeu StarCraft nos anos 90 porque era um jogo de informação imperfeita onde atacar a atenção do adversário valia mais do que atacar a base dele e onde o recurso mais escasso, mais do que minério, era foco.

A analogia funciona porque Tobi passou vinte anos construindo sistemas que reduzem a quantidade de decisões que precisam da atenção dele. O OS decide a estrutura da empresa.

O sistema de compensação decide os tradeoffs de remuneração. Os pods decidem o tamanho dos times. O sistema de fases de projeto, dividido em protótipo, proposta e build com transições formais entre eles, decide quando ele precisa aprovar algo e quando pode confiar que o time tem o que precisa para seguir sozinho.

Cada um desses sistemas existe porque a atenção de Tobi é o recurso mais caro da empresa, e gastá-la em decisões que poderiam ser tomadas por outras pessoas ou por regras claras é um desperdício que se acumula de forma invisível até um COVID aparecer e expor tudo de uma vez.

Há uma tensão que a entrevista com David Senra deixa no ar. Tobi diz que escrever políticas mata empresas porque as pessoas que estudam a política com mais cuidado são exatamente as que você não quer contratar, aquelas que buscam o manual antes de agir. O Shopify OS, porém, é uma política sofisticada sobre como a empresa deve se organizar, escrita em código Python com um SAT solver.

A diferença que ele aponta é que o sistema é derivado de princípios e mantido em código, então quando um princípio muda, as consequências se propagam automaticamente para toda a estrutura, diferente de uma política escrita que envelhece sem que ninguém perceba.

O problema é que princípios também envelhecem, e o próprio Tobi admite que vai encontrar contradições nessa entrevista se pedir para uma IA analisar a transcrição, e que contradição sinaliza que o frame mudou, não que o raciocínio era ruim quando foi feito.

O Shopify OS de 2020 foi a resposta para os problemas que a Shopify tinha em 2020, e em 2026, com agentes de IA reescrevendo o que é possível fazer com um time pequeno, a pergunta sobre qual deveria ser o tamanho de um time vai precisar ser respondida de novo, com números completamente diferentes, e o sistema que calcula essa resposta vai precisar ser reescrito por alguém que provavelmente ainda está no onboarding.

Essa sequência acontece o tempo todo, em empresa de todos os tamanhos, e quase nunca gera uma conversa honesta sobre o que deu errado. O que gera é uma nova sprint, um novo roadmap, uma nova feature que vai resolver o que a anterior não resolveu, enquanto o problema original continua lá, intacto: o produto foi entregue mas nunca foi adotado.

No novo episódio do Product Gurus, conversei com Bárbara Milet, Head de Parcerias nas Américas da UserGuiding, sobre o que fica entre o deploy e o uso real. Bárbara foi sócia de uma Software House antes de ir para o lado de quem resolve esse problema, então ela fala do fracasso de adoção de dentro pra fora, não como consultora que diagnostica de longe.

Um case dela do episódio: produto para área de educação que deveria demorar quatro meses, demorou mais de um ano porque cada botão precisava ser perfeito, e quando chegou nas escolas o professor não tinha paciência para 70 gráficos no dashboard, só queria gerar um PDF de uma página para entregar na diretoria.

A gente também foi fundo em Time to Value, que é uma métrica que todo mundo diz usar e quase ninguém calcula certo, porque o problema não é o T, é o V. Se você não sabe o que é valor para aquele perfil específico de usuário, o tempo que você está medindo não tem significado nenhum, você está cronometrando o percurso sem ter definido o destino.

E a conversa chegou num ponto que eu acho que vai incomodar bastante gente: o usuário não está apegado ao seu produto. Ele está apegado ao resultado. Se aparecer outra ferramenta que entrega o mesmo resultado com menos atrito, o apego vai embora junto.

🔗 UserGuiding (20% de desconto): https://productgurus.short.gy/Au9oVX

🎧 Ouça agora no Spotify ou YouTube.

Capítulo
01:18 Quem é Bárbara Milet
02:45 A maior frustração de adoção que Bárbara já viveu
05:04 Por que PMs focam em delivery e ignoram adoção
07:29 O custo invisível de uma feature que ninguém usa
08:27 Gov.br e o trauma de produto difícil de usar
10:15 Onboarding que encanta vs. onboarding que irrita
12:43 Demo interativa fake e o churn que vem depois
14:39 Time to Value: por que o T não é o problema
17:15 TTV começa pelo V, não pelo tempo
19:17 PM dependente de engenharia e o que isso custa
24:28 Ferramentas no-code e autonomia do time de produto
28:57 Como a UserGuiding fecha esse gap
36:54 Merchan + a polêmica do episódio
38:29 A verdade que nenhum PM admite: usuário não liga pro produto
42:59 A UserGuiding que não usava a própria UserGuiding
44:15 Encerramento

🛠️ Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: ⁠https://go.pm3.com.br/ProductGurus-AI-Specialist⁠
Cupom de 10%: PRODUCTGURUS

🛠️ Pingback é a plataforma simples e rápida para automatizar marketing e vendas sem burocracia. Crie formulários, dispare e-mails e WhatsApp, segmente leads e automatize fluxos enquanto seu time acompanha tudo no CRM.
Acesse: ⁠https://pbck.link/paulo-chiodi

O que torna esse número difícil de engolir é o que ele implica sobre o trabalho que já foi feito, porque cada feature no produto passou por alguém priorizando, alguém desenhando, alguém desenvolvendo, alguém testando e alguém anunciando, com um custo médio que fica entre R$ 80 mil e R$ 300 mil quando se conta engenharia, design e PM num time razoavelmente estruturado, e multiplicado pelo tamanho de um catálogo típico de produto SaaS o valor parado em funcionalidades que ninguém usa se torna difícil de dimensionar sem constrangimento.

Subscreva agora

A metodologia da Pendo mede adoção por feature de uma forma específica, contando quantas funcionalidades são necessárias para gerar 80% do volume de interação de um usuário típico, um conjunto que a empresa chama de Core Events, e a lógica é razoável porque evita o problema de features que aparecem muito por razões estruturais, como botões de navegação ou campos obrigatórios, focando no que o usuário escolhe usar com alguma frequência.

Com essa definição, a mediana da indústria fica em 6,4%, enquanto os produtos no top 10% chegam a 15,6%, pouco mais que duas vezes a média.

O que separa esses dois grupos raramente é a quantidade de features: os produtos com adoção alta tendem a ser menores em catálogo ou mais disciplinados no que mantêm ativo, o que os dados da Pendo confirmam quando olham para tamanho de empresa, já que empresas com menos de 200 funcionários têm adoção média de 7,4%, a mais alta de todos os segmentos, provavelmente porque times menores simplesmente não têm capacidade de manter um catálogo inflado, então o que fica no produto é o que as pessoas de fato precisam.

O custo de uma feature ignorada vai além do que foi gasto para construí-la, porque uma vez que a funcionalidade existe ela precisa de manutenção a cada mudança de infraestrutura, precisa ser considerada em cada decisão de design, aparece na documentação, entra nos fluxos de onboarding e gera tickets de suporte de usuários que tropeçam nela sem entender para que serve, sem contar que ela consome atenção do time e adiciona ruído para qualquer usuário novo que tenta entender o que o produto faz.

A variação por setor nos dados da Pendo acrescenta uma camada nesse raciocínio: manufatura e bens de consumo têm as taxas mais altas de adoção por feature, enquanto mídia fica em 4,9%, e a explicação mais plausível é que um produto B2B de nicho provavelmente tem adoção alta porque os usuários chegam com objetivo claro e repetem as mesmas tarefas toda semana, ao passo que um produto de mídia com centenas de features enfrenta comportamento muito mais disperso porque o usuário decide o que quer a cada sessão, sem nenhuma obrigação de retornar às mesmas funcionalidades.

Esse comportamento disperso aponta para algo que os dados de adoção por feature não mostram diretamente: a diferença entre features usadas muitas vezes pelos mesmos usuários e features tentadas uma vez e abandonadas, duas dimensões que a Pendo chama de profundidade e duração da adoção, sendo que um usuário que abre um relatório avançado uma vez por curiosidade e nunca mais volta gera um clique no numerador mas não gera valor real, e times que acompanham adoção de forma mais cuidadosa monitoram a curva de retenção por feature, não só a taxa de ativação.

A Pendo recomenda quatro caminhos para melhorar adoção: walkthroughs in-app, comunicação de feature dentro do produto, clareza sobre valor e ação esperada, e segmentação por perfil de usuário, todos razoáveis quando o problema é que o usuário não sabe que a feature existe ou não entende como usar, mas nenhum deles resolve o caso em que o usuário tentou, entendeu e parou de usar porque a feature simplesmente não entrega valor suficiente para justificar a mudança de comportamento que ela exige.

Medir adoção por feature e agir em cima disso implica, eventualmente, remover funcionalidades do produto, e remover feature é uma das decisões mais difíceis de tomar em qualquer time, não porque seja tecnicamente complicada, mas porque sempre existe alguém que usa, sempre existe o risco de reclamação pública e sempre existe a memória de quanto custou construir, o que faz com que a maioria dos produtos cresça em direção a um catálogo cada vez mais denso, com uma camada fina de uso real sobre uma estrutura cada vez mais pesada de funcionalidades que ninguém pede para tirar mas que quase ninguém usa de verdade.

O que os dados não respondem é quantas das features paradas nos 93,6% poderiam ser cortadas sem que nenhum usuário percebesse, e se a resposta para essa pergunta é incômoda, o processo de descobri-la é provavelmente mais incômodo ainda.

🔗 Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: https://go.pm3.com.br/ProductGurus-AI-Specialist
Cupom de 10%: PRODUCTGURUS

Em 80% dessas organizações havia cortes de pessoas vinculados às iniciativas de IA, alguns chegando a 20% da força de trabalho, e o resultado financeiro das que cortaram mais foi praticamente idêntico ao das que cortaram menos. Em vários casos, quem cortou menos saiu melhor.

Subscreva agora

A lógica por trás dos cortes é clara em qualquer apresentação de diretoria: aqui está o que gastamos com pessoas nessa função, aqui está quanto a IA absorve, aqui está a economia resultante.

O que o business case não separa é que liberar caixa e gerar retorno são dois passos diferentes, sendo que o primeiro acontece com a demissão e o segundo depende de uma cadeia de condições que os dados da Gartner mostram não estar se cumprindo.

Helen Poitevin, VP Analyst da Gartner, disse que “reduções de headcount podem criar espaço no orçamento, mas não criam retorno”, e a distância entre as duas coisas é exatamente o que ninguém na sala dos altos executivos pedem para separar quando mostram o número de cabeças e a economia projetada logo abaixo.

As empresas que aparecem com retornos reais nos dados da Gartner são as que redirecionaram pessoas: requalificaram equipes para trabalhar junto com IA, redesenharam funções em torno do que humano e modelo fazem bem separadamente, e construíram operações onde pessoas supervisionam sistemas autônomos em vez de serem substituídas por eles.

Poitevin chamou as fixadas em headcount de “laggards” porque estão perseguindo a menor versão possível do que a IA pode entregar, que é fazer o mesmo trabalho com menos gente, enquanto as empresas com ROI positivo perseguem crescimento de receita, velocidade de lançamento e mudanças operacionais que a tecnologia torna viáveis mas que exigem pessoas para executar.

Os casos individuais que vieram antes dessa pesquisa já apontavam na mesma direção. A Klarna demitiu 700 pessoas de atendimento ao cliente, assistiu a qualidade cair e começou a recontratação; a IBM automatizou boa parte do RH e reverteu quando os sistemas não conseguiram lidar com nada que exigisse julgamento; o Commonwealth Bank of Australia reverteu 45 demissões motivadas por IA depois de concluir que as funções nunca foram redundantes.

Em fevereiro, a própria Gartner previu que metade das empresas que atribuíram cortes de pessoas à IA vão recontratá-los até 2027, só que com nomes de cargo diferentes, o que é um jeito elegante de dizer que as demissões foram prematuras.

O que esses casos têm em comum é que a decisão de cortar foi tomada antes de saber se os sistemas que substituíam as pessoas conseguiam carregar o peso, e o argumento que as lideranças usam para justificar esse timing, de que as capacidades de IA estão avançando rápido e o que não funciona hoje pode funcionar em dezoito meses, aponta na direção contrária do que parece: se o sistema ainda está amadurecendo, fazer cortes permanentes sobre capacidades provisórias é exatamente o risco que os dados mostram não compensar.

O gasto com software de agentes de IA deve sair de 86 bilhões de dólares em 2025 para 206 bilhões em 2026 e 376 bilhões em 2027, o que significa que a tecnologia vai melhorar e baratear nos próximos anos, e as empresas que cortaram agora para capturar eficiência vão reconstruir equipes nesse mercado mais competitivo, pagando prêmio para recontratá-los, tendo perdido dois anos de conhecimento institucional que andou junto com quem saiu.

A Gartner projeta que negócios autônomos vão ser geradores líquidos de empregos entre 2028 e 2029, com demanda crescente por pessoas que consigam orientar, supervisionar e escalar sistemas de IA, e as empresas que investiram nisso durante o ciclo de transição vão entrar nessa fase com equipes treinadas, enquanto as que correram atrás do número de headcount de 2026 vão estar recrutando do zero, em escassez, contra concorrentes que não cortaram.

O que os business cases não capturam é o que acontece com clientes, candidatos e parceiros no intervalo entre os cortes e a eventual recontratação.

Uma empresa que elimina o time de customer success e substitui por automação pode registrar resultado financeiro neutro no trimestre, mas o comitê de decisão que estava a três semanas de fechar um contrato de sete dígitos e começou a se perguntar se a empresa vai ter equipe para suportá-los daqui a um ano não aparece em nenhuma linha do relatório, assim como o candidato sênior que viu a sequência de notícias de demissão no LinkedIn da empresa antes de receber o convite para entrevista, ou o conhecimento sobre clientes específicos que saiu junto com o gerente demitido e não estava documentado em lugar nenhum.

Esses efeitos aparecem como atrito acumulado nos trimestres seguintes: vendas que demoram mais para fechar, retenção que piora gradualmente, recrutamento que fica mais caro, cada um parecendo problema isolado, mas somando o custo de ter tratado pessoas como variável de ajuste num business case que, segundo os dados de 350 empresas que efetivamente tentaram, não gerou retorno de qualquer jeito.

🔗 Construa uma carreira à prova do futuro, liderando produtos mais inteligentes e eficientes com IA. Acesse: https://go.pm3.com.br/ProductGurus-AI-Specialist
Cupom de 10%: PRODUCTGURUS

O Zé Delivery entrega bebida em minutos para 20 milhões de pessoas, opera em 850 cidades com 3.500 parceiros e já tem 25% do faturamento fora de cerveja. Tudo isso dentro da Ambev.

Fernando Mazzarolo, CEO do Zé Delivery, veio no Product Guru’s para contar como funciona por dentro: como o Zé manteve cultura de startup depois da integração com a nave-mãe, por que recusou virar supermercado, como estrutura autonomia para 18 squads sem perder alinhamento, e o que aconteceu quando a IA saiu do controle de 100 agentes catalogados para ninguém mais sabe quantos.

Também fala sobre o erro que cometeu antes de acertar na estratégia de IA, o KPI que ficou parado quatro anos e se moveu quatro pontos em quatro meses, e por que mapeamento de processo vem antes de qualquer automação.

O que você vai aprender nesse episódio:

• Como proteger cultura de produto dentro de uma corporação grande

• Por que estratégia é sacrifício, e como o Zé aplica isso com 18 squads

• O erro clássico de IA corporativa e o que funcionou de verdade

• Como expandir portfólio sem perder identidade de marca

• O skill número 1 de PM segundo o CEO do Zé Delivery

Assista no YouTube ou ouve no Spotify.

Capítulos:
00:00 O que o Zé Delivery é de verdade
01:43 Quem é Fernando Mazzarolo
05:02 Como o Zé sobreviveu à integração com a Ambev
08:47 A verdade sobre cultura de produto que ninguém admite
13:04 O que tira o sono do CEO: os 6 KPIs diários
15:43 Por que o Zé recusou virar supermercado
19:13 Como o bar da esquina virou parceiro de logística
22:11 25% do faturamento sem cerveja (e a meta de 40%)
25:28 Gestão de portfólio: como lançar categoria sem errar
29:45 Modelo de negócio do Zé e o papel do PM
36:47 Autonomia dos PMs dentro de uma corporação
37:25 Processo é ferramenta de autonomia, não obstáculo
43:07 Estratégia é sacrifício
43:46 Como a IA entrou no Zé — e o primeiro erro
47:00 De 20 para 200 pessoas no AI Talks
51:00 Mapeamento de 100% dos processos com IA
53:00 Perdemos o controle: de 100 agentes para ninguém sabe
55:41 Cases reais de IA no Brasil e o convite ao time do Zé
58:22 Encerramento

O culpado nominal foi o Claude Code, ferramenta da Anthropic para geração e refatoração autônoma de código. Mas culpar a ferramenta é como culpar o cartão de crédito pela fatura alta. O que aconteceu na Uber é um problema de modelo mental: a empresa tratou IA como uma linha de licença de software, quando na prática ela se comporta como uma linha de produção funcionando vinte e quatro horas por dia com custo proporcional ao que produz.

Subscreva agora

O modelo SaaS tradicional cobra por assento. Você tem 5.000 engenheiros, assina 5.000 licenças, o custo mensal é previsível e praticamente independe de quantas horas cada um trabalha. O Claude Code funciona por consumo de tokens, que são unidades de processamento. Cada vez que um agente varre um repositório, executa um teste, propõe uma refatoração ou compila uma sugestão, ele consome tokens e a conta sobe. Quando você tem 5.000 engenheiros usando a ferramenta ativamente, com agentes rodando tarefas em background sem supervisão humana constante, a matemática deixa de ser linear. Ela fica exponencial.

A Uber chegou ao ponto onde agentes de IA escreviam 11% de todo o código de backend em produção, incluindo lógica de pareamento de motoristas e algoritmos de precificação dinâmica. Três meses antes, esse número era inferior a 1%. O salto foi rápido demais para que qualquer ciclo orçamentário anual acompanhasse. Orçamentos são aprovados em outubro para o ano seguinte. A adoção do Claude Code disparou em dezembro e janeiro. Quando o financeiro olhou para os números, a fatura do primeiro trimestre já era maior do que o planejado para o ano inteiro.

Tem um componente comportamental nessa história que agrava tudo. A liderança da Uber criou painéis internos que ranqueavam os engenheiros pelo volume de uso de ferramentas de IA. A intenção era acelerar a adoção. O efeito foi que consumir tokens virou métrica de desempenho. Engenheiros passaram a abrir sessões maiores, delegar mais tarefas concorrentes aos agentes, deixar processos rodando mais tempo do que o necessário para o problema em questão. A analogia mais precisa aqui foi feita pela analista Cristina Cordova: avaliar equipes de engenharia pelo gasto em tokens é como avaliar equipes de marketing pelo valor gasto em mídia, ignorando qualquer resultado de conversão. A métrica mede atividade, não valor.

Esse fenômeno ganhou nome. Tokenmaxxing é a prática de maximizar o consumo de tokens de IA como se isso fosse um indicador de produtividade. Não é exclusividade da Uber. A Meta incluiu uso de ferramentas de IA nas avaliações de desempenho de funcionários. A startup Nectir estabeleceu cotas mínimas de consumo semanais, que foram de US$ 100 para “alguns milhares de dólares” por engenheiro. Em Estocolmo, um engenheiro chamado Max Linder relatou à imprensa que seus gastos mensais com Claude superavam o salário.

O resultado prático desse ambiente é que faturas de US$ 150.000 mensais por engenheiro individual deixaram de ser absurdas para serem relatadas como algo normal. Um agente de IA rodando continuamente sobre um repositório grande pode processar mais de 700 milhões de tokens em uma semana. Com o modelo de cobrança por consumo que a Anthropic migrou os clientes enterprise no início de 2026, os custos deixaram de ser uma variável discreta e passaram a flutuar em tempo real conforme o comportamento dos desenvolvedores.

A questão que ninguém estava preparado para responder é simples: qual o ponto de equilíbrio entre o custo da ferramenta e o valor que ela gera?

Um estudo do CSAIL do MIT sobre automação de tarefas de visão computacional concluiu que em apenas 23% dos casos a máquina era mais barata que o humano. Nos 77% restantes, quando contabilizados os custos de implementação, manutenção, hardware, treinamento e inferência contínua, o trabalhador humano saia mais barato. Bryan Catanzaro, VP de deep learning na Nvidia, disse abertamente que os custos de infraestrutura de processamento da sua divisão já superam a folha salarial da equipe.

Isso coloca um problema concreto para qualquer pessoa sentada numa cadeira de liderança de produto ou tecnologia. O argumento de que IA reduz custo de trabalho humano, que foi o principal justificador de orçamento nos últimos dois anos, começa a depender de condições muito específicas para ser verdade. Não é falso. Mas também não é automaticamente verdadeiro para qualquer tarefa, em qualquer escala, com qualquer modelo de cobrança.

A Uber está avaliando migrar parte da carga para o Codex da OpenAI, em parte porque analistas apontam que ele consome tokens de forma mais eficiente em certos tipos de refatoração. Isso é, em essência, escolher fornecedor de IA pelo custo por token, da mesma forma que empresas de logística escolhem combustível pelo preço por litro. É um mercado de commodities que estava disfarçado de diferencial tecnológico.

O que fica sem resposta: se os engenheiros da Uber produzem melhor código, em menos tempo, usando Claude Code, mas o custo da ferramenta ultrapassa o salário de parte da equipe, e o MIT diz que em 77% dos casos o humano ainda é mais barato, quem exatamente ficou com a produtividade dessa equação?

Subscreva agora

🎧 Ouça pelo Spotify, Apple Podcast e YouTube.

📌 Se você ouve pelo Spotify, segue o canal e deixa 5 estrelas.
📺 No YouTube: se inscreva, deixa o joinha e comenta o que achou.

00:00 Introdução — o episódio mais polêmico do PG
01:50 A maior mentira que os gurus de IA vendem
05:10 Por que IA tem mais de 80 anos e ainda é novidade
06:55 93% dos executivos dizem que o problema é cultura. Por que ninguém age?
09:20 Automação ou ampliação? Como descobrir em qual lista você está
11:20 TCO: o custo real de manter IA que os vendedores ignoram
19:30 Tecnologia escala eficiência, liderança humana escala valor
23:10 A verdade que todo CEO precisa saber nos próximos 5 anos
25:40 Por que a IA ainda está na bolha de tech
29:00 Modelos próprios vs. modelos genéricos: o caminho das empresas grandes

Obviamente existe uma série de papeis específicos dentro da área de produtos que carregam funções características, seja o Product Manager, Product Owner, Product Marketing Manager e outras já bem disseminadas em diferentes mercados.

Em todos os casos, existe um papel basicamente central para avaliação de resultados da perspectiva de produto: a análise de dados.

Subscreva agora

Nesse sentido, existem diversas métricas e frameworks que podem ser considerados para avaliação de resultados das ações tomadas pela equipe, como por exemplo o F4P (Fit For Purpose).

Entrando em mais detalhes práticos, existem diferentes KPIs (em inglês Key Performance Indicators) que podem ser considerados para avaliação de desempenho de determinado produto.

Para uma melhor contextualização, separamos alguns dos mais populares utilizados em diferentes contextos que estão atrelados a ativação de usuários:

• Lifetime Value (LTV)
  O LTV deve ser empregado como uma ferramenta de acompanhamento do cliente, visando prolongar sua relação com o negócio e mitigar o Churn. É uma métrica importante para buscar formas de rentabilização do cliente junto ao seu produto ou serviço.

  A fórmula para cálculo do LTV é basicamente por meio da soma da vida útil dos clientes dividido pelo número total de clientes.

• Net Churn
  A métrica conhecida como Net Churn revela a porcentagem de clientes que cancelaram contratos ou cessaram a compra de seus produtos. É um recurso valioso para entender as demandas relacionadas ao reforço das estratégias de retenção e fidelização de clientes.

  Por exemplo, para calcular a taxa de Churn de seu produto, basta dividir o total de clientes que cancelaram contratos pelo número de consumidores ativos durante o período estipulado, e então multiplicar o resultado por 100.

• Custo de Aquisição de Cliente (CAC)
  Calculado dividindo o valor total investido em marketing e vendas pelo número de novos clientes adquiridos. Por exemplo, se o investimento total for de R$ 20 mil e forem adquiridos 250 novos clientes por mês, o CAC será de R$ 80,00.
  Isso significa que o Custo de Aquisição de Clientes dessa empresa é de R$ 80,00 para cada novo cliente.

• Time to Value (TTV)
  Uma métrica crítica que indica quanto tempo seus usuários levam para perceber o valor de seu produto ou serviço ao alcançar o estágio de ativação em sua estratégia de monetização.
  Essa estratégia pode estar relacionada à aquisição do produto, excluindo assim usuários que apenas experimentaram a versão de teste (como por exemplo o tempo de usuários que utilizam a versão gratuita do Duolingo levam para adquirir a versão paga).
  No entanto, essa definição pode variar e, em alguns casos, estar ativo não significa necessariamente estar pagando.

• NPS (Net promoter Score)
  Avaliação da relação do consumidor com produto/serviço de forma geral, levando em consideração se ele estaria disposto a levar suas percepções adiante, de forma orgânica, recomendando para seus amigos e familiares. Leva em consideração a lealdade que ele possui com determinada marca, um sentimento extremamente relevante para futuros negócios da empresa.

O que todas tem em comum?

O primeiro ponto é que não existe uma regra universal que ajuda a definir uma boa média para cada uma das métricas: cada segmento tem características específicas que podem levar a uma média maior ou menor (produtos B2C e B2B, por exemplo, já demonstram diferenças consideráveis entre si).

O segundo ponto em comum é de que esses (e tantos outros) indicadores precisam ser monitorados com recorrência, visando o entendimento de como aprimorar seu produto.

Um dos pilares da metodologia Lean é baseado nesse ciclo de construir, mensurar e aprender como uma forma de coletar e analisar feedback.

Visto pela primeira vez no livro Lean Startup de Eric Ries, o processo envolve aprender rápido para que você possa desenvolver rapidamente com assertividade: mensurar dados antecipadamente e utilizar seus resultados para aprimorar nosso aprendizado e criar uma percepção de valor junto ao usuário.

A Mentoria CPO do IFTL inclui uma aula focada no detalhamento de alguns dos conceitos trazidos no livro Lean Startup de Eric Ries, além de abordar diversos frameworks à partir da cultura Agile.

O conceito de Customer Relationship Management (CRM)

Sendo membro da área de produto, é bem provável que você utilize uma “plataforma de CRM” em seu dia a dia no trabalho, ou ao menos tenha um relacionamento próximo com algum stakeholder que tenha essa função.

Entretanto, o conceito de CRM é muito mais abrangente do que uma mera plataforma ou atividade: é uma forma de projetar estruturas e sistemas para que se concentrem em fornecer aos consumidores o que eles desejam, e não no que a empresa deseja que eles queiram, criando um time-line da vida desse cliente no negócio e/ou empresa. Geralmente envolve uma reestruturação dos sistemas de TI da empresa e uma reorganização do seu pessoal.

Esse definição de 2009 do The Economist se mantém extremamente atual, especialmente por conta da falta de contexto em que muitas vezes o termo é utilizado.
O CRM depende fortemente de uma técnica chamada data warehousing, uma forma de integrar informações díspares sobre clientes de diferentes partes da organização e reuni-las em um enorme “armazém” de T.I.

Dale Renner, CEO da RedPoint Global, define essa atividade como “identificar, atrair e reter os clientes mais valiosos para sustentar um crescimento lucrativo”.

A visão de uma profissional de CRM

Para trazer uma visão prática de uma profissional da área que possa contextualizar exemplos do dia a dia e também construir a ponto junto aos profissionais da área de produto, tive uma bate-papo com Monique Servija, coordenadora de marketing digital e e-commerce na Vic Beauté e com passagens na Tok&Stok e Calvin Klein lidando diretamente com o tema.

Como foi sua trajetória profissional dentro de CRM?

Comecei a trabalhar na área à partir do disparo de e-mails marketing como web designer. Durante essa etapa, tive muito contato com diferentes designers, o que me ajudou no entendimento do conceito de experiência do cliente.

Já a minha primeira experiência mais por dentro do campo de CRM foi durante minha posição na Tok & Stok: acabei tendo interface com praticamente todas as áreas da empresa por conta da relação entre os temas delas e as perguntas que o relacionamento com o cliente ajudava a responder.

Inicialmente, lidava muito com a área de pesquisa: o primeiro grande projeto começou com a implementação e avaliação do NPS e feedbacks dos clientes em relação aos produtos de forma geral, e essa foi a base para a criação de uma sinergia com outras áreas e cargos.

Passamos a criar diferentes relatórios com base nessas informações, e foram as equipes de tecnologia que manifestaram mais interesse à respeito.

Começamos, na sequência, a desenvolver alguns projetos ainda mais abrangentes: O aplicativo da T&S foi um exemplo. Passamos a atuar com Push notifications e InApps, formatos de comunicação direcionadas ao usuário do aplicativo com ofertas e promoções de acordo com seus respectivos perfis.

Nesse momento já havia uma troca com o time que tocava o e-commerce (site), porém era muito restrito e pontual, pautado especialmente pela necessidade de integração de dados.

Existiu um grande case que levou você ao aperfeiçoamento como profissional?

Um dos grandes projetos que realizei foi o programa de fidelidade da T&S: ele foi o grande entregável que contou com o apoio de todas as áreas voltadas a tecnologia da empresa.

Iniciamos com um modelo de Minimum Viable Product (MVP) que trouxe algumas hipóteses para validação. Com o passar do tempo, após os resultados prévios trazendo algumas hipóteses confirmadas, o programa começou a ter destaque. Se tornou uma atividade semanal, e uma vez que o deploy foi aprovado, uma série de melhorias passaram a ser acrescentadas.

O projeto nasceu dentro de CRM após a implementação da área de pesquisa, e ao estudar a questão de churn, foi identificado o interesse por parte dos clientes.

Ter uma pessoa que pode entender e interpretar as ideias de pessoas mais criativas e traduzir para um time mais técnico foi o papel fundamental de PMs e POs durante o processo. Eles ajudam a “pavimentar” roadmap.

Qual a maior dificuldade por parte dos PMs e POs no contato com CRM?

Backlog: filas gigantescas em relação aos desenvolvimentos a serem realizados. Mesmo CRM já tendo se provado internamente na T&S, ainda assim para criação de novas features foi uma grande batalha.

Mas é necessário entender que não necessariamente é o PO/PM que toma essa decisão, uma vez que existem diversas prioridades de diferentes áreas que simultaneamente fazem solicitações recorrentes.

Qual o principal gap de entendimento das atividades de CRM que você gostaria que os profissionais soubessem?

A definição, que é muito maior e mais abrangente do que meramente a ferramenta a ser usada para disparo de comunicação ou armazenamento de dados dos clientes.

O CRM faz a gestão dos dados do cliente de diversos pontos distintos, tendo como premissa a manutenção do relacionamento com eles. Na prática, é uma figura intermediadora entre o que a empresa quer fazer e do que o cliente precisa.

Ponto importante: CRM não cria necessidade, ele atende a necessidades por meio de produtos voltados ao cliente.

A empresa, independente do negócio, quer realizar transações o tempo todo. Entretanto, o cliente nem sempre está interessado: o pulo do gato é que a partir de uma base de clientes, é mais fácil identificar quem está disposto a realizar essa transação. Entender o momento do cliente e abordá-lo da melhor forma possível.

Quais os principais indicadores a serem considerados pelas organizações?

Você já citou algumas no início do artigo, mas é importante ressaltar que as métricas variam de empresa para empresa: no final do dia elas são responsáveis por vendas efetivamente realizadas (e suas variações até chegarem lá). Em algumas empresas, por exemplo, CRM atende como canal de vendas.

Mas o principal indicador que considerei em minha vida profissional é a base ativa de clientes: uma forma de trazer resultados a longo prazo, mantendo meu consumidor, evitando que deixem de consumir os produtos ou serviços da organização. Ou seja, acabamos respondendo por venda e métrica de engajamento de todos os canais de comunicação e conversão.

Durante uma entrevista a Forbes em 2022, o CEO da Kovai, Saravana Kumar, mencionou algo relevante nesse sentido:

Como os testes acontecem dentro da área CRM?

Tentativa e erro é uma rotina por parte de CRM: a nível de comunicação e tipos de conteúdo, é necessário testar o tempo todo (não existe verdade absoluta que irá funcionar sempre, como “descontos para fidelizar clientes”, por exemplo).

Na T&S o time de criação era interno, então isso facilitou os testes realizados por conta da celeridade no desenvolvimento dos mesmos.

Ao encontrar um padrão que dá certo e usá-lo exaustivamente, uma hora ele irá invariavelmente decair, e é necessário voltar a buscar novas formas de uplifting/retenção. Por meio de testes contínuos.

Para planejamento, é necessário criar um calendário de disparos e testes com novas formas de fazer as mesmas ações: dessa maneira é possível mensurar quais as respostas obtidas.

No meu cotidiano na T&K, levei em consideração calendário com base ativa, recuperação, programa de fidelidade, pessoa jurídica, push notifications, InApp, SMS, e-mail mkt etc. e dentro de cada um deles existiam as opções de comunicações oficiais e testes efetivos.

Para compartilhar com outras áreas, foram criadas variações para simplificar a visão dos interesses de cada uma delas.

Principais dificuldades de CRM

Acredito que a maior dificuldade se dá por parte das empresas por conta dos resultados: além de mostrá-los, os profissionais de CRM precisam se explicar internamente. Muitas vezes as pessoas entendem que CRM constitui apenas na ação de disparados de e-mail, e por conta disso é necessário cumprir um papel como “educadora” para explicar com mais detalhes as demais equipes.

Explicar que minha atividade não era meramente disparar o mesmo e-mail para toda a base de clientes era algo recorrente.

Quer saber mais sobre o tema CRM?

A Monique repassou algumas indicações para quem tiver interesse em se aprofundar no tema, conforme relação abaixo de cursos, ferramentas para testes e outros:

Cursos

• Formação em CRM com a querida Fatima Periard - https://lnkd.in/dz42jyrD (ah, e quem faz parte do grupo CRM Marketing Brasil tem desconto, não se esqueçam!)

• CRM Marketing da EBAC - Escola Britânica de Artes Criativas e Tecnologia- https://lnkd.in/dsMrSW5E

• CRM e Funil de Marketing da Alura - https://lnkd.in/dfCrnQzp

• CRM, Dados e o Futuro Centrado no Cliente da Coursera - https://lnkd.in/dEHpg8cW

• Marketing de relacionamento e CRM da Learncafe - Cursos online- https://lnkd.in/daPvKGdk

Comunidades no WhatsApp

• CRM Marketing Brasil - https://lnkd.in/d8QbaNq3

• Vagas CRM - https://lnkd.in/dtDQQGrk

Livros (aqui já aviso, não são livros teóricos de CRM)

• A arte de encantar clientes - https://lnkd.in/d2mkFTxq

• O jeito Disney de encantar clientes - https://lnkd.in/d5JbhBUn

Onboarding Orquestrado - https://lnkd.in/dv9eWq_h

𝗕𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸

• Really Good Emails - https://lnkd.in/dRB67arS

• Milled - https://milled.com/

• Lista de palavras gatilhos de spam - https://lnkd.in/dd7XVKVV - evite, não quer dizer que nunca pode usar!

• Mailchimp (métricas por setor) - https://lnkd.in/dHeU-RvK

𝗙𝗲𝗿𝗿𝗮𝗺𝗲𝗻𝘁𝗮𝘀 𝗱𝗲 𝗧𝗲𝘀𝘁𝗲 𝗲 𝗔𝘃𝗮𝗹𝗶𝗮𝗰̧𝗮̃𝗼

• Teste o seu subject - https://lnkd.in/dK3j9YSB - apesar de ser um site em inglês, ele consegue validar a estrutura e gatilhos

• Descubra a “nota” e possíveis problemas com o seu e-mail - https://lnkd.in/dSh3H_Be - tanto com seu HTML quanto com seu domínio

• Descubra o seu Sender Score - https://senderscore.org/: ajuda a entender como está a reputação do seu domínio ou IP

Subscreva agora

O problema concreto era outro: os professores abriam a plataforma e não sabiam o que fazer com ela.

A Gerente de Produto Bennur Amaç descreveu a situação sem rodeios:

“Tínhamos duas escolhas: passar meses construindo um sistema de integração ou encontrar um caminho mais rápido.”

Essa frase resume o ponto de virada do projeto, mas o que tornou a situação difícil de resolver não foi falta de recursos. Foi um equívoco sobre quem era o usuário real da plataforma.

O produto tinha sido construído com a sofisticação certa para o que ele fazia, geração de currículo por IA, relatórios analíticos, ferramentas de personalização, integração com ecossistemas múltiplos de alunos, pais e administradores. O que não tinha sido previsto é que a maioria dos professores que precisava operar tudo isso vinha de escolas que adotam tecnologia por imposição administrativa, não por escolha. Esses professores não precisavam de um produto menos capaz, precisavam de uma entrada diferente no mesmo produto.

A confusão inicial não era sobre funcionalidade, era sobre orientação. Um painel com dezenas de opções, sem um ponto de partida claro, produz o que designers de UX chamam de “síndrome da página em branco”: o usuário enxerga possibilidade demais e não consegue começar. No caso da Twin, isso significava professores que criavam conta e paravam. Não tentavam configurar turma, não matriculavam alunos, não chegavam à parte do produto que gerava valor real.

A resposta instintiva para esse tipo de problema é documentação. Manual de usuário, vídeo de onboarding no YouTube, tutorial em PDF, nenhuma dessas saídas funciona bem porque todas exigem que o usuário saia do produto para aprender a usá-lo, e depois volte para aplicar o que leu ou assistiu. Cada vez que essa alternância acontece, parte da informação se perde e a sensação de dificuldade aumenta.

A decisão da Twin foi construir o onboarding dentro do próprio produto, usando uma ferramenta no-code chamada UserGuiding. A escolha pelo no-code tinha uma justificativa direta: se a equipe de engenharia precisasse codificar o fluxo de integração internamente, o projeto consumiria de 5 a 10 profissionais seniores durante semanas, entre PMs, designers, desenvolvedores front e back-end e analistas de dados, e depois exigiria manutenção constante a cada mudança de interface. A economia auditada foi de mais de US$ 10.000 só em custo de mão de obra direta, além de meses de desenvolvimento que não foram gastos, o que permitiu que a equipe técnica continuasse no roadmap principal da plataforma.

A economia de US$ 10.000 é a parte visível, mas a parte que muda o produto de verdade é a lógica de segmentação que a ferramenta habilitou.

A Twin dividiu os professores em dois grupos com base em comportamento, não em perfil declarado.

1. O primeiro grupo era de recém-chegados: contas criadas há menos de sete dias, sem nenhuma ação registrada nos logs, nenhuma turma criada, nenhum aluno matriculado. Para esse grupo, o fluxo de integração ignorava completamente as funcionalidades avançadas da plataforma. A única missão era guiar o professor até dois marcos: criar a primeira turma e matricular os primeiros alunos. Nada de IA generativa, nada de currículos dinâmicos, nada de relatórios. Só o básico que prova que o produto funciona.

2. O segundo grupo era ativado automaticamente quando o professor completava esses dois marcos. A plataforma detectava a conclusão via telemetria e mudava o conjunto de tutoriais disponíveis. Esse professor já não via mais instruções para adicionar alunos. Via caminhos para usar os recursos de IA, personalizar currículos e operar as partes mais complexas do sistema. A transição acontecia sem intervenção humana, sem que nenhum gerente de sucesso do cliente precisasse checar manualmente quem havia avançado.

Essa divisão resolve um problema que muitos produtos de software com múltiplos perfis de usuário ignoram: tratar usuários diferentes com o mesmo fluxo de integração produz resultados ruins nos dois extremos. O iniciante se perde, o usuário avançado perde tempo com instruções que não precisa. A segmentação por comportamento elimina esse conflito porque o critério de classificação é o que o usuário fez, não o que ele declarou ser.

O sistema de checklists que acompanhava o fluxo usava um princípio de psicologia cognitiva chamado Efeito Zeigarnik: tarefas incompletas geram tensão mental até serem concluídas, o que aumenta a motivação para terminar o que foi começado. Apresentar ao professor uma lista com três ou quatro tarefas básicas, com barra de progresso e estimativa de tempo (”leva 2 min”), transforma um painel assustador em um conjunto de passos gerenciáveis. A percepção de complexidade cai sem que o produto precise ser simplificado.

Os números reportados pela Twin:

• aumento de 30% no engajamento diário dos usuários após a implementação,

• redução de 10% a 20% no tempo até a primeira ação concreta dentro da plataforma (o que o setor chama de Time to First Value),

• melhora de até 50% nas taxas de retenção em comparação com o modelo anterior sem onboarding estruturado.

Esses são os números que a empresa divulgou publicamente com base nos dados do UserGuiding.

O que esses números revelam é que o produto estava tecnicamente correto antes da mudança. O que não funcionava era a ponte entre o que o produto conseguia fazer e o que o professor conseguia descobrir sozinho dentro dele.

Essa distinção importa mais do que parece para quem constrói software B2B com usuários finais que não são os compradores. A escola compra o produto, o professor usa. O comprador avalia features, integrações e preço. O usuário avalia se consegue fazer a tarefa mais básica no primeiro dia. Se não consegue, para de tentar. E quando o usuário para de tentar, o dado que a escola vê no relatório de utilização é baixo, e na próxima renovação o contrato está em risco.

A Twin tem parceiros como Boeing e Intel porque o produto educacional convence em reuniões de C-level e avaliações de impacto social. Mas o que mantém esse produto sendo usado nas escolas é o professor de Ankara ou de Lagos que abriu o painel pela primeira vez e não desistiu nos primeiros quinze minutos, e o onboarding é o que decide se isso acontece ou não.

O problema que permanece sem resolução simples é que essa lógica vale para qualquer software com usuário final não técnico, mas a maioria das equipes de produto só descobre o custo do abandono precoce quando a taxa de churn já virou problema no board. Corrigir o fluxo de integração depois que os usuários desenvolveram hábito de não usar o produto é significativamente mais difícil do que construir o fluxo certo desde o início.

Subscreva agora