Modelagem de negócios em IA para product managers: o custo começa em cada pedido

Em produto de IA, cada pedido do usuário tem custo. Um copiloto vendido a R$ 49 por mês pode lucrar R$ 40 com um cliente e perder R$ 29 com outro, como mostra a conta mais abaixo. No SaaS clássico, isso não acontecia. Na IA, é o primeiro número que o PM precisa conhecer.

Durante muito tempo, modelar um produto digital apoiava-se em perguntas estáveis: tamanho do mercado, personas, proposta de valor, diferenciação, custo de aquisição e retenção. Em produtos com IA, elas continuam valendo, mas não bastam. O custo muda com o uso e a qualidade nunca é garantida. Os modelos pioram com o tempo se ninguém cuida deles (é a deriva, ou drift). E a vantagem vem menos de uma funcionalidade isolada e mais do conjunto: dados, modelos, a forma como eles são coordenados e o que o sistema aprende com o uso.

Isso muda o trabalho de produto. O PM já não só traduz necessidades em funcionalidades. Ele precisa juntar estratégia, o que a tecnologia consegue fazer, a conta econômica, os dados de uso e os testes.

Não basta saber se o usuário deseja uma experiência. É preciso saber se o modelo a entrega com qualidade suficiente, se o custo de servir continua saudável com o crescimento e se a empresa está construindo ativos reutilizáveis.

A IA também mexe no próprio modelo de negócio. Às vezes reduz custo por automação. Às vezes muda o patamar de produtividade do usuário. Às vezes abre experiências antes inviáveis: copilotos, fluxos inteligentes, interfaces conversacionais. Ao mesmo tempo, traz novos custos: o processamento de cada pedido (inferência), monitoramento, avaliação, retreinamento, segurança e regras de controle. Ganhos e custos entram na mesma conta.

Sem essa visão, a empresa coleciona demos que não aguentam tráfego real nem a primeira revisão de margem.

Por que o modelo não é o ponto de partida?

A armadilha mais comum é começar pela tecnologia. A equipe discute qual modelo usar, qual provedor é mais barato, se vale RAG ou fine-tuning, se um agente parece mais moderno. As perguntas importam, mas são prematuras enquanto o problema não está definido.

O ponto de partida é um problema valioso. O modelo vem depois, quando já se sabe que tipo de erro é tolerável e quanto se pode gastar por resposta.

Problemas bons para IA costumam ter traços em comum:

• classificar, prever, priorizar ou resumir em grande volume;
• dados livres, sem formato fixo: texto, imagem, áudio, registros de sistema;
• personalização para muitos usuários ou fluxos com muitas variações;
• decisões em que acertar um pouco mais vezes já vale dinheiro.

Mesmo assim, nem todo problema "bom para IA" é um bom problema de negócio. Para a oportunidade ser real, ela precisa passar em três filtros:

1. Frequência. O problema acontece o bastante para o impacto ser recorrente, não pontual.
2. Relevância. Mexe em custo, risco, receita, produtividade ou experiência.
3. Dados. Há base suficiente para a IA funcionar de forma aceitável.

Se faltar um dos três, o produto parece promissor só em apresentações. Viabilidade técnica sem densidade de dados ou sem relevância operacional raramente vira modelo de negócio.

Essa etapa obriga o PM a dizer "não" a casos sedutores e estruturalmente fracos. O melhor caso de uso raramente é o mais futurista. É aquele em que frequência, impacto e dados apontam para o mesmo lado.

Um teste de frequência rápido: se a tarefa ocorre 3 vezes por mês por usuário e economiza 10 minutos cada, o ganho é de 30 minutos mensais. Se ocorre 40 vezes, são quase 7 horas. A mesma funcionalidade, com o mesmo modelo, vale mais de dez vezes mais no segundo caso.

Qual motor econômico a IA move no seu produto?

A conversa sobre valor costuma ficar abstrata. Diz-se que a IA "melhora a experiência" ou "deixa o produto mais inteligente", sem lógica econômica por trás. Para o PM, isso não basta.

A IA cria valor por seis caminhos recorrentes:

