Currículum de product manager (responsable de producto): ejemplos y guía para redactarlo

Persona inventada, alcance realista. Lee el primer logro de cada puesto: dice de qué se encargaba y qué tamaño tenía, antes de cualquier resultado. Eso es lo que necesita quien contrata para valorar el resto.

Los puestos de product manager reciben cientos de candidaturas, muchas de jefes de proyecto, consultores e ingenieros que quieren cambiar de rol. El filtro es implacable y busca unas pocas señales concretas.

• El alcance del que te encargabas. Ingresos, usuarios, cuentas, ingenieros, squads. Sin esto, ninguna métrica se puede interpretar.
• El tipo de producto. SaaS B2B, app de consumo, marketplace, plataforma o API, herramientas internas, hardware. Quien contrata se fija mucho en las coincidencias.
• Pruebas de discovery. Con cuántos clientes hablas de verdad y una decisión que cambió por ello. La mayoría de currículums no tienen nada de esto.
• Decisiones, incluido lo que cancelaste. Decir que no es el trabajo. Un logro sobre algo que dejaste de lanzar es poco habitual y llama la atención.
• Cifras que puedas defender. Activación, retención, adopción, tiempo de ciclo, ingresos de tu área. La honestidad en la atribución importa, porque te preguntarán qué más estaba pasando en ese momento.

“Lo que delata a un buen candidato es el discovery. Casi todo el mundo escribe que definió el roadmap y trabajó con equipos multifuncionales. Muy pocos escriben que hicieron veintidós entrevistas de baja y luego quitaron dos elementos del roadmap por lo que oyeron. Con esa segunda persona quiero hablar.”

Tres o cuatro líneas: años, dominio de producto, alcance en ingresos o usuarios, uno o dos resultados y una pista de cómo trabajas. Reescríbelo según el tipo de empresa: un equipo de crecimiento de consumo y un equipo de plataforma enterprise quieren oír cosas distintas.

El fallo es el mismo en casi todos los currículums de producto: logros que describen el ritual del puesto (roadmaps, dailies, stakeholders) en lugar de las decisiones y sus efectos.

Sobre la atribución. No moviste una métrica tú sin ayuda de nadie, y un buen entrevistador lo va a sondear. La solución no es rebajar lo que afirmas, sino nombrar tu parte: qué decidiste, en qué pruebas te basaste y quién lo construyó. «Reduje la baja del 2,1 % al 1,4 % después de que 22 entrevistas detectaran carencias en los permisos; definí y prioricé la reconstrucción de permisos con dos ingenieros» es a la vez más grande y más creíble que un porcentaje a secas.

Olvídate de enumerar frameworks. Una lista con Agile, Scrum, Kanban, Lean, Design Thinking y SAFe no dice nada. Agrupa tus competencias en discovery, entrega y negocio, y deja las herramientas en una sola línea.

Discovery y pruebas:

• Entrevistas con clientes, entrevistas de win/loss y de baja
• Pruebas de prototipos y de concepto con usuarios reales
• Dimensionamiento y priorización de oportunidades (RICE o tu propio modelo, explicado con claridad)
• Analítica de producto y análisis de embudos: Amplitude, Mixpanel, GA4, Looker
• SQL, al nivel que sea honesto en tu caso
• Diseño de tests A/B y de grupos de control, e interpretación de resultados sin engañarte

Entrega y oficio:

• Redacción de especificaciones, historias de usuario y criterios de aceptación con los que los ingenieros puedan trabajar
• Gestión y refinamiento del backlog con equipos Scrum o Kanban
• Planificación de releases, estrategia de despliegue y feature flags
• Trabajo con diseño en flujos y prototipos
• Soltura técnica: APIs, modelos de datos, integraciones, lo suficiente para debatir los compromisos
• Jira o Linear, Productboard o Aha!, Figma, Miro, Confluence o Notion

Las competencias de negocio son las que más pesan en puestos sénior y las que más a menudo faltan: aportaciones a precios y empaquetado, redacción de business cases, lanzamiento al mercado con ventas y marketing, análisis de la competencia y explicar a la dirección qué no vas a hacer y por qué. Di cuáles de estas has hecho de verdad.

