Product Manager: mercado

Vacante

un empleo abierto que superó el filtro de calidad y menciona al menos dos tecnologías

Candidato observado

un candidato cuyo stack contiene esta tecnología; es un agregado: ni un solo registro sale del perímetro

Candidato emparejable

aún no contabilizado

Ventana

empleos abiertos en el momento en que se generó el snapshot

Un Junior / Associate PM lleva una parte pequeña del producto o funcionalidades concretas con mentoría. Salto a Middle: responsabilidad independiente sobre un área: discovery, priorización, métricas, lanzamientos. Un Senior responde de un producto grande o un área importante e influye en la estrategia. Group / Lead PM gestiona varios productos o un equipo de PM. Trayectoria: (a menudo desde analítica, desarrollo, BA, marketing, soporte) → Associate / Junior PM → Middle → Senior → Group / Lead PM → Head of Product → CPO. Hay pocas vacantes Junior puras: la entrada a la profesión es competitiva (ver la pregunta aparte).

Herramientas principales: go, agile, visio, git, product owner. Herramientas: Jira + Confluence (backlog, documentación), Figma (diseño y prototipos), analítica (Amplitude, Mixpanel, Yandex Metrika, GA4), SQL (requisito en crecimiento, obtener los datos tú mismo), Miro, herramientas de roadmapping, herramientas de IA para research y análisis de feedback. Skills clave: pensamiento de producto, ver tras las features el problema y el valor para el usuario; discovery, custdev, entrevistas, prueba de hipótesis, análisis de mercado y competidores; trabajo con métricas, definir, calcular y mover las métricas de producto correctas, unit economics, árbol de métricas; priorización, decidir qué hacer y qué no, y argumentarlo; estrategia y roadmap, visión de producto y el camino hacia ella; A/B tests, verificar los cambios con experimentos; trabajo con el equipo, asignar tareas, explicar el «por qué», liderar al equipo sin autoridad formal; gestión de stakeholders, alinear los intereses del negocio, los usuarios y el equipo; comunicación e influencia, la herramienta principal del PM; sentido de UX, entender al usuario y el buen diseño; horizonte técnico, hablar con desarrollo en el mismo idioma. Inglés, para el mercado internacional. Lo principal: al PM no se le valora por conocer herramientas, sino por la capacidad de encontrar qué construir y llevarlo a un resultado medible.

Los términos se confunden constantemente, y no hay una respuesta única: mucho depende de la empresa. Diferencia básica: Product Owner (PO): un rol de la metodología Scrum: una persona que gestiona el backlog de un equipo, formula y prioriza las tareas, acepta el resultado, trabaja de cerca con el equipo en los sprints. El PO se centra en «qué hace el equipo en los próximos sprints», en la ejecución. Product Manager (PM): un rol más amplio: responsable del producto en su conjunto: estrategia, mercado, usuarios, métricas, resultado de negocio; decide no solo «qué va en el sprint», sino «qué producto y qué dirección en general». En la práctica: en algunas empresas PM y PO son la misma persona (sobre todo en las pequeñas); en otras el PM fija la estrategia mientras el PO lleva el backlog y el equipo a su lado; en otras «Product Owner» es solo el nombre aceptado para un product manager. En Rusia «Product Owner» se usa a menudo como sinónimo de PM o como título para un nivel de PM más cercano al equipo. Conclusión: al leer una oferta, mira las responsabilidades, no el título: si va de estrategia, mercado, métricas y resultado, es trabajo de PM; si va solo de backlog y sprints, es PO en sentido estrecho. Trayectoria: PO en sentido estrecho, un paso habitual hacia un PM completo.

Tres roles con abreviaturas parecidas y esencia distinta. El Product Manager es responsable de qué construir y por qué: del producto, su valor para los usuarios y el resultado de negocio; la pregunta clave es «¿estamos haciendo lo correcto?». El Project Manager es responsable de cómo entregar: de que el alcance de trabajo definido se haga a tiempo, dentro del presupuesto y con la calidad adecuada; la pregunta clave es «¿lo estamos haciendo bien y a tiempo?» (ver /research/pm/project-manager). A grandes rasgos: el product manager decide qué hacer; el project manager se asegura de que se entregue. El Business Analyst es responsable de los requisitos: extrae y formaliza qué exactamente hay que hacer dentro de una dirección dada, describe procesos y requisitos para el equipo (ver /research/analyst/business-analyst). A grandes rasgos: el PM elige la dirección y responde por el resultado; el BA detalla los requisitos dentro de ella; el Project Manager organiza la entrega. En equipos pequeños estos roles suelen combinarse en una persona; en los grandes, se separan. Flujo de carrera: la gente suele llegar a Product Manager desde Business Analyst, Project Manager, analítica, desarrollo o marketing.