• reduz custo ao comprimir trabalho manual;
• acelera fluxos, encurtando o tempo entre entrada e resultado;
• aumenta precisão, com menos erro e retrabalho;
• detecta risco cedo, com peso enorme em fraude, crédito, suporte e compliance;
• melhora a experiência, deixando o produto mais fluido e contextual;
• abre novos usos, como copilotos, agentes e raciocínio assistido.

O erro está em tratá-los como equivalentes. Num produto, o motor é economia de tempo. Noutro, processar muito mais volume com a mesma equipe. Noutro, retenção maior ou ticket médio mais alto.

O PM precisa escolher o motor central, porque ele define as métricas de sucesso, o posicionamento e até a forma de cobrança. Sem essa escolha, a proposta de valor fica difusa e não vira compra, retenção ou expansão.

Às vezes o motor está onde ninguém olhou. Uma equipe que tenta cobrar mais pode descobrir que o ganho estava na ativação: quem chega ao momento "aha" durante a configuração paga mais e fica mais tempo. O motor de receita pode estar num passo do funil que não parece comercial, e só a análise por coorte de ativação mostra isso.

Custo e valor também não andam juntos. Uma função cara de servir pode gerar pouco valor marginal. Uma função barata pode sustentar disposição a pagar alta porque resolve um problema crítico. Muitos times só percebem essa assimetria quando chega a primeira fatura do provedor em volume real.

Como saber se o motor escolhido é o certo? Um sinal barato é perguntar aos usuários ativos como se sentiriam se não pudessem mais usar o produto e cruzar a resposta com o uso da funcionalidade de IA. Se os "muito decepcionados" não forem os que mais a usam, o motor está em outro lugar.

O moat está no sistema, não no modelo

A defensabilidade em IA quase nunca vem do modelo isolado. Modelos se comoditizam rápido e APIs viram substituíveis. Trocar de provedor leva semanas. Reconstruir anos de feedback rotulado é outra história.

O que cria uma proteção difícil de copiar (o moat) é a soma de várias coisas: dados próprios, conhecimento do setor bem organizado, uma busca bem ajustada, o retorno dos usuários alimentando o sistema, integração profunda no dia a dia do usuário, uma interface pensada para ele e testes rápidos. O diferencial é uma máquina que transforma uso em aprendizado, aprendizado em qualidade e qualidade em valor para o cliente.

O exemplo público mais citado é a Netflix. Carlos Gomez-Uribe e Neil Hunt escreveram em 2015, na ACM TMIS, que as recomendações influenciavam cerca de 80% das horas assistidas e valiam mais de US$ 1 bilhão por ano para a empresa. O algoritmo, sozinho, não explica isso. O que explica é o volume de sinais de uso que alimenta o sistema todo dia.

Para o PM, isso muda a priorização. A melhoria mais estratégica às vezes está numa parte que ninguém vê: a base onde os documentos ficam prontos para busca, o sistema de avaliação, o plano B quando o modelo falha (fallback) ou a medição do uso.

Um teste útil para o backlog: se o concorrente trocasse de provedor amanhã e chegasse ao mesmo modelo, o que ainda o separaria do seu produto? Os itens que respondem a essa pergunta merecem prioridade.

E quando ainda não há dados próprios? Para muitos produtos, sobretudo os que não têm dados próprios no começo, o moat de sistema é uma promessa distante. O que os protege nos primeiros 12 a 18 meses é distribuição: um canal, uma integração com o software que o cliente já usa, uma base instalada. Nesse ponto quem desconfia do moat de sistema tem razão. Na prática, se você ainda não tem volume de uso para alimentar loops de feedback, priorize distribuição e integração, e trate a camada de dados como investimento que começa a pagar depois de alguns milhares de usuários ativos.

Erros recorrentes na modelagem de negócio de IA

Alguns erros se repetem com frequência suficiente para virar padrão; abaixo, cada um vem acompanhado do sinal prático que ajuda a percebê-lo a tempo.

