O que você vai aprender aqui
- Por que a função de PM deixou de bastar sozinha, e o que veio no lugar
- Por que resolver uma dor bem resolvida vence lista de feature em produto não comoditizado
- Como identificar o cliente ideal (ICP) de um produto pela prioridade que ele dá ao problema, não pelo perfil demográfico
- Qual é a sequência real para ganhar fluência de negócio para quem ainda não entende de finanças ou de projetos
- Como montar um portfólio de produto que mostra resultado, não lista de tarefas
- Onde usar inteligência artificial para encurtar pesquisa de mercado sem terceirizar o raciocínio
Este artigo complementa o e-book gratuito Product Marketing Estratégico, que mostra como decisões de produto e de mercado se apoiam nas mesmas heurísticas de decisão do cliente.
Num bate-papo com a comunidade Bichinhos da TI, gente no início da carreira em produto trouxe as perguntas que mais pesam nessa fase: como migrar de desenvolvimento, o que estudar, como montar portfólio, como entender o cliente ideal. Respondi cada uma na hora, mas as respostas, juntas, formam uma ideia maior do que qualquer pergunta isolada: a carreira em produto se constrói com a mesma disciplina que se usa para construir um produto.
Depois de sete startups fundadas ao longo de mais de três décadas em tecnologia, e de anos dando aula sobre marketing de produto na ESPM, essa é a costura que aparece toda vez que alguém pergunta por onde começar.
Por que só entender de produto não basta mais
Em 2023, na conferência Config23 do Figma, o CEO do Airbnb, Brian Chesky, disse que a empresa havia se livrado da função clássica de product manager, porque designers e PMs passaram a ter o mesmo peso na decisão. A frase virou manchete de “o PM morreu” e gerou reação forte na comunidade de produto. Meses depois, Chesky reconheceu que deveria ter sido mais claro: a Airbnb não eliminou o cargo, redistribuiu o peso de decisão entre design e produto, no modelo que a Apple já usava.
O caso Airbnb é sobre produto e design, não sobre produto e marketing, mas a pressão que ele expõe é maior do que essa fusão específica. Na minha avaliação, o mesmo movimento aparece em qualquer empresa onde o PM (product manager, quem prioriza o roadmap e conduz o discovery, o processo de descobrir com o usuário qual problema vale a pena resolver antes de construir) precisa também entender como o produto chega ao mercado.
Esse terreno já tem nome, e não é novo: é o PMM, o product marketing manager, a disciplina que soma leitura de produto com mensagem, posicionamento e apoio a vendas. Não estou dizendo que a Airbnb renomeou o cargo para PMM; estou dizendo que a fronteira que a Airbnb testou com design é a mesma fronteira que o PMM já ocupa com marketing, e que os dois casos apontam para a mesma direção: quem cuida do produto não pode mais ficar de fora da conversa sobre como esse produto vai ao mercado.
Essa distinção importa mais do que a manchete original. O mercado ficou mais competitivo, e o PM que só olha dor do usuário, sem entender como o marketing fala do produto, como vendas argumenta a favor dele e como o suporte recebe o feedback depois do lançamento, joga com uma mão amarrada.
Vale separar os três nomes que aparecem juntos e confundem quem está começando, PM, PO e PMM, porque o PO (product owner) entra nessa conversa mesmo sem ter aparecido até aqui:
| Papel | O que decide | Foco do dia a dia |
|---|---|---|
| PM (product manager) | O quê construir e por quê | Estratégia, discovery e roadmap |
| PO (product owner) | Como e quando entregar | Backlog e alinhamento do time no sprint |
| PMM (product marketing manager) | Como o produto pronto chega ao mercado | Mensagem, posicionamento e apoio a vendas |
Numa empresa pequena, os três papéis pesam sobre uma pessoa só; numa empresa grande, cada um vira cargo separado, e a fronteira entre eles fica mais visível, e mais disputada.
Se eu fosse abrir uma startup hoje, não contrataria um PM nesse formato antigo. Contrataria alguém que também soubesse apoiar marketing, vendas e atendimento, porque as decisões de um produto raramente cabem só na conversa entre desenvolvimento e usuário.
O resultado prático é que quem está entrando em produto hoje entra numa área com fronteira mais larga do que a de cinco anos atrás. Isso também é oportunidade: quem chega já disposto a aprender essa fronteira larga sai na frente de quem só aprendeu o script antigo.
Resolver uma dor bem resolvida vence lista de feature
O erro mais comum de quem começa em produto é confundir valor com quantidade de funcionalidade. Um exemplo que uso em aula: um assistente de escrita que resolve um único problema, “escreva do seu jeito”, aprendendo o estilo da pessoa a partir dos textos que ela já escreveu em redes sociais e e-mails. Esse produto não precisa fazer mais nada. Quem sofre com esse problema paga só por essa função, porque ela resolve algo que está martelando na cabeça da pessoa todos os dias.
O oposto disso é o que chamo de over delivery: empilhar funcionalidade para competir em tabela comparativa, com colunas de “o que o produto A faz” contra “o que o produto B faz”. O cliente raramente usa a tabela inteira. Ele quer uma linha específica funcionando bem.
Uso sempre o exemplo pessoal do carro: não entendo nada de carro, mas ando muito de Uber, e a única coisa que me importa num carro é espaço para as pernas no banco de trás. O meu sonho de consumo automotivo é o BYD King, um sedã híbrido plug-in vendido no Brasil, não porque o design ou a autonomia me interessem, mas porque, toda vez que o Uber Black chega com espaço curto atrás, sinto que perdi na loteria, e o BYD King resolveria isso sozinho. Uma única funcionalidade bem resolvida pode colocar um produto no topo da lista de alguém, mesmo sem ele ser o mais completo do mercado.
Essa lógica muda quando o mercado é comoditizado. Numa categoria com muitos concorrentes parecidos e margem espremida, empilhar item na lista de funcionalidades passa a fazer sentido, porque a diferenciação por preço já foi exaurida. A régua para decidir qual dos dois jogos jogar é o quanto a categoria está espremida, não uma preferência pessoal por minimalismo.
Nessa conta entra também o financeiro, que tem poder de veto sobre funcionalidade cara demais para a margem, mas não deveria ter poder de decisão sobre qual funcionalidade construir: ouvir o financeiro é diferente de deixar o financeiro escolher o roadmap.
Na prática, isso funciona quando o PM chega com um número que mostra a preferência do público, não só opinião: se o dado aponta qual funcionalidade o cliente prioriza, os dois lados discutem o mesmo número, em vez de contrapor “eu acho que devemos construir isso” contra “isso custa caro demais”. Discussão de dado é mais fácil de fechar do que disputa de opinião.
Como descobrir quem sente o seu problema como prioridade número um
A pergunta mais recorrente de quem está começando é como achar o cliente ideal, o ICP. A resposta mais útil que já cheguei não veio de framework, veio de uma tentativa e erro real numa plataforma de recrutamento que ajudei a lançar. A plataforma cadastrava cientistas de dados e desenvolvedores para desafios técnicos com prêmio em dinheiro, e chegou a mais de 14 mil profissionais inscritos, todos com desempenho validado pelos próprios desafios. Do outro lado, faltava achar quem comprava.
O primeiro caminho, falar direto com times de recrutamento, andava devagar: gente de RH estava sempre ocupada com folha de pagamento, plano de saúde e cultura interna, e o produto entrava na fila. A virada aconteceu quando comecei a procurar especificamente o gerente de recrutamento e seleção, o cargo cuja única meta era fechar vagas abertas. Esse gerente vivia com uma prioridade número um fixa na cabeça, e o produto casava exatamente com ela: esse mesmo banco de candidatos já testados, pronto para gerar um desafio personalizado e ranquear quem contratar.
Com esse público, as reuniões aconteciam rápido, a demonstração era pedida, o contrato avançava. Com o público genérico de RH, a mesma conversa não saía do lugar.
Essa lição não fica presa a esse caso: de todas as pessoas que sentem a dor que você resolve, o ICP é quem sente essa dor como a maior prioridade do momento, não só mais uma entre várias. Duas ou três pessoas do mesmo cargo podem ter a mesma dor com intensidade diferente, uma trata como urgência, outra como algo que resolve quando sobrar tempo.
Chamo esse critério de “teste da agenda lotada”: quem tem o problema no topo da lista abre espaço na própria agenda para resolvê-lo agora, quem só sofre a dor pela metade sempre encontra motivo para adiar a reunião. Achar quem passa nesse teste muda o ritmo de vendas inteiro, porque é essa pessoa que separa agenda, orçamento e atenção agora, não depois.
A fluência de negócio que separa quem estagna de quem cresce
Todo setor tem seu próprio vocabulário fechado, o que costumo chamar de sopa de letrinhas: TI tem a sua, jurídico tem a sua, financeiro tem a sua. O erro de quem vem de tecnologia é achar que só a área técnica sofre com isso. Quando você senta numa reunião com marketing, jurídico e financeiro ao mesmo tempo, e não entende metade das siglas, a sensação de estar perdido é mútua: ninguém ali entende a sua sopa de letrinhas também. A saída é aprender a linguagem que costura todas as áreas: a de projetos, não decorar cada sigla.
Toda área trabalha com recursos, prazos e metas, o que já é o vocabulário básico de gestão de projetos. Entender isso primeiro permite negociar prioridade com qualquer departamento na mesma língua: “para cumprir essas tarefas nesse prazo, preciso de mais recurso, ou a gente muda a priorização”.
O passo seguinte é entender que, no fim, quase todo argumento de empresa madura se resolve em lucro: uma iniciativa que aumenta a margem ganha qualquer discussão, porque é isso que o financeiro, o board e a liderança querem ouvir. Numa startup em fase de crescimento, a métrica que decide a discussão pode ser outra, receita recorrente, retenção, participação de mercado, mas o teste é o mesmo: qual métrica o board está perseguindo agora, e o argumento se conecta a ela.
A sequência que ensino é sempre essa: primeiro comunicação e humildade de admitir o que não se sabe, depois o vocabulário comum de projetos, só então a leitura financeira que mostra o efeito de cada decisão na margem.
Esse argumento de lucratividade funciona, mas é situacional. Numa sala onde todos os presentes se beneficiam diretamente do resultado da empresa, um sócio, um conselheiro representando acionistas, o argumento de “isso aumenta a margem” derruba qualquer disputa de poder. Numa sala onde ninguém ali ganha nada com o resultado do ano, o mesmo argumento soa deslocado e pode até parecer oportunista.
Ler a sala antes de escolher o argumento é parte da fluência, não só decorar o argumento certo: a pergunta que separa os dois tipos de sala é se quem está ali quer resolver o problema do dia e ir para casa tranquilo, ou se quer que a empresa dê lucro no fim do ano. Composição diferente de sala pede negociação diferente, mesmo quando o produto em discussão é o mesmo.
Quem entende só de código, e se recusa a atravessar essa camada de negócio, tende a virar o que chamo de “pleno eterno”: tecnicamente bom, mas com teto de carreira baixo, porque quem decide promoção olha para quem consegue conversar com as outras áreas, não só para quem escreve o código mais elegante. Ninguém no mercado paga a mais por um código com menos linhas se esse código não resolver um problema que alguém está disposto a comprar. É essa mesma fluência que separa quem tem os arquétipos de liderança que Google, Amazon e Netflix cobram de quem fica travado no teto técnico.
Trate a sua carreira como você trataria um produto
A pergunta que mais aparece de quem está se recolocando é por que os portfólios parecem todos iguais. A resposta é que a maioria descreve o que fez, em vez de contar como descobriu o que fazer. Um portfólio forte troca “trabalhei nesses produtos, nessas empresas” por “esse produto tinha esse problema, resolvi assim, e o resultado foi esse”: a narrativa é de resolução de problema, não de inventário de tarefa.
Isso exige fugir do que chamo de métrica de vaidade: número de download, visitante de site, seguidor de rede social. Esses números dizem pouco sobre resultado de negócio. O que interessa para quem recruta é o número que impactou a companhia, e a história que levou até ele: o que importa é quantos desses viraram clientes pagantes, não quantos milhares baixaram um e-book gratuito, e qual foi a estratégia usada para converter. Essa é a mesma lógica por trás de transformar número em história que aprova projeto: o dado sozinho não convence, o que convence é o argumento que ele sustenta. O que pesa é como você fez, não só o que você fez.
O mesmo raciocínio de produto vale para entrevista de emprego. Times de venda gravam e transcrevem ligações para entender por que ganharam ou perderam um negócio; a maioria das pessoas nunca faz esse exercício com a própria carreira. Grave a entrevista, transcreva, peça para alguém apontar sem filtro onde você travou e o que poderia melhorar. E não olhe só para o que precisa corrigir: descubra também por que você foi chamado para aquela entrevista, porque essa é a parte que não pode estragar quando você ajustar o resto, do mesmo jeito que um produto não pode quebrar a funcionalidade que já funciona bem só para caber uma novidade.
Gosto de resumir essa ideia de especialização com uma imagem que uso em mentoria: um pato sabe nadar, voar e andar, mas ninguém compra pato por nenhuma dessas três coisas, compra pelo ovo. Um profissional pode ser razoável em várias frentes, mas o que faz alguém contratar é a frente em que ele é excepcional, não a média de tudo o que sabe fazer. Isso também muda como tratar cursos: fazer curso atrás de curso sem produzir nada no meio enfeita currículo e não convence ninguém. O ciclo que funciona é aprender, aplicar num caso próprio, mostrar o resultado, só então considerar o próximo curso.
A inteligência artificial encurtou uma etapa inteira desse processo. Uma análise de concorrência que antes tomava uma semana inteira de navegação manual, anotação e comparação, hoje sai em cerca de duas horas com uma ferramenta de IA generativa bem instruída: pedir para levantar concorrentes, diferença de público, de proposta de valor e de precificação entre eles. Isso não substitui o raciocínio, só corta o tempo de coleta: quem recebe o resultado ainda precisa ler com atenção, checar se a ferramenta não inventou nada e decidir o que fazer com aquilo.
Com esse atalho, chegar numa entrevista com uma análise de mercado pronta deixou de ser trabalho de uma semana e virou algo que qualquer pessoa em início de carreira consegue produzir antes da conversa.
Onde começar amanhã
Escolha um produto real que você admira ou usa, e escreva uma análise de mercado de duas páginas: quem são os concorrentes diretos, qual a proposta de valor de cada um, e qual público-alvo parece atender melhor. Aponte uma decisão de priorização que você tomaria diferente, com a justificativa. Publique isso no LinkedIn ou guarde como peça de portfólio, e leve para a próxima entrevista em vez de mais um certificado. Antes disso, vale garantir que o currículo já passa pelos filtros de IA que boa parte das empresas usa na triagem, senão essa análise de mercado nem chega a ser lida.
Se você já está trabalhando com produto, aplique o teste da agenda lotada na sua própria base de clientes: entre os perfis que já compram de você, qual deles trata o seu problema como prioridade número um, e não como mais um item da lista? Redirecione a próxima rodada de vendas ou de comunicação para esse perfil antes de tentar convencer quem só sofre a dor pela metade.
Este artigo se apoia em Carreira na era da inteligência artificial: 4 verdades duras para vencer a mediocridade para quem quer aprofundar a parte de posicionamento de carreira.
Se o tema conversa com a sua trajetória, o Consultor de Carreira é um caminho: um agente de IA que indica os cursos da minha curadoria na ESPM conforme o seu perfil.
Perguntas frequentes
Preciso saber programar para migrar para produto? Não precisa saber programar a fundo, mas precisa entender o básico de como o desenvolvimento funciona: o que é backlog, por que uma tarefa simples de explicar pode ser complexa de construir, e por que prazo depende de recurso disponível. Quem vem de dev tem vantagem inicial nessa conversa, mas quem vem de outra área consegue aprender esse vocabulário mínimo com estudo dirigido. O que não dá para pular é entender os dois lados, o técnico e o de negócio, porque o trabalho de quem está em produto é justamente traduzir um para o outro.
Qual o primeiro passo para migrar para produto sem experiência prévia? Construir um caso de uso, não colecionar certificado. Depois de um curso ou de uma leitura, feche o ciclo com algo concreto: um protótipo, uma análise de mercado de um produto real, um estudo de caso publicado no LinkedIn. Quem chega numa entrevista só com curso no currículo compete pior do que quem chega com algo para mostrar, mesmo que pequeno. O curso prova que você estudou; o caso de uso prova que você aplica.
O que colocar no portfólio se eu ainda não lancei nenhum produto? Uma análise de mercado feita por conta própria já conta como peça de portfólio, desde que mostre raciocínio, não só descrição. Escolha um produto real, mapeie concorrentes, proposta de valor e público de cada um, e aponte uma decisão que você tomaria diferente e por quê. O que pesa na avaliação de quem recruta é menos o produto que você escolheu, e mais a lógica que você usou para chegar à conclusão: como você definiria prioridade, como decidiria o que construir primeiro.
Qual a diferença entre PM, PO e Product Marketing Manager? São três papéis diferentes que costumam se confundir. O PM (product manager) decide o quê construir e por quê, cuidando de estratégia, discovery e roadmap. O PO (product owner) cuida do como e do quando entregar, gerindo o backlog e alinhando o time de desenvolvimento no sprint. O PMM (product marketing manager) cuida de como o produto já pronto chega ao mercado, mensagem, posicionamento e apoio a vendas. Em empresa pequena, uma pessoa acumula os três; em empresa grande, cada um vira um cargo, e a fronteira entre eles fica mais visível. Na prática, o PMM funciona como tradutor entre produto e mercado, e cresce quem consegue falar as duas línguas.
Como descobrir o cliente ideal (ICP) de um produto? Procure quem tem esse problema como prioridade número um, não só quem também sofre com ele. Duas ou três pessoas do mesmo cargo podem sentir a mesma dor com intensidades diferentes: uma trata como urgência diária, outra como incômodo que cabe resolver depois. O ICP costuma estar na primeira categoria, porque só quem tem o problema no topo da lista separa agenda, orçamento e atenção para resolvê-lo agora.
Vale a pena empilhar vários cursos de gestão de produto? Curso sem aplicação prática enfeita currículo e não move contratação. Quem recruta já viu esse padrão: certificado atrás de certificado, sem nada demonstrável no meio. O curso funciona melhor como ponto de partida de um ciclo: aprender, aplicar num caso próprio, mostrar o resultado, e só então considerar o próximo curso. Sem o meio do ciclo, o próximo curso vira o mesmo enfeite do anterior.
Por que desenvolvedores costumam resistir a aprender sobre negócio? Porque código tem uma previsibilidade que negócio não tem: a mesma entrada produz a mesma saída, e um erro aponta exatamente onde corrigir. Decisão de negócio envolve pessoas, e pessoas mudam de resposta dependendo do dia, do humor e do contexto, o que exige tolerância a ambiguidade que a lógica de programação não pede. Quem atravessa essa resistência costuma achar mais estimulante lidar com esse tipo de complexidade do que a complexidade técnica sozinha, mas a travessia exige aceitar que ali não existe teste automatizado para validar se a decisão foi certa.
Edney “InterNey” Souza atua com tecnologia desde 1990 como professor, palestrante e conselheiro em IA, dados e inovação. Participou da criação de sete startups ao longo da carreira. É professor na ESPM, Insper, PUCRS, USP e IBGC. É autor de vários e-books gratuitos sobre tecnologia, marketing, liderança e inovação, disponíveis nesta página de e-books gratuitos.
