Gerente de Produto: mercado

Vaga

uma vaga aberta que passou pelo filtro de qualidade e lista pelo menos duas tecnologias

Candidato observado

um candidato cujo stack contém esta tecnologia; um agregado — nenhum registro individual sai do perímetro

Candidato compatível

ainda não contado

Janela

vagas abertas no momento em que o snapshot foi gerado

O Junior / Associate PM conduz uma pequena parte do produto ou features individuais sob mentoria. Salto para Pleno — propriedade independente de uma direção: discovery, priorização, métricas, lançamentos. O Sênior é responsável por um produto grande ou uma direção importante, influencia a estratégia. O Group / Lead PM gerencia vários produtos ou um time de PMs. Fluxo de carreira: (muitas vezes de analytics, desenvolvimento, BA, marketing, suporte) → Associate / Junior PM → Pleno → Sênior → Group / Lead PM → Head of Product → CPO. Vagas de Júnior puro são poucas — a entrada na profissão é competitiva (veja a pergunta à parte).

Top ferramentas: go, agile, visio, git, product owner. Ferramentas: Jira + Confluence (backlog, documentação), Figma (design e protótipos), analytics (Amplitude, Mixpanel, Yandex Metrika, GA4), SQL (requisito crescente — obter dados você mesmo), Miro, ferramentas de roadmapping, ferramentas de IA para pesquisa e análise de feedback. Skills-chave: product thinking — enxergar o problema do usuário e o valor por trás das features; discovery — custdev, entrevistas, teste de hipóteses, análise de mercado e concorrentes; trabalho com métricas — definir, calcular e mover as métricas de produto certas, unit economics, árvore de métricas; priorização — decidir o que fazer e o que não fazer, e argumentar; estratégia e roadmap — a visão de produto e o caminho até ela; testes A/B — validar mudanças com experimentos; trabalho com o time — definir tarefas, explicar o "porquê", liderar o time sem autoridade formal; gestão de stakeholders — alinhar os interesses de negócio, usuários, time; comunicação e influência — a principal ferramenta do PM; senso de UX — entender o usuário e o bom design; horizonte técnico — falar com o desenvolvimento na mesma língua. Inglês — para o mercado internacional. O principal: o PM é valorizado não pelo conhecimento de ferramentas, mas pela capacidade de descobrir o que construir e levá-lo a um resultado mensurável.

Os termos são constantemente confundidos, e não há uma resposta única — muito depende da empresa. Diferença básica: Product Owner (PO) — um papel da metodologia Scrum: a pessoa que gerencia o backlog de uma equipe, formula e prioriza tarefas, aceita o resultado, trabalha em estreita colaboração com a equipe nos sprints. O PO é focado em "o que a equipe faz nos próximos sprints" — na execução. Product Manager (PM) — um papel mais amplo: responsável pelo produto como um todo — estratégia, mercado, usuários, métricas, resultado de negócio; decide não só "o que entra no sprint", mas "qual produto e direção afinal". Na prática: em algumas empresas PM e PO são a mesma pessoa (especialmente nas pequenas); em outras o PM define a estratégia enquanto o PO conduz o backlog e a equipe ao seu lado; em outras ainda "Product Owner" é apenas o nome aceito para um product manager. Na Rússia "Product Owner" é frequentemente usado como sinônimo de PM ou como título para um nível de PM mais próximo da equipe. Conclusão: ao ler uma vaga, olhe as responsabilidades, não o título — se é sobre estratégia, mercado, métricas e resultado, é trabalho de PM; se é só sobre backlog e sprints, é PO no sentido estrito. Fluxo de carreira: PO no sentido estrito — um passo comum para um PM completo.

Três papéis com abreviações parecidas e essência diferente. Product Manager é responsável por o que construir e por quê — pelo produto, seu valor para os usuários, e o resultado de negócio; a pergunta-chave — "estamos fazendo a coisa certa". Project Manager é responsável por como entregar — que o escopo de trabalho definido seja feito no prazo, no orçamento e com a qualidade certa; a pergunta-chave — "estamos fazendo a coisa do jeito certo e no prazo" (veja /research/pm/project-manager). Grosso modo: o product manager decide o que fazer; o project manager garante que seja entregue. Business Analyst é responsável pelos requisitos — levanta e formaliza o que exatamente precisa ser feito dentro de uma direção dada, descreve processos e requisitos para o time (veja /research/analyst/business-analyst). Grosso modo: o PM escolhe a direção e é responsável pelo resultado; o BA elabora os requisitos em detalhe dentro dela; o Project Manager organiza a entrega. Em times pequenos esses papéis são frequentemente combinados em uma pessoa; em grandes — separados. Fluxo de carreira: as pessoas frequentemente chegam a Product Manager a partir de Business Analyst, Project Manager, analytics, desenvolvimento ou marketing.