• Começar pelo modelo e só depois procurar o problema. Por quê: o entusiasmo técnico antecipa a escolha de RAG, fine-tuning ou provedor antes de existir um problema frequente e com dados. Como perceber: a equipe descreve a solução em detalhe e o problema em uma frase vaga.
• Confundir a saída do modelo com valor. Por quê: "mais inteligente" ou "mais automatizado" não vira métrica. Como perceber: ninguém consegue dizer que decisão melhorou, quanto e a que custo.
• Tratar todas as rotas de valor como iguais. Por quê: sem definir o motor econômico dominante (custo, volume processado ou retenção), o preço sai difuso. Como perceber: a proposta de valor muda conforme quem a apresenta.
• Medir só o usuário e ignorar o modelo. Por quê: em IA a qualidade varia com drift, contexto e latência. Como perceber: o painel mostra ativação e retenção, mas não taxa de alucinação, latência p95 nem custo por inferência.
• Otimizar a demo em vez da defensabilidade. Por quê: a feature vistosa esconde camadas frágeis de dados, avaliação e orquestração. Como perceber: impressiona na apresentação e quebra sob carga real.

Mapear e priorizar capacidades antes das funcionalidades

O mapa de capacidades transforma ambição estratégica em blocos operáveis. Em vez de uma coleção de funcionalidades, o PM enxerga capacidades que precisam funcionar em cadeia. Muitas falhas de escala nascem nas camadas invisíveis que sustentam a interface.

As capacidades costumam cair em quatro camadas:

1. Dados: como os dados circulam, são preparados para busca, guardados, anotados e revisados.
2. Modelos: modelos base, versões ajustadas, busca nos documentos próprios (RAG) e testes de qualidade.
3. Orquestração: as instruções (prompts), os agentes, as regras que escolhem o modelo para cada pedido, o plano B e o controle do contexto.
4. Experiência: onde o usuário percebe valor, em copilotos, automações, recomendações e interfaces conversacionais.

Cada capacidade responde a quatro perguntas. Que valor entrega ao usuário? Que limitação técnica impõe? Que custo operacional introduz? Que avaliação ou governança exige? Quando a relação fica implícita, o time subestima dependências e lança experiências fortes na superfície e frágeis por baixo.

Uma planilha simples já ajuda. Para cada capacidade, compare RAG contra fine-tuning, modelo grande contra pequeno, cache contra inferência dinâmica, qualidade contra custo.

A priorização segue a mesma lógica. Uma funcionalidade pode parecer urgente para o mercado e depender de dados frágeis, de um modelo caro demais ou de uma avaliação que ainda não existe. Nesse caso, quem sobe no backlog é a capacidade habilitadora.

O PM pesa se o modelo combina com o problema, se há dados suficientes, quão rápido e quão preciso precisa ser, de que outras peças depende, que riscos traz e se a conta fecha. Algumas capacidades resolvem um caso de uso. Outras resolvem dez. Algumas dão impacto imediato. Outras aceleram o aprendizado do time. Em IA, essas diferenças pesam direto na economia do negócio.

Uma regra de desempate: entre duas capacidades com custo parecido, priorize a que serve a pelo menos 3 funcionalidades do roadmap. Ela vai pagar a construção três vezes.

Suponha que um pipeline de avaliação custe 6 semanas de engenharia. Usado por uma só funcionalidade, sai por 6 semanas por funcionalidade. Usado por quatro, por um pouco mais de uma semana cada, e cada nova funcionalidade nasce com a régua de qualidade pronta. É por isso que capacidades compartilhadas costumam vencer funcionalidades vistosas na disputa por engenharia.

Medir o usuário e o modelo na mesma tela

Produtos de IA criam uma exigência analítica nova. Não basta medir o comportamento do usuário. É preciso medir o comportamento do modelo e a interação entre os dois.

No software clássico, o sistema é estável e a análise foca ativação, retenção e conversão. Na IA, a qualidade varia com a distribuição dos pedidos, a qualidade dos dados, a deriva do modelo e as decisões de orquestração.

São duas famílias de métricas:

• Comportamento: ativação, profundidade de uso, conclusão de tarefa, tempo economizado, retenção, impacto por funcionalidade.
• Modelo: quantas respostas estão certas, quantos casos ele encontra, relevância, quantas respostas inventa, tempo de resposta, custo por pedido e sinais de que está piorando.

