Fuera del sector de tecnología, e incluso dentro del mismo, se hace difícil de explicar qué es ser product manager. Yo aún habiéndoselo explicado durante años a amigos, familiares y conocidos siguen diciéndome si eso raro que tu haces o sigo sin entender a qué te dedicas.
Y la verdad es que es normal que suceda esto por dos razones principales:
- En cada empresa ser product manager es diferente, las tareas, los procesos, la cultura de producto o incluso los equipos cambian. No es lo mismo ser un product manager en una IBEX35 sin cultura de producto que en una start-up con 28M de financiación.
- Porque hoy en el mundo de la IA ni los propios product managers sabemos hacia dónde se dirige la profesión. Esto pasa porque hay dos corrientes, unos dicen que se va hacia el rol de product builder mientras que otros consideran que el rol es cada vez más fundamental y evolucionará con herramientas pero estar cerca del usuario y dedicar tiempo a lo realmente importante de la profesión será vital. El debate está servido, pero eso para otra entrada.
Pero no nos vayamos por derroteros. Si estás aquí es, seguramente, porque quieres aprender sobre producto digital. Si es así has de saber que estás en un buen lugar y por otro lado quisiera agradecerte que de todo internet elijas esta web.
Con mis artículos intentaré desgranar y aportar todo lo que he aprendido desde 2009 en el mundo digital, start-ups y desde 2017 en diferentes roles de producto desde lo básico, pasando por lo avanzado y con ejemplos y experiencias personales siempre que pueda.
Volvamos a la pregunta inicial
¿Qué es ser product manager?
Un product manager es tener conocimientos de tres áreas diferentes, negocio, diseño y desarrollo porque vas a interaccionar con estas partes del negocio y has de desenvolverse bien en las tres para tomar decisiones correctas tanto para tu empresa como para tus equipos y tus usuarios. Cada vez se tiene más en cuenta el tema de la inteligencia artificial y de cómo llegar al mercado pero esto daría para otro artículo propiamente dicho. Podría a continuación hablar sobre todo lo que es ser y no ser product manager, las diferencias con un product owner o un project manager pero no.
Voy a contaros mi experiencia en algunos de los roles de producto que he tenido durante mi carrera porque creo que eso explicará mejor qué es ser product manager, cómo es el día a día y podrás hacerte una idea de qué se necesita para el rol.
La etapa del Santander – Innovation Product Manager
En el banco Santander tuve la oportunidad de estar en el departamento de Santander Digital (ya no existe) liderado por personas que venían de la empresa Intuir, empresa americana y por ende perfiles americanos. Estuve en la división de innovación y en aquella época, ahora lo desconozco, no se contaba internamente con equipos de desarrollo para las iniciativas sino que se externalizar todo a consultoras (incluso yo y miembros de mi equipo éramos consultores externos).
Como Innovation Product Manager actuaba como soporte a iniciativas de diferente índole y diferentes geografías, generalmente en España, aunque otros compañeros apoyaban en México o Brasil. ¿Qué significaba dar soporte? Pues desde lo siguiente:
- Apoyar a los equipos de negocio en la investigación y análisis de oportunidades, en ocasiones incluso tu mismo detectando oportunidades de negocio y planteándoselas a tus jefes.
- Monitorizar tendencias y hacer análisis de noticias sectoriales para saber qué oportunidades pueden venir y que tendría sentido construir.
- Pensar en posibles modelos de negocio y modelos de pricing de iniciativas.
- Hacer presentaciones de iniciativas y apoyar en las mismas para conseguir financiación interna.
- Apoyar a los equipos de diseño internos o externos en la fase de discovery, a esta fase la llamamos entender el problema mediante entrevistas de usuario cuantitativas y cualitativas generalmente. Es decir participaba activamente en el diseño de test y en las entrevistas de usuario.
- Conceptualizar y diseñar flujos y customer journeys con los equipos.
- Lanzar y diseñar anuncios para ver si una iniciativa tenía sentido o podría haber un negocio viable (a esto se le llama Fake Tests).
- Gestionar equipos de desarrollo para la implementación de las iniciativas.
- Analizar métricas de cómo los usuarios estaban utilizando aplicaciones o funcionalidades dentro de la app del Santander o de otros proyectos.
- Y reuniones, muchas reuniones de coordinación.
Como se puede ver no había un día típico, al ser un soporte iba cambiando de proyectos y de equipos. A veces estaba más cerca de diseño, otras más de la implementación junto a tecnología y en otras más cerca de negocio. Se lanzaban muchas iniciativas en el departamento y eso me permitió mejorar muchas habilidades de la profesión.
La etapa de Bravado- Growth Product Manager
Bravado era, y digo era porque cerró sus operaciones a principios de 2026, una start-up americana que combinaba una red social anónima para profesionales de ventas con una plataforma de recruiting especializada en el sector de ventas.
Es decir si querías contratar a un profesional de ventas ibas a Bravado y nosotros te dábamos información que ni siquiera se encontraba en LinkedIn (de esto haré un caso para que se entienda mejor el negocio).
Entré como Growth Product Manager cuando a la red social, una especie de reddit de ventas, era sólo una lista de espera a la que íbamos dando acceso a los usuarios paulatinamente. ¿Mi misión? Conseguir traer el mayor al mayor número de usuarios posibles a la plataforma de la forma que sea, junto con marketing claro, y que el onboarding fuese lo más fluido posible para maximizar la conversión.
¿Cuál eran mis tareas y cómo era el día a día?
- En primer lugar trabajaba en horario americano, empezaba a las 13.00-14.00 y acababa a las 21.30 o 22.30 todos los días de lunes a viernes. Miraba el email, miraba las métricas, conversaciones de Slack, 1&1 con mi manager una vez a la semana, reuniones con los fundadores y directivos bimensualmente. Trabajar codo con codo con el product designer constantemente en las iniciativas.
- Mi equipo era internacional y tenía en mi squad un Engineering Manager, QA Engineer, Product Designer y aunque se empezó con un equipo de 4 desarrolladores se llegó a ampliar a 8. Teníamos la stand-up a las 15.00 con europeos y brasileños (no había desarrolladores americanos, en mi squad al menos). No había data analyst ya que había un departamento de data y hablábamos con ellos para lo necesario.
- Implementar y diseñar A/B test para comprobar que las mejoras funcionasen realmente junto con el equipo de data.
- Tocaba constantemente proponer ideas de mejora para conseguir los objetivos trimestrales de la empresa en mi área y conseguir crecer para que el negocio fuera un éxito. Esto puede ser desde optimizaciones del onboarding tras un análisis del mismo con herramientas como Amplitude, que era la que usábamos, o pensar en formas de hacer marketing que nadie había pensado con el objetivo de disminuir costes.
- Implementar las mejoras, es decir crear Briefs de Producto en las que se especificasen las nuevas funcionalidades y quedase claro para el equipo de desarrollo, el product designer y el documento actuase como verdad universal, aunque se actualizaba, a lo largo de la fase de desarrollo.
- Ayudar al Engineering Manager a priorizar tareas en las sesiones de priorización.
- Hacer retrospectivas con el equipo trimestrales o mensuales para ver formas en las que podíamos mejorar.
- Integrar datos de otras empresas con el equipo tras la compra de un proyecto externo.
- Hacer reportes sobre el éxito o fracaso de iniciativas en las que había estado involucrado.
- Coordinarme con marketing para el lanzamiento de nuevas iniciativas y la comunicación interna.
- Gestionar a un Product Manager Junior y estar involucrado en la conceptualización de nuevas líneas de negocio.
La etapa de Radix – Lead Product Manager
Radix es una layer 1 de crypto monedas, puedes pensar algo así como Ethereum, que resuelve varios problemas del mundo crypto y la adopción de DeFi: seguridad, por el diseño particular de su sistema de activos, escalabilidad, son capaces de hacer medio millón de transacciones complejas por segundo y experiencia de usuario, poseen una interfaz y una wallet únicamente móvil.
Ahí tuve la oportunidad de tener como jefe a Matt Hine cuyo pensamiento de producto me ayudó mucho a crecer como profesional. Matt siempre explicaba las cosas con el camino del usuario tanto en presentaciones de lanzamiento como a todos los miembros del equipo. Él quería que entendiésemos, incluso si no existía cómo iba a ser el flujo del usuario hasta realizar una acción y qué iba a hacer exactamente. Y lo más importante, por qué eso y no otra cosa.
Entré con conocimientos de finanzas pero poco de cripto en aquel momento, y entré cuando todavía se estaba construyendo la red 2022, había que crear muchos servicios y crear un proyecto prácticamente de cero.
Tenía un equipo pequeño pero senior, contaba con un product designer (el único junior), y varios desarrolladores, frontend y full-stack principalmente. He de decir que el equipo de Radix, en general es uno de los mejores con los que he trabajado técnicamente, y que el líder de diseño Aftab es un portento tanto a nivel de diseño y como persona.
Aquí trabajé en varios proyectos principales:
- El dashboard / explorer de Radix, la plataforma donde ver todo lo que sucedía en la red y poder hacer staking en los nodos
- El developer console, donde se podían subir “contratos inteligentes” a la red y crear tokens.
- La extensión de Radix para Chrome
- El sistema de descarga de la aplicación desde la web
- RadQuest, una plataforma de onboarding para nuevos usuarios
¿Cómo era el día a día?
No era un día a día normal. Como os podéis imaginar muchas de las tareas que realizaba ya se han mencionado anteriormente pero igualmente haré un resumen. Pero la parte diferencial era el constante aprendizaje de las nuevas capacidades que estábamos creando así como conocer todo el aspecto técnico de la red y estar al tanto de lo que ocurría en el sector.
Hubo diferentes fases, antes de lanzar los productos el día a día era más de trabajar codo con codo con el diseñador, incluso en muchas ocasiones diseñando yo mismo pantallas de Figma porque no se llegaba al deadline, haciendo mucha investigación y análisis de webs de la competencia para entender cómo se estaba mostrando la información.
Muchas entrevistas de usuario, muchos test con diseños de flujos para ver cuáles eran los mejores, discusiones y reuniones internas entre diseñadores, desarrolladores y producto para ver cuál era el mejor camino y qué podíamos hacer técnicamente para reducir fricción o qué tecnologías o sistemas podíamos usar, fueran convencionales o no.
Gestión de tiempos y expectativas, decir que no se llegaba en alguna ocasión y llegar de la mejor forma posible sacrificando algunas funcionalidades.
Hacer mucho QA y testing en stokenet (una red de pruebas), con la wallet, el producto y todo para ver que no había ningún fallo y todas las transacciones funcionasen correctamente (aquí no había QA engineer…).
Una vez que se lanzaron los productos, mejorar con nuevas funcionalidades y analizar las mínimas métricas de uso interno que se tenían.
Gestionar e involucrarse en la conceptualización de la plataforma de onboarding de RadQuest realizado por una agencia externa. Hacer seguimiento y hacer más de Project Manager y explicarles todos los conceptos importantes sobre cómo funcionaba la red.
Y claro obviamente gestionar al equipo y dar soporte y ayuda a otros Product Managers menos seniors.
Radix fue una etapa muy intensa, aprendí mucho, hice grandes amistades que aún me llevo y en la que aporté todo lo que pude. Cuando escribo esto el proyecto se está convirtiendo en una DAO y está en manos de la comunidad convertirlo y aprovechar todo su potencial.
La etapa de Obi – Head of Product
Obi es una empresa que es una pasada, con cientos de miles de descargas (por NDA no puedo mencionar cuántas en total como se comprenderá) y que resuelve un problema importantísimo en el mundo del ridehailing y del transporte para el usuario: ¿qué aplicación de ridehailing me es más barata para ir a dónde quiero ir?
Imagina que estás en Atocha y quieres ir a tu casa por la noche. Estás pensando en qué aplicación abrir, Uber, Cabify, Bolt o Freenow (si la tienes). Por lo general tendrías que abrir una a una y comprobar los precios.
Pues Obi es un agregador que hace justamente eso, tu conectas tus cuentas con la aplicación y buscas una sola vez. De esta forma ahorras tiempo y, probablemente lo más importante, dinero ya que ves cuánto te va a costar el viaje en cada app y así puedes escoger en cuál realizar el viaje.
¿Lo mejor? Funciona en casi todo el mundo.
Entré en Obi en junio de 2025 como Head of Product para dirigir los diferentes productos que tenían (por confidencialidad no puedo mencionarlos) y lanzar alguno nuevo.
El rol era de Head of Product pero como mi CEO me dijo en una ocasión, Edu sé que en start-ups más grandes tu rol a veces lo hacen dos o tres personas. Esto qué quiere decir, que en start-ups pequeñas si el equipo es pequeño te va a tocar hacer de todo, mucho más de lo que podrías estar acostumbrado en otras posiciones (por eso decía que los roles dependen de cada empresa).
Pero este puesto me gustaba mucho, el sector me encantaba, había estado anteriormente fugazmente en Uber como Operations Manager antes de descubrir que prefería producto a operaciones en las start-ups, estuve a punto de lanzar una aplicación de taxi en 2011 en Madrid con un amigo con La Gremial del Taxi y me apasionan los coches autónomos y sabía muchísimo del sector.
En Obi el equipo era pequeño pero sabían muy bien lo que hacían y llevaban años con la aplicación viendo a cientos de aplicaciones del sector desaparecer a nivel mundial tuve la oportunidad de dirigir un equipo de 14 desarrolladores, contando con QAs y CTOs, definir el roadmap, mejorar métricas de negocio mediante la optimización del onboarding.
También hice todo el análisis y conceptualización de un nuevo producto para lanzar en países en vías de desarrollo (igual por confidencialidad no puedo hablar mucho), y este producto se diseñó, validó y lanzó en tan solo dos meses. Es decir diseñamos y validamos con usuarios la interfaz y el problema en un mes y se lanzó a producción dos aplicaciones móviles, en iOS y Android, en el mes siguiente. Obviamente usando IA en el desarrollo y algo de IA en el diseño.
El trabajo como os podéis imaginar es similar ya habiendo descrito varios, coordinarse con el equipo, con stakeholders, con marketing, hablar con usuarios, en este caso leer mucho las reseñas de usuarios de las apps store, ser parte del soporte de los usuarios si hacía falta para entender sus necesidades y quejas. Usar la aplicación y reportar bugs inusuales con apps poco usadas en tu país, pensar con marketing y proponer nuevas iniciativas de crecimiento, validar ideas e hipótesis, analizar métricas en Mixpanel, crear paneles y nuevos sistemas como Posthog para grabar las pantallas de los usuarios, alinear roadmap con tecnología y prioridades de negocia, ver qué es factible y qué no, priorizar un equipo pequeño para dar soporte a los diferentes productos y que todo vaya como la seda, etc…
Como puedes ver el rol del product manager depende de la organización, de la fase en la que estés y de la parte de producto en la que te encuentres. No es lo mismo estar en el onboarding de una parte de un marketplace como Bravado a estar en una aplicación móvil como Obi siendo responsable de su totalidad o estando en la fase de conceptualización de productos como en Santander o Radix.
Se suele decir que los Product Managers son los “CEOs” del producto, desde mi experiencia esto es falso. Un Product Manager tiene generalmente, a menos que seas Lead o Head of Product, poca decisión sobre negocio para poner los objetivos. Y depende de la organización, tampoco puede decidir al 100% qué hacer sin contar con los stakeholders. No es un CEO.
Un Product Manager tiene que velar por los usuarios y por lo que es mejor para ellos. Siempre obviamente teniendo en cuenta las necesidades de negocio.
Si has leído hasta aquí espero que te quede un poco más claro las tareas diarias de un product manager y quizás qué es el rol.
Artículo escrito en su totalidad sin Inteligencia Artificial.