O trabalho do PM é um ciclo contínuo de "entender → decidir → construir → medir". 1) Discovery (pesquisa de produto) — entender qual problema do usuário vale a pena resolver: entrevistas e custdev, análise de comportamento no produto, estudo de mercado e concorrentes, coleta e análise de feedback, formulação e teste de hipóteses. Objetivo — não construir o que ninguém precisa. 2) Estratégia e visão — para onde o produto está indo, em qual mercado, para quais usuários, qual é a sua diferenciação; no horizonte de trimestres e anos. 3) Roadmap — plano do produto: quais grandes tarefas e em que lógica, atreladas a objetivos (não apenas uma lista de features com datas). 4) Priorização — o mais importante e o mais difícil: decidir o que fazer agora e o que — não, e por quê; os recursos são sempre limitados, e um bom PM se reconhece pelo que ele recusou fazer. 5) Definição de tarefas para o time — transmitir o problema e o objetivo (não ditar a solução), trabalhar com design e desenvolvimento, explicar o "porquê". 6) Lançamento e iterações — implantar a mudança, verificar com um experimento, olhar as métricas, tirar conclusões e repetir. 7) Trabalho com stakeholders — alinhar os interesses de negócio, usuários, time e liderança. Essencial: o PM alcança resultados por meio de influência, dados e argumentos, não por meio de poder — formalmente ele quase não gerencia ninguém.

Um product manager não precisa programar, e uma formação técnica não é obrigatória — mas tudo depende do produto. O que é definitivamente necessário: horizonte técnico — entender em alto nível como o produto é construído, o que são API, bancos de dados, frontend e backend, o que é tecnicamente barato e o que é caro; isso é necessário para falar a mesma língua do desenvolvimento, avaliar prazos e realismo de forma adequada, não ser "enganado" e não exigir o impossível. Quando o background técnico importa: para produtos técnicos — plataformas, APIs, infraestrutura, dev tools — é preciso um Technical PM com profundidade técnica real (veja /research/pm/tech-pm); as pessoas costumam chegar lá vindas do desenvolvimento. Quando não é crítico: para a maioria dos produtos de consumo e de negócio, a compreensão de usuários, mercado, métricas e negócio importa mais que o código. O que de fato importa mais que um diploma técnico: pensamento de produto, capacidade de trabalhar com usuários e dados, comunicação, senso de negócio. SQL — à parte: é uma exigência crescente para quase todos os PMs (capacidade de extrair os dados por conta própria), e vale a pena dominar independentemente do background. Conclusão: PM é um cargo aberto a pessoas sem formação técnica, mas que exige crescimento constante do horizonte técnico; para produtos técnicos a régua técnica é mais alta.

Why entry is hard: pure Junior PM openings are few (per Zorky sample 33 jobs are open, and almost all are Middle+), the profession is popular and competition high, and employers want to see proven product results which a newcomer by definition doesn't have — classic "no work without experience, no experience without work" trap. So people more often move into PM from adjacent roles rather than coming "off the street after courses". Working entry paths: 1) Transition from an adjacent role inside or near the product — analyst (especially product), Business Analyst, developer, designer, QA, marketer, support, Project Manager; you're already in the product team and gradually take on product tasks. 2) Domain expertise — deep knowledge of an industry (finance, logistics, medicine) + product skills = PM for a product in that industry. 3) Associate / Junior PM programmes at large companies — rare, competitive, but real. 4) Your own pet product / launch of something of your own — a proven result, even small. Skills roadmap: product thinking and frameworks (JTBD, discovery), working with metrics and unit economics, SQL, UX basics, custdev and interviews, prioritisation, Agile. Resources: books ("Inspired" Marty Cagan — classic, etc.), product management courses (ProductStar, Yandex, GoPractice — known for its simulator, Simulator from GoPractice), product communities. Main advice: not "learn to PM from scratch", but get into a product team in any role and grow into PM from inside, accumulating proven results.

33 active open Product Manager positions in the Zorky sample. Important about this number: the vast majority are Middle and Senior; pure Junior positions are few (entry to the profession goes mainly by transition from adjacent roles). The real market is wider than exact-term search — the role is named "product manager", "product owner", "PM", "product owner". Geography: the US, Poland, Singapore. Sources: hh.ru, Habr Career, getmatch, LinkedIn, Telegram (product communities and job channels). Product Manager — in-demand and popular profession with sustained demand for experienced specialists and high competition for entry positions. NB: in the Zorky taxonomy there's also a separate "product" direction — some product roles may be counted there.

Um Product Manager Sênior responde por um grande produto ou direção importante e pelo seu resultado. Pensamento estratégico: ver o produto no horizonte de trimestres e anos, entender mercado, concorrentes e tendências, formular estratégia e visão, não apenas gerir um backlog. Domínio de discovery: entender profundamente os usuários, testar hipóteses de forma rápida e barata, distinguir o problema real do ruído dos "desejos", não deixar que coisas desnecessárias sejam construídas. Trabalho com métricas: definir as métricas de produto certas (não as facilmente manipuláveis), calcular unit economics, construir uma árvore de métricas, trabalhar corretamente com testes A/B, tomar decisões com base em dados. Priorização e foco: ser rigoroso ao decidir o que NÃO fazer; proteger o foco do time do fluxo de pedidos; encontrar as alavancas de maior impacto. Influência sem autoridade: liderar time, design, desenvolvimento e stakeholders por argumentos, dados e confiança; alinhar interesses conflitantes do negócio e dos usuários; vender ideias à liderança. Pensamento de negócio: entender a economia do produto e da empresa, ligar as decisões de produto ao dinheiro. Horizonte técnico: avaliar viabilidade e custo, falar de igual para igual com os engenheiros. Senso de UX: entender o usuário e a qualidade do design. Liderança: definir a cultura e o nível de exigência do time; para o Lead — desenvolver PMs Júnior. Comunicação: oral e escrita — a principal ferramenta. Inglês — para o mercado internacional. O principal valor de um Sênior — não "gerir o produto", mas encontrar o que trará o maior resultado e levá-lo a um impacto mensurável, sendo dono do resultado.