Painéis separados ajudam pouco. O trabalho é conectar as duas famílias: que latência destrói adoção, que erro mina confiança, quanto de deriva começa a afetar retenção, em que ponto o custo por inferência compromete a margem.

A latência é o exemplo mais fácil de quantificar. Cada segundo a mais entre a pergunta e a resposta custa conclusões de tarefa, e um modelo melhor que responde mais devagar pode perder dinheiro. A medida está no próprio produto: comparar a taxa de conclusão por faixa de latência p95 mostra onde fica o limite que os usuários toleram.

Há outro alerta que todo PM de IA deveria guardar: ganhos offline não se transformam de forma confiável em ganhos de negócio. A métrica do modelo melhora, a receita não se mexe.

Há ainda o funil completo. A IA pode melhorar o onboarding, encurtar o tempo até o valor, prever upsell e antecipar churn. A instrumentação precisa nascer desenhada para capturar esses efeitos. Sem isso, a IA é julgada por sinais locais e o impacto no negócio fica invisível.

Experimentos que provam viabilidade

Na IA, a experimentação deixa de servir só para escolher a melhor interface. Vira o principal mecanismo para validar viabilidade: do modelo, da segurança, do custo e da estabilidade em ambiente real.

No teste A/B clássico, a pergunta é qual versão o usuário prefere. Aqui ela vem com outra: o sistema aguenta a versão vencedora com custo e risco aceitáveis?

Testes com dados históricos continuam úteis. São rápidos e baratos. Mas os testes com usuários reais mostram o que o histórico esconde: pedidos inesperados, casos raros, uso oportunista, mudança no tipo de pedido e pico de carga. Por isso o desenho precisa acompanhar desempenho do modelo, segurança, latência, frequência de fallback e impacto econômico.

Avaliar com outro modelo, o chamado LLM como juiz, acelera o ciclo, mas tem vieses conhecidos: juízes automáticos tendem a preferir respostas mais longas, a resposta que aparece em certa posição da comparação e textos parecidos com os que eles mesmos geram. Mesmo quando concordam com avaliadores humanos na maior parte dos casos, uma amostra revisada por pessoas continua obrigatória.

As travas de segurança (guardrails) ganham peso estratégico. Quantas respostas inventadas se toleram, que conteúdo é proibido, a partir de que taxa de falha se para, quando entra o plano B e que nível de confiança se exige: isso marca até onde o produto continua viável como negócio.

O rigor estatístico vem do desenho: tamanho de amostra, duração suficiente para pegar a variação dos pedidos, guardrails definidos antes de olhar os resultados. Encerrar o teste no primeiro dia em que a variante parece vencer anula esse desenho.

Métrica e trava. Num copiloto de atendimento, a métrica principal pode ser a taxa de conclusão de tarefa sem ajuda humana. As travas: latência p95 abaixo de 3 segundos, taxa de alucinação na amostra revisada abaixo de 2% e custo por tarefa concluída abaixo de R$ 0,50. Se a variante vence na métrica principal e rompe uma trava, ela não sobe. Escrever as três travas antes do teste é o que impede a discussão de virar opinião depois.

A decisão de seguir ou recuar continua sendo do PM, e pesa o que se sustenta em produção, além do que venceu na métrica principal.

Custo de servir: a conta que decide se o produto sobrevive ao sucesso

A modelagem financeira costuma ser o filtro final. Em SaaS tradicional, o PM podia simplificar custos e deixar detalhes para engenharia ou finanças. Na IA, não. O custo de servir depende de uso, contexto, frequência, modelo e arquitetura.

Os custos variam com o tamanho do modelo, o comprimento do contexto, os tokens gerados, o tráfego, o cache e a eficiência da orquestração. Pequenas decisões de UX mexem nessa estrutura. Prompts maiores, respostas mais longas ou raciocínio mais profundo aumentam o valor percebido e, ao mesmo tempo, corroem a margem.

Uma conta inventada, mas típica. Imagine um copiloto para escritórios de contabilidade vendido a R$ 49 por mês por usuário. Cada resposta sai por R$ 0,03 de inferência, e cada conta tem R$ 3 de custo fixo de hospedagem e avaliação.

