Em uma aula para milhares pessoas presente no Pcamp, Marty Cagan explicou por que muitas carreiras em Produto estão em risco e qual é o papel do Product Model nisso.
No Product Camp, diante de um público de mais de 3.000 pessoas, com todas as salas transmitindo a palestra, Marty Cagan abriu a sua fala com um misto de admiração e preocupação.
Ele relembrou sua primeira visita ao Brasil em 2007, quando, segundo ele, quase não existiam profissionais de Produto no país. De lá para cá, voltou cerca de 15 a 20 vezes, principalmente para São Paulo e Rio, e acompanhou o crescimento da comunidade.
Mas, em vez de celebrar apenas o avanço da indústria, Marty escolheu outro caminho:
Ele disse estar genuinamente preocupado com o futuro de muitas carreiras em Produto, não só no Brasil, mas no mundo todo.
Ao longo da apresentação, ele explicou:
- Por que empresas já estão concluindo que “não precisam mais” de algumas funções de produto.
- O que é, de fato, o Product Model (product operating model).
- Por que Product Managers e Product Leaders são centrais nessa mudança.
- E como a IA está acelerando tudo isso.
O conteúdo a seguir resume, os principais pontos da apresentação de Marty Cagan no Product Camp.
“Muitas carreiras em Produto estão em risco”
Logo no início, Marty deixa claro o objetivo da palestra era usar hora para “assustar” um pouco o público, para que todos levem a sério a necessidade de evoluir suas habilidades.
Segundo ele, em várias partes do mundo, empresas já estão olhando para seus times de produto, especialmente Product Managers e Product Owners e, em muitos casos, concluindo que não precisam mais destes profissionais. Essa é uma tendência global, não limitada ao Brasil.
Marty ressalta que pode estar errado em algumas previsões, mas que, no ponto central, o risco concreto para carreiras em Produto, ele acredita que não está:
Para ele, já há sinais suficientes em diferentes mercados de que essa transformação começou.
Por isso, a mensagem que fica é que todo profissional de Produto precisa investir seriamente em atualizar suas competências.
O que é o Product Operation Model?
Product Operation Model = de output para outcomes
Marty define o Product Model como um conjunto de conceitos, competências, e, principalmente, um conjunto de princípios.
Na forma mais curta, ele resume assim:
O Product Model é a mudança de entregar projetos e features em um roadmap para entregar soluções que geram resultados de negócio (outcomes).
Ele contrasta dois modelos:
- Project / Feature Model
- A empresa financia projetos.
- Stakeholders pedem features.
- O time constrói e entrega.
- O foco está em output.
- Product Operation Model
- A empresa trabalha com problemas a serem resolvidos.
- Times são responsáveis por encontrar soluções que clientes amam e que funcionam para o negócio.
- O foco está em outcomes, não em quantidade de entregas.
Marty cita um dado da Harvard Business Review que em média, 85% das features de um roadmap não geram o resultado esperado pela empresa, o que significa apenas 15% de “sucesso”. Na leitura dele, esse é o sintoma mais claro de que “Colocar algo no roadmap” não é garantia de resolver um problema real. Por isso, o Product Model propõe um enquadramento diferente:
Em vez de dizer a um time “construa essa feature”, a empresa deveria dizer “resolva esse problema”.
Segundo Marty, é isso que caracteriza um empowered product team. Um time que recebe um problema e um outcome, e não um pacote de requisitos fechados.
Product Model ≠ Product Management Model
Marty faz questão de esclarecer alguns equívocos comuns:
- Product Model não é “modelo de Product Management”.
- Product Management é apenas uma parte do Product Model.
- Product Management é apenas uma parte do Product Model.
- Product Ops não é o mesmo que Product Operating Model.
- Ele comenta que a semelhança dos nomes em inglês causa confusão.
- Existem empresas com Product Ops sem trabalharem no Product Model, e vice-versa.
Outro ponto direto, que ele destaca é:
Se a empresa tem pessoas chamadas Product Owners, isso é um forte indício de que ela não está usando o Product Model.
Ele está se referindo, especificamente, a Product Owners formados em certificações como CSPO ou PSPO, cuja atuação se concentra em processos de entrega (delivery).
Na visão de Marty, o Product Owner, nesse formato, é um papel de delivery, focado em backlog e requisitos. Enquanto, o Product Manager, como ele defende, é um papel de discovery, responsável por descobrir a solução certa.
As três dimensões do Product Model
Ao longo da fala, Marty apresenta um “mapa” do Product Model com três grandes dimensões:
- Como a empresa escolhe quais problemas vai resolver
- Como os times descobrem soluções para esses problemas
- Como constroem, testam e entregam essas soluções continuamente
Dimensão 1 – Escolher os problemas certos (Product Strategy)
Segundo Marty, muitas empresas, no final do ano, decidem o que vão trabalhar no ano seguinte. Ele chama isso de Product Strategy. A escolha dos problemas mais importantes para a empresa resolver e das ameaças mais relevantes a enfrentar.
Ele destaca alguns pontos:
- O Product Model usa práticas e técnicas para ter uma visão holística de problemas e oportunidades.
- Não se trata apenas de stakeholders pedirem financiamento para projetos específicos.
- É um trabalho que envolve Product Leaders e, muitas vezes, os stakeholders juntos.
Marty também traz um aspecto político:
Todo bom time de Produto é capaz de “descobrir bons problemas” falando com clientes.
Mas, para ele, não é saudável começar por aí. A recomendação dele é que em vez de ignorar o que stakeholders já trazem, confie neles inicialmente, tratando os problemas que eles apontam como reais. Depois, com resultado entregue, eles passam a se interessar mais por novos problemas que o próprio time identifica.
Dimensão 2 – Mudar como resolvemos problemas (Product Discovery)
Depois de escolher os problemas, entra a disciplina de Product Discovery.
Marty afirma que, no Project Model, é comum um stakeholder apontar um problema, sugerir uma solução e o time ir direto construir “o que foi pedido”.
Enquanto no Product Model, o movimento muda, pois precisamos saber primeiro, “qual é exatamente o problema?” “para quem esse problema é relevante?”, “como saberemos se tivemos sucesso?”, “quais são as possíveis soluções?”
O objetivo do discovery é:
Chegar a uma “solução que vale a pena ser construída”, isto é, uma solução valiosa, usável, factível e viável.
Marty diferencia:
- Problem discovery – descobrir quais problemas existem.
- Solution discovery – testar diferentes abordagens para encontrar uma solução que gera o outcome desejado.
Na prática, ele diz é que problemas normalmente são definidos por Product Leaders e stakeholders, em conjunto E o time de produto recebe o problema e é responsável por descobrir a solução.
Ele reforça que nem tudo é um “problema de produto” arriscado. Existem atividades de “keep the lights on”, débitos técnicos, manutenção etc. Mas o foco do Product Model, nessa dimensão, são os problemas mais relevantes e arriscados.
IA dentro do Discovery
Marty coloca a IA em dois contextos:
- Uso de IA para construir produtos “convencionais”, onde a maioria das pessoas, inclusive em empresas de IA, não está construindo “produtos de IA”, mas produtos normais com apoio de ferramentas de IA. E essas ferramentas ajudam principalmente em delivery e, em menor medida, em discovery (prototipação, simulação).
- Construção de produtos de IA (smart product, predictive product, probabilistic product), segundo Marty, esse tipo de produto é, hoje, mais lento e difícil de construir do que produtos tradicionais, pois envolve conceitos como avaliação (eval) e traz novos desafios para Product Managers e designers.
Ele também comenta uma mudança em processos seletivos para empresas que já trabalham no Product Model. O novo formato busca testar as habilidades essenciais de Descoberta (Discovery) e criação, que são o cerne do trabalho do PM.
O novo formato de entrevista exige:
- A apresentação de um problema a ser resolvido.
- A pergunta: “Qual é a sua ferramenta de prototipagem favorita?”.
- A criação de um protótipo e a demonstração de como o candidato irá testar essa solução.
Essa abordagem “atinge o cerne do que realmente é o trabalho de product manager“. Isso reforça a visão de que o PM é um “criador de produto” (product creator). As empresas fazem o candidato criar um protótipo durante a entrevista para mostrar que ele entende o que significa ser um criador e um construtor.
Importante esclarecer o uso dos termos “Product Creator” e “Builder”.
- “Product Creator”: Este é o termo usado para definir a função do PM na era da IA. Ele é descrito como um criador, assim como o designer e o engenheiro são criadores.
- “Builder”: O termo “builder” é usado em conjunto com “creator” para reforçar a natureza prática e hands-on da função. As empresas que adotam o Product Model exigem que o candidato a PM crie um protótipo durante a entrevista para mostrar que ele entende o que significa ser um criador e um construtor.
O Foco no Novo Product Manager.
Embora ele use a palavra “builder,” Marty Cagan esclarece que a responsabilidade do PM não é construir o produto (a função de engenharia), mas sim descobrir o produto certo para construir.
A chave é que o Product Manager precisa criar os protótipos que permitem aprender e validar se a equipe tem a solução correta. É essa mentalidade de criador/construtor que é essencial para o sucesso na Descoberta de Produto (Product Discovery), que se torna o caminho crítico na nova era.
Dimensão 3 – Mudar como entregamos (Delivery moderno)
Na terceira dimensão, Marty fala sobre construção, testes e deploy. Ele demonstra frustração com o fato de que há 20 anos, muitos times de produto já trabalhavam melhor nessa parte do que vários times hoje, que adotaram processos excessivamente pesados. Ele critica explicitamente abordagens muito burocráticas (como SAFe – Scaled Agile Framework) e afirma que essas estruturas não cabem na realidade atual.
Para ele, alguns pontos são básicos:
- Deploy, no mínimo, quinzenal; idealmente, contínuo.
- Uso efetivo de ferramentas de analytics.
- Instrumentação completa do produto para ter dados de uso, experimentos e monitoramento.
- Capacidade de fazer testes A/B e rollbacks quando necessário.
Marty reforça um ponto-chave:
Se o Product Model é “mover de output para outcome”, é impossível provar outcomes sem dados.
Ele comenta que muitas empresas possuem licenças de ferramentas de analytics, mas não usam de fato esses recursos. Na opinião dele, se uma empresa ainda faz releases mensais ou trimestrais essa empresa está em perigo e isso deveria ser comunicado ao CEO.
Product Manager na era da IA: de “dono de backlog” a “criador de produto”
Uma parte central da palestra é dedicada ao papel do Product Manager.
Product Manager como “product creator”
Marty define o PM, na era da IA, como um criador de produto, e não alguém que só explica ao time o que deve ser construído ou alguém que apenas organiza as tarefas.
Ele diz claramente que “Explicar o porquê” para o time levaria 30 minutos por semana e isso não é um trabalho de tempo integral. Além disso, o “porquê” vem, em grande parte, de líderes e estratégia, não apenas do PM.
O trabalho real do PM, para ele, é:
- Criar protótipos que permitam aprender se a solução está no caminho certo.
- Ser responsável pela proposta de valor da solução, se os clientes vão usar ou comprar.
- Garantir a viabilidade da solução dentro da empresa (marketing, vendas, suporte, jurídico, compliance, segurança, modelo de monetização etc.).
Ele enfatiza que isso não é trivial e é exatamente o que diferencia o PM dentro do time.
Valor, viabilidade e “product sense”
Na visão de Marty, o Product Manager é responsável por valor e viabilidade e responsável, no fim, pelo outcome do que o time entrega.
Ele afirma que muitos designers e engenheiros, em alguns times, não veem a utilidade de certos Product Managers, porque esses PMs não fazem esse trabalho de valor/viabilidade.
Quando o PM atua como ele descreve:
- A relação muda.
- Designers e engenheiros passam a ver claramente a importância da função.
Marty destaca algumas características essenciais dos PMs mais valorizados hoje:
- High agency – capacidade de encontrar caminhos mesmo com obstáculos (liderança difícil, falta de recursos, pouco entendimento da diretoria e etc).
- Julgamento forte: especialmente em decisões de produto.
- Product sense: capacidade de sentir o que faz ou não sentido no produto, baseada em exposição constante a:
- Usuários e clientes (toda semana).
- Dados de produto (pelo menos uma hora por dia).
- Engenheiros (para entender novas possibilidades tecnológicas).
- Stakeholders de negócio (para entender restrições e objetivos).
Ele comenta que em alguns contextos, Product Owners estão entre os primeiros a serem demitidos e alguns tipos de Product Managers também, quando não geram valor percebido. Por outro lado, PMs que atuam como descrito por ele têm visto aumentos salariais entre 50% e 100% em empresas que trabalham nesse modelo.
Tipos de times de produto: delivery, feature e empowered
Marty também classifica as equipes de Produto em três grupos:
1. Delivery Teams
- Basicamente, desenvolvedores + Product Owner.
- O PO traduz pedidos de stakeholders em backlog, histórias, PRDs etc.
- O foco é entregar o que foi pedido.
2. Feature Teams
- Mais comuns em alguns mercados.
- Executivos e stakeholders acabam atuando, na prática, como “verdadeiros PMs”.
- O Product Manager fica apenas organizando e repassando demandas.
- Isso leva a roadmaps cheios de itens que não entregam resultado.
1. Empowered Product Teams
- A grande diferença é que quem representa o negócio é o Product Manager, e não o stakeholder.
- O PM representa a viabilidade e conecta com vendas, marketing, financeiro, jurídico, compliance etc.
- O designer representa usabilidade/experiência.
- Os engenheiros representam a tecnologia.
- O time recebe problemas e metas, não apenas features.
Segundo Marty, é esse terceiro modelo que está no centro do Product Model e que deve ser o objetivo de transformação.
Product Leaders: o papel que “amarra” tudo
Marty dedica uma parte importante aos Product Leaders (gestores de PMs, designers e engenheiros).
Ele afirma que:
Product Leaders são a chave de toda a transformação.
Entre as responsabilidades que ele lista para esses líderes estão:
- Articular uma visão de produto clara e convincente.
- Não faz sentido cada PM ter sua própria visão isolada.
- Definir a Product Strategy – quais são os problemas mais importantes a serem atacados.
- Atribuir esses problemas aos times – é assim que se pratica empowerment.
- Garantir que todos os times tenham:
- acesso direto a usuários e clientes,
- acesso a dados,
- contato com stakeholders.
- Treinar e desenvolver as pessoas de produto, especialmente em discovery e estratégia.
Ele introduz o conceito de “contexto estratégico”, mesmo com times fortes, um time individual não sabe, sozinho, se suas decisões são as melhores para a empresa como um todo. É função da liderança prover esse contexto de visão, estratégia, prioridades e como o trabalho dos times se conecta.
Marty menciona um princípio usado na Netflix:
“Lead with context, not control” (liderar com contexto, não com comando e controle).
Ele também reforça que Empowerment não é ausência de gestão. É um estilo de liderança em que líderes fazem perguntas intencionais, sabem profundamente o trabalho (já fizeram antes) e conseguem orientar equipes em vez de apenas “aprovar” ou “mandar”.
As perguntas do público: pressão por IA, futuro do PM e como começar
Na parte final, Marty responde perguntas da audiência.
Alguns temas que aparecem:
“Meu board está me pressionando para ‘fazer AI’. Isso é normal?”
Marty responde que isso está acontecendo “em todo lugar” e que recebe muitos relatos de pessoas sendo pressionadas a “colocar IA no produto” apenas para marcar a caixa de “somos uma empresa de IA”. Ele compara essa fase com momentos anteriores da corrida para “ter internet” e para “ter mobile”. Segundo ele, em breve, todas as empresas terão um “checkbox” dizendo que usam IA. Depois, a pergunta mais importante deixará de ser “tem IA?” e passará a ser se “Isso é bom?” ou “Resolve um problema real?”
Ele também comenta que essa pressão não é totalmente negativa, porque obriga empresas a descobrirem o que não sabem sobre IA. Ao tentar construir produtos de IA, elas percebem a dificuldade real e conceitos como avaliação e o papel extra de PMs e designers nesses produtos.
“Qual é o maior impacto da IA hoje em times de produto?”
Marty responde olhando para dois pontos:
- Descobrir o que construir (discovery)
- Construir o que foi decidido (delivery)
Ele afirma que o maior impacto atual da IA tem sido em delivery, com ganhos de produtividade de cerca de 15% a 30% para desenvolvedores, segundo alguns benchmarks. Isso já está reduzindo o tamanho médio dos times (por exemplo, de 7–8 devs para 6–7 por produto).
Se fica mais barato e rápido construir, o principal gargalo passa a ser “o que construir”. Por isso, este momento é, segundo ele, “a melhor fase da história para Product Discovery e Product Strategy”. Ele observa que, no passado recente, houve discursos dizendo que “não precisaríamos mais de Product Managers”. Agora, vê o movimento oposto: CEOs dizendo que estão aumentando o número de PMs, porque essa função se tornou crítica.
“Minha empresa não usa o Product Model. Como faço para ela começar?”
Marty considera essa a pergunta mais importante, porque reflete a realidade de muitas empresas. Ele compartilha algumas ideias, como por exemplo, mencionando seu novo livro, “Transform”, voltado não só a pessoas de Produto, mas também a CEOs e executivos, como uma forma de abrir o tema com lideranças. Reforça que, mesmo sem mudar a empresa inteira, cada pessoa pode elevar suas próprias habilidades, aprendendo mais sobre clientes, entender melhor dados e compreender marketing, vendas, compliance, segurança, monetização.
Ele relata já ter visto vários casos em que PMs que fizeram esse movimento foram promovidos ou ganharam mais responsabilidade.
Outra sugestão prática:
- Um PM ou time pode, mesmo ainda cumprindo o trabalho atual, experimentar uma forma diferente de trabalhar em um problema específico:
- construir protótipos,
- testar com usuários,
- voltar para os líderes com algo concreto.
E ele dá um conselho bem direto:
“Não vá com uma apresentação em PowerPoint. Vá com um protótipo.”
Segundo ele, na pior hipótese, os líderes não se interessam. Na melhor, que ele diz ser comum, eles pedem para mostrar aquilo ao chefe deles.
“E se os usuários estiverem muito distribuídos, difíceis de acessar?”
Uma pessoa pergunta sobre a dificuldade de acessar usuários quando eles estão distribuídos geograficamente. Marty responde com uma palavra-chave: agency. Ele lembra que já trabalhou com empresas em regiões remotas, em que tudo é feito à distância e cita o próprio uso de ferramentas de comunicação online (como Skype, no passado) para pesquisar e desenvolver produtos.
A mensagem dele é que obstáculos como distância e logística podem ser superados, e cabe ao profissional de Produto encontrar maneiras de fazer isso.
“Qual o recado final para Product Managers na era da IA?”
No encerramento, Marty retoma o ponto inicial que ele reafirma que não é mais uma questão de “seria bom fazer isso”, mas sim de “você precisa fazer isso”. Ou seja, atualizar habilidades, aprender discovery, entender profundamente clientes, dados, negócio e tecnologia, e sair do papel de “processo” e assumir o papel de criador de produto.
No mínimo, isso tornará o profissional mais valioso para a empresa e em muitos casos, pode ser o que mantém o emprego.
O que você leu
- Marty Cagan abriu sua fala no Product Camp Brasil preocupado com o futuro das carreiras em Produto.
- Ele afirmou que, em vários países, empresas já estão concluindo que não precisam mais de alguns Product Owners e Product Managers.
- Explicou o Product Model como a migração de “entregar features” para “entregar outcomes de negócio”.
- Destacou que Product Model ≠ Product Operating Model e que Product Ops não é a mesma coisa.
- Afirmou que, se a empresa tem Product Owners no formato tradicional, é um sinal de que provavelmente não está no Product Model.
- Apresentou as três dimensões do Product Model: escolher problemas, descobrir soluções, entregar continuamente com dados.
- Criticou ciclos longos de entrega e ressaltou a importância de analytics, experimentos e instrumentação.
- Definiu o Product Manager da era da IA como um criador de produto, responsável por valor e viabilidade.
- Apontou que alguns POs e PMs estão sendo demitidos, enquanto outros veem salários aumentarem entre 50% e 100%, conforme o tipo de atuação.
- Reforçou o papel central dos Product Leaders em visão, estratégia, contexto e desenvolvimento de times.
- Respondeu perguntas sobre pressão por IA, impacto da IA em produtividade, como iniciar a transição para o Product Model e como lidar com usuários distribuídos.
- Encerrou convocando todos a elevarem suas habilidades, tanto por relevância quanto por sobrevivência profissional.
Quer ter acesso e interar sobre o conteúdo completo da palestra do Marty Cagan no Product Camp?
Se você leu este artigo até aqui, já entendeu uma coisa:
A palestra do Marty Cagan no Product Camp não foi “mais uma talk”. Ela foi um alerta direto sobre o futuro das carreiras em Produto, sobre o Product Operating Model e sobre o impacto real da IA no trabalho de Product Managers, Product Leaders e times de produto.
Se você quer ir além do artigo e ter acesso a um workspace de aprendizado interativo, com conteúdo da palestra organizado para você consultar, conectar ideias e revisitar conceitos sempre que precisar, acesse gratuitamente:
Baixe o resumo interativo completo da palestra do Marty Cagan
Sobre o Product Camp Brasil
O Product Camp Brasil, também conhecido como PCamp, é o maior evento nacional voltados à comunidade de gestão de produtos digitais. Realizado anualmente em São Paulo, o evento reúne profissionais de Product management, design, tecnologia, dados, IA e negócios para debater tendências, compartilhar experiências e fortalecer a comunidade de Produto no Brasil.
Mais do que um evento, o PCamp é um ponto de vira
da. É onde você escuta quem vive os dilemas do dia a dia, quem já errou, acertou e aprendeu no processo. Aqui, não falamos de teorias distantes: trocamos experiências reais, compartilhamos aprendizados práticos e construímos conexões que continuam muito além dos dois dias de evento.