El trabajo de PM es un ciclo continuo de «entender → decidir → construir → medir». 1) Discovery (investigación de producto): entender qué problema del usuario merece resolverse: entrevistas y custdev, análisis del comportamiento en el producto, estudio del mercado y la competencia, recogida y análisis de feedback, formulación y validación de hipótesis. Objetivo: no construir lo que nadie necesita. 2) Estrategia y visión: hacia dónde va el producto, en qué mercado, para qué usuarios, cuál es su diferenciación; en un horizonte de trimestres y años. 3) Hoja de ruta: el plan del producto: qué grandes tareas y con qué lógica, ligadas a objetivos (no solo una lista de funcionalidades con fechas). 4) Priorización: lo más importante y lo más difícil: decidir qué hacer ahora y qué no, y por qué; los recursos siempre son limitados, y a un buen PM se le reconoce por lo que se negó a hacer. 5) Planteamiento de tareas al equipo: transmitir el problema y el objetivo (no dictar la solución), trabajar con diseño y desarrollo, explicar el «por qué». 6) Lanzamiento e iteraciones: desplegar el cambio, verificarlo con un experimento, mirar las métricas, sacar conclusiones y repetir. 7) Trabajo con stakeholders: alinear los intereses del negocio, los usuarios, el equipo y la dirección. Clave: un PM logra resultados mediante la influencia, los datos y los argumentos, no mediante el poder: formalmente casi no dirige a nadie.

Un product manager no necesita programar, y la formación técnica no es obligatoria, pero todo depende del producto. Lo que sí hace falta: horizonte técnico: entender a alto nivel cómo está construido el producto, qué son una API, las bases de datos, el frontend y el backend, qué es técnicamente barato y qué es caro; hace falta para hablar con desarrollo en el mismo idioma, evaluar con criterio los plazos y el realismo, no dejarse «engañar» y no exigir lo imposible. Cuándo importa la formación técnica: en productos técnicos (plataformas, APIs, infraestructura, herramientas para desarrolladores) hace falta un Technical PM con profundidad técnica real (ver /research/pm/tech-pm); a menudo se llega ahí desde desarrollo. Cuándo no es crítica: en la mayoría de los productos de consumo y de negocio, entender a los usuarios, el mercado, las métricas y el negocio importa más que el código. Lo que de verdad importa más que un título técnico: pensamiento de producto, capacidad de trabajar con usuarios y datos, comunicación, sentido de negocio. SQL, aparte: es un requisito cada vez más frecuente para casi todos los PMs (capacidad de obtener los datos por tu cuenta), y vale la pena dominarlo sea cual sea tu formación. En resumen: PM es un rol abierto a personas sin formación técnica, pero exige ampliar constantemente el horizonte técnico; en productos técnicos el listón técnico es más alto.

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.

Un Senior Product Manager es responsable de un producto grande o de una línea importante y de su resultado. Pensamiento estratégico: ver el producto con un horizonte de trimestres y años, entender el mercado, la competencia y las tendencias, formular la estrategia y la visión, no solo gestionar un backlog. Dominio del discovery: entender a fondo a los usuarios, validar hipótesis de forma rápida y barata, distinguir el problema real de los «deseos» ruidosos, no dejar que se construya lo innecesario. Trabajo con métricas: definir las métricas de producto correctas (no las fáciles de mover), calcular la economía unitaria, construir un árbol de métricas, trabajar correctamente con pruebas A/B, decidir con datos. Priorización y foco: firmeza para decidir qué NO hacer; proteger el foco del equipo frente al flujo de peticiones; encontrar las palancas de mayor impacto. Influencia sin poder: dirigir al equipo, diseño, desarrollo y stakeholders con argumentos, datos y confianza; alinear los intereses enfrentados del negocio y de los usuarios; vender ideas a la dirección. Pensamiento de negocio: entender la economía del producto y de la empresa, vincular las decisiones de producto con el dinero. Horizonte técnico: evaluar la viabilidad y el coste, hablar con los ingenieros de igual a igual. Sensibilidad UX: entender al usuario y la calidad del diseño. Liderazgo: marcar la cultura y el listón del equipo; para un Lead, desarrollar a PMs Junior. Comunicación: oral y escrita: la herramienta principal. Inglés: para el mercado internacional. El principal valor de un Senior: no «gestionar el producto», sino encontrar lo que dará el mayor resultado y llevarlo a un impacto medible, haciéndose responsable del resultado.