• Usuário leve: 200 respostas por mês. Custo: R$ 6 + R$ 3 = R$ 9. Margem: R$ 40.
• Usuário pesado: 2.500 respostas por mês, concentradas na apuração do Simples Nacional. Custo: R$ 75 + R$ 3 = R$ 78. Margem: menos R$ 29.

A correção: incluir 600 respostas no plano e cobrar R$ 0,05 por resposta excedente. O usuário pesado passa a pagar R$ 49 + 1.900 × R$ 0,05 = R$ 144, contra R$ 78 de custo. O prejuízo de R$ 29 vira R$ 66 de contribuição. O usuário leve nem percebe.

Sem a franquia, o mix decide tudo. Com 90 usuários leves e 10 pesados, a contribuição total é R$ 3.600 menos R$ 290, cerca de R$ 3.310 por mês. Com 60 leves e 40 pesados, cai para R$ 2.400 menos R$ 1.160, R$ 1.240. A receita é a mesma nos dois casos.

O pico também conta. Se metade do uso dos contadores cai nos cinco primeiros dias úteis do mês, a infraestrutura precisa ser dimensionada para o pico, e a média engana. Esse custo de capacidade ociosa entra na conta fixa.

Fica uma dúvida em aberto: o usuário pesado aceita a franquia ou migra para um concorrente? Isso só um teste de preço com coorte real responde.

Produtos de IA carregam ainda custos para se manter vivos: preparar e rotular dados, ajustar o modelo, avaliar, testar de novo o que já funcionava, infraestrutura, monitoramento e correção quando o modelo piora. Muitas vezes, somados, superam o investimento inicial no modelo. Um modelo financeiro honesto projeta essas despesas mês a mês com a curva de uso e mostra em que volume a margem por cliente fica negativa.

Na cobrança, as estratégias giram em torno de quatro famílias: cobrança por uso, acesso escalonado, preço baseado em valor e modelos híbridos. Escolher entre elas exige entender se o cliente paga por volume, capacidade, resultado ou uma combinação. A escolha só é boa quando conversa com a estrutura de custo e com as métricas de valor.

O teste de cinco linhas antes do roadmap

Toda essa complexidade cabe num fluxo de trabalho com ordem:

1. Definir o problema e a proposta de valor.
2. Verificar a viabilidade dos dados.
3. Mapear as capacidades necessárias.
4. Fixar critérios de avaliação do modelo.
5. Rodar os loops de experimentação.
6. Estimar custos antes do protótipo e refazer a estimativa com os resultados dos testes.
7. Planejar cenários e buscar o alinhamento organizacional.

A estimativa é refeita porque o consumo real de tokens quase nunca coincide com o do protótipo. E o alinhamento, frequentemente subestimado, é o que impede um caso promissor de virar ingovernável entre produto, dados, engenharia, operações e governança.

Se o produto trata dados pessoais, a LGPD entra já no passo 2. No copiloto contábil do exemplo, os documentos lidos trazem dados de clientes do escritório: a base legal para tratá-los e o lugar onde o modelo roda precisam estar definidos antes do protótipo, porque mudam a arquitetura e a conta de custo.

O fluxo não elimina a incerteza. Torna-a gerenciável. Antes da próxima revisão de roadmap, cada iniciativa de IA passa por cinco perguntas:

1. O problema é frequente, relevante e tem dados suficientes?
2. Qual é o motor econômico dominante e que métrica o comprova?
3. Que capacidade habilitadora falta e quanto custa construí-la?
4. Que limites de alucinação, latência e custo por inferência fariam o time recuar?
5. A cobrança acompanha a forma como o custo cresce com o uso?

Se a primeira resposta for fraca, a iniciativa sai da lista, por mais impressionante que seja a demo. Sem a segunda, volta para discovery até alguém dizer que decisão melhora e em quanto. As três últimas não barram o projeto, mas definem a ordem: primeiro a capacidade e os guardrails, depois a funcionalidade, por último a escala.

O teste tem um ponto cego: as respostas valem para o modelo e o preço de hoje. Uma troca de fornecedor ou uma janela de contexto maior muda a quarta e a quinta linha sem que ninguém reabra a lista, por isso ela volta à pauta a cada revisão.