En muchas empresas son la misma persona; en otras son trabajos realmente distintos, y el volumen de búsquedas muestra que mucha gente se presenta a los dos. Si aciertas con la redacción, un mismo currículum sirve para ambos cambiando el titular.

Si eres product owner y apuntas a puestos de product manager, mantén tu cargo real y pon el trabajo de resultados por encima del de entrega en tus logros. Si eres product manager y te presentas a puestos de product owner, haz lo contrario y pon primero el backlog, el ritmo y las métricas del equipo.

Certificaciones útiles aquí: Professional Scrum Product Owner de Scrum.org, Certified Scrum Product Owner de Scrum Alliance y SAFe Product Owner/Product Manager si te presentas a una organización con agile a escala. Abren puertas para puestos de product owner y son bastante neutras para puestos sénior de product manager, donde deciden el alcance y los resultados.

Esta es la versión más buscada de esta pregunta, y con razón: a la gestión de producto casi todo el mundo llega desde otro puesto. El currículum tiene que demostrar que ya has hecho partes del trabajo con otro cargo.

• Desde ingeniería: funcionalidades que definiste y no solo construiste, compromisos que defendiste, llamadas con clientes en las que participaste.
• Desde el análisis de negocio o de datos: toma de requisitos, entrevistas con stakeholders, cuadros de mando que cambiaron una decisión, consultas SQL que encontraron algo en lo que nadie había reparado.
• Desde customer success o soporte: patrones de bajas y quejas que documentaste, peticiones de funcionalidades que convertiste en un caso priorizado.
• Desde diseño: investigación de discovery, pruebas de prototipos, influencia en el roadmap, lanzamientos junto a ingeniería.
• Desde consultoría u operaciones: rediseños de procesos con resultados medidos, business cases, presentaciones a la dirección.

1. 1Elige los dos proyectos en los que decidiste algo, no solo entregaste algo, y reescríbelos como logros de producto: problema, pruebas, decisión, resultado.
2. 2Añade contacto real con clientes. Veinte entrevistas que hiciste tú, en cualquier puesto, son una experiencia de discovery creíble.
3. 3Aprende suficiente SQL y analítica de producto para responder a tus propias preguntas, y dilo con un ejemplo.
4. 4Lanza algo pequeño de principio a fin, aunque sea interno. Una herramienta interna con 40 usuarios y un ahorro de tiempo medido es una historia de producto legítima.
5. 5Saca el PSPO I o el CSPO si apuntas a puestos de product owner o a empresas con agile a escala. No te convertirá en product manager, pero te quita un filtro.

• Una página hasta unos 8 años de experiencia, dos páginas para puestos sénior, de group o de dirección con alcance de equipo y de cartera.
• PDF a una columna, texto real, sin gráficos ni barras de nivel. Las grandes tecnológicas analizan los currículums con un ATS antes de que los vea una persona.
• En España la foto es habitual pero opcional, y en tecnología muchas candidaturas van sin ella. No incluyas fecha de nacimiento ni DNI. Si te presentas a una empresa de EE. UU. o Reino Unido, quita la foto; los consejos de contenido de esta guía son los mismos.
• Empieza cada puesto con una línea de alcance y después los logros. Los responsables de selección leen el primer logro de cada puesto y pasan por encima del resto.
• Deja una línea breve de enlaces: LinkedIn, y una web personal solo si tiene algo que merezca la pena leer.

Palabras que conviene reflejar de la oferta: estrategia de producto, roadmap, discovery, investigación con clientes, priorización, backlog, historias de usuario, criterios de aceptación, equipos multifuncionales, go-to-market, experimentación, tests A/B, analítica de producto, SQL, activación, retención, churn, adopción, OKR, gestión de stakeholders, agile, Scrum.

Último repaso antes de enviarlo: comprueba que cada métrica indica su base (usuarios, cuentas, ingresos, sesiones), que tus años de experiencia cuadran con las fechas y que al menos tres logros describen una decisión y no una actividad. Si ninguno lo hace, el currículum parece el de un jefe de proyecto, que es el motivo más común por el que candidaturas sólidas quedan fuera de los puestos de producto.