Author: Eduardo Martín

  • Growth Product Manager en Bravado

    ¿Qué es Bravado?

    Bravado fue, y digo fue porque dejó de existir en 2026, una startup centrada en el recruiting de comerciales con un componente social. Puedes imaginarlo como un Tinder entre empresas y comerciales y un canal de reddit de ventas en el que las personas comentaban sus experiencias de forma anónima.

    Fue mi primera start-up internacional y de fundadores americanos en la que tuve oportunidad de trabajar y la experiencia me encantó.

    Cuando entré la compañía había levantado una ronda de inversión el año pasado, estaba todavía creando el producto, la red social y no tenía modelo de negocio (aunque sí la idea de él). Es decir estaba en un momento pre-product market fit en donde además estaba todo por hacer porque se estaba rehaciendo el foro.

    La hipótesis de Bravado era, uno venía de ser comercial con mucho éxito y otro tenía era data analyst, que seríamos capaces de crear junto con un curriculum enriquecido con diferentes datos un algoritmo que dijese quiénes eran los mejores comerciales o el top 1% de comerciales. Y quería resolver el problema de recursos humanos con perfiles de ventas que finalmente no venden, o venden menos de lo esperado. Ya sea porque están acostumbrados a otro sector, porque la empresa tiene una cultura diferente o por la razón que sea.

    El equipo de producto inicial

    El equipo de producto estaba formado por 4 personas contando conmigo pero las otras dos personas no tenían bagaje de producto, estaban ya en la empresa cuando mi CPO llegó  e iban aprendiendo con lo que hacían, les enseñábamos y guíabamos entre los dos y muchas horas que le dedicaban. Lo que más les costaba realmente era a veces entender de ingeniería, como suele pasar a product managers menos técnicos cuando están empezando.

    Tuve que pasar un largo proceso antes de entrar, no es fácil conseguir trabajos en remoto con empresas americanas, primero una prueba técnica en tiempo real con mi futura jefa. Los pasos fueron prueba técnica, entrevista con el CTO, entrevista con el Head of Design, entrevista con el fundador y una última entrevista de cultura con miembros de mi equipo, operaciones, tecnología y marketing.

    La prueba técnica fue, y ha sido sin duda, la mejor prueba técnica que me han hecho en la vida porque la CPO se puso una hora de su tiempo a preguntarme el caso práctico y hacerme las preguntas que consideraba relevantes e importantes. Y esto lo valoré muchísimo. Jamás he vuelto a tener una prueba técnica como esta y creo que dice mucho más que una entrevista y puedes entender la manera de pensar y resolver problemas de candidatos más allá de pruebas técnicas que se mandan y escriben. Aunque siempre depende de lo que quieras claro está…

    Ya escribiré otros artículos sobre entrevistas y pruebas técnicas pero el caso es que me contrataron y empecé a trabajar como Growth Product Manager.

    Mis primeras responsabilidades como Product Manager

    El rol era claro, liderar el equipo y la squad para conseguir el máximo número de usuarios posibles completasen el onboarding en la plataforma, coordinarme con marketing y realizar acciones de product led growth.

    Cuando entré el foro social estaba creado, se había creado desde cero y tenía varias funcionalidades interesantes que gamificaban la experiencia como puntos por comentar, votar los temas más interesantes, un ranking de los usuarios más activos y cosas similares. 

    Había una waiting list en la que los usuarios tenían que apuntarse y si lo compartían con otras personas que a su vez se apuntasen avanzaban en la waiting list. 

    Se iba dando acceso al foro paulatinamente y se detectó que el foro era un elemento clave en la fase de engagement y retención en la plataforma por lo que rápidamente se pensó en crear una aplicación móvil para que los usuarios pudiesen interactuar en el foro desde cualquier sitio.

    En ese momento mi jefa venía de haber trabajado en el antiguo angel.co, ahora renombrado en wellfound.com, por lo que sabía cómo funcionaba el mundo del recruiting y traía ese bagaje y experiencia. Estaba convencida que el enfoque tenía que ser recruiting y que podíamos hacer algo grande en el sector.

    Mi equipo empezó a trabajar en el onboarding para cuando la waiting list dejase de existir, y los usuarios pudiesen registrarse directamente y entrar al foro sin esperar, con el fin de empezar a captar datos básicos de los usuarios que luego pudiesen resultar relevantes para los futuros puestos de nuestros futuros clientes.

    Había un diseño conceptual iniciado antes de que yo entrase y rápidamente empezamos a implantarlo en la plataforma. Al poco tiempo nos dimos cuenta de que la conversión de funnel era subóptima y teníamos que mejorarlo porque se nos iban muchos usuarios. Tras hacer un análisis exhaustivo del flujo me percaté de que dependiendo de la pantalla en la que estuvieses mirando el onboarding era más “difícil” o menos, principalmente porque tenías que hacer mucho scrolling para darle al botón de siguiente en el momento de pasar al siguiente paso. Esto pasaba con las pantallas de móviles que no tenían fijo el botón de siguiente y además los usuarios no sabían que tenían que hacer scrolling porque a veces no se veía la siguiente pregunta y pensaban que ya habían acabado o no pensaban en hacer el scrolling.

    Aquí aprendí la importancia del dog fooding y de usar siempre y hacer QA como Product Manager y de hacerlo en diferentes dispositivos, pantallas además de ver todo lo que puedas, si puedes, las sesiones de pantalla grabadas de los usuarios.

    Pero algo se me quedó en la mente y recordé por qué un caso de negocio que había leído sobre encuestas online con Typeform. Y es la reducción de fricción para el usuario mediante la eliminación de distracciones visuales. Es decir que si tienes que hacer al usuario varias preguntas en la misma pantalla en muchas ocasiones, o casi siempre, es mejor preguntarlas en diferentes pasos que todas juntas. Esto mejoraba la conversión.

    Me quedé con la idea para futura iteraciones y mejoras del onboarding porque ahora no íbamos a rediseñarlo entero. Aunque se hizo y añadió más flujos varias veces.

    Mientras tanto seguíamos consiguiendo usuarios, nuestra principal vía eran anuncios de social media y nos costaba varias decenas de dólares conseguir el email de un usuario, es decir estaba saliendo muy cara la captación. Y yo empezaba a ver que si seguíamos así la empresa no dudaría demasiado o no seríamos capaces de demostrar la hipótesis por falta de caja. Por lo que empecé a pensar en iniciativas y leer sobre adquisición de usuarios para ayudar a marketing en sus esfuerzos.

    A la par estábamos haciendo test A/B junto con el equipo de data en el onboarding para mejorar la conversión y añadir más preguntas que resultasen valiosas. Lo de añadir más preguntas nunca me convenció del todo porque en una plataforma así yo priorizaría conversión a datos aunque entiendo el modelo pero el conceptual era, si para nosotros como negocio una pregunta o la obtención de un dato nos aporta más valor que el número de usuarios que perdemos en el proceso nos compensa. Y es cierto pero desde ahí sólo ves la perspectiva del negocio y no del usuario. Siempre ha de haber un balance y el product manager ha de pensar en el usuario. Pero esto es mi punto de vista claro…

    Los test duraban por lo general una semana porque teníamos que conseguir suficientes usuarios para ver si eran significativos o no y además tener muy en cuenta los cohortes de cada grupo de usuario. Desgraciadamente muchos de los tests, salvo excepciones o cambios drásticos del flujo eran poco significativos y o había que repetirlos o esperar más tiempo para realmente ver si merecía la pena cambiar a la opción B.

    El problema de growth y su solución

    Habiendo estado en el mundo start-up desde 2010 en España y leyendo durante muchos años Techcrunch y otras publicaciones entendía que nos encontrábamos en un momento clave en el que teníamos todo por demostrar y que el tiempo se agotaba.

    Y la clave, como suele pasar, eran dos:

    • Conseguir más facturación, pero claro el modelo de recruiting estaba empezando y no teníamos la operativa para escalar ni usuarios suficientes
    • Conseguir más usuarios, pero nos estaban costando muy caros

    Por lo que decidí hacer una investigación y pensar desde primeros principios para resolver el problema dos, es decir el de conseguir más usuarios que era a su vez parte de mi labor, por no decir la fundamental. 

    ¿Qué hice? Pues pensar en quiénes eran realmente nuestros usuarios y si me cuestioné si estábamos llegando a ellos a través de las mejores plataformas con la propuesta de valor que les ofrecíamos. Y me hice las siguientes preguntas:

    1. ¿Quiénes son realmente nuestros usuarios? Profesionales comerciales de Estados Unidos en diferentes momentos de su carrera profesional y aquellos que puedan estar interesados en convertirse en comerciales.
    2. ¿Cuál es nuestra propuesta de valor? Un foro anónimo donde compartir experiencias y hacer y responder preguntas en comunidad para que el saber sea compartido. Una especie de Quora y Reddit de ventas. A la par les ofrecemos nuevos trabajos en caso de que estén buscando puestos.
    3. ¿Saben nuestros canales de marketing si una persona es de ventas, y si la respuesta es no, cómo lo podemos saber? No, no lo saben porque usamos Facebook y al menos que pongas o tengas actualizada tu profesión no lo sabe. LinkedIn y plataformas de empleo lo saben.
    4. ¿Dónde están las personas que quieran conocer o aprender de ventas? En plataformas como la que estábamos creando o en Reddit.
    5. ¿Dónde están las personas que están buscando nuevos trabajos de comerciales? En LinkedIn o Indeed.

    Ahí tenía mi respuesta. LinkedIn o Indeed eran la clave, estábamos demasiado enfocados en el engagement y en el foro cuando nuestra principal propuesta de valor y el modelo de negocio eran los puestos de trabajo y el matching entre candidatos y empresas.

    Y me pregunté, ¿qué pasaría si creásemos ofertas de nuestras empresas en estos canales y pidiésemos a los usuarios registrarse y cumplir nuestro onboarding?

    Yo ya había hecho recruiting antes y conocía LinkedIn, Indeed y otras plataformas y su potencial para conseguir candidatos, no tenía duda de que iba a ser una idea con mucho potencial. Así que ese qué pasaría si y el pensamiento lateral y basado en primeros principios consiguió un crecimiento explosivo de usuarios que nos ayudó a levantar una ronda B de $26M de financiación.

    Eso sí, no pasó de la noche a la mañana. Tardé varias semanas en convencer a mi jefa y a la responsable de operaciones en hacer un test para probar mi hipótesis. Se lo comentaba una y otra vez en cada reunión pero desgraciadamente pensaban que no tenía sentido ya que estaban con demasiado foco en el foro.

    Finalmente en un viaje a Berlín en el que fuimos varias personas del equipo de producto y diseño para hacer equipo tuve la oportunidad de volverlo a explicar a mi CPO quien me preguntó: ¿esto quién lo hace? Y tuve que enseñarle en vivo en LinkedIn cómo funcionaban empresas de recruiting como Toptal o Spring Professional y que todo el mundo del sector usaba para sus ofertas de clientes ofertas de empleo en portales de empleo.

    Al verlo me dijo, en la próxima reunión con la COO yo te apoyo en esto.

    El momento de crecimiento astronómico 

    Dimos con la tecla, tras la primera prueba para validar la hipótesis la COO vió el ahorro de costes y cómo se estaban multiplicando por 6 los usuarios gastando lo mismo y no dudó en dar más presupuesto a las ofertas y empezamos a crecer y conseguir usuarios.

    Tanto que teníamos el problema que nos faltaban empresas para tantos candidatos que nos llegaban. Comenzamos a cerrar acuerdos, reclutábamos candidatos y nuestra facturación empezaba a crecer. Incluso cerramos un acuerdo comercial de $120.000 para un plan anual.

    La empresa estaba eufórica. Gracias a esto conseguimos levantar 26 millones de dólares en financiación y pudimos crecer en equipos y trabajar en nuevas iniciativas que íbamos conceptualizando paso a paso. 

    Íbamos tan bien y nos gastábamos tanto en los anuncios de empleo que una de las principales plataformas que usábamos vió que no se cumplían sus normas, esas que nadie se lee, en el proceso de ofertas y nos baneó de poder subir más ofertas durante una semana. Fue mi peor semana en la empresa como os podéis imaginar, el CEO me dijo, bueno pues a buscar otras formas Edu… Yo sabía que había pocas o ninguna “otras formas” de conseguir algo tan explosivo.

    Pero por suerte lo solucionamos implementando un onboarding que cumpliese con sus políticas, aunque perdimos algo de conversión, y el coste disminuyó aún más. Tanto que ahora en lugar de 6 usuarios por el coste inicial conseguíamos 30. 

    Más crecimiento de usuarios.

    Empezamos el product lead growth y el SEO

    Comenzamos a pensar que con un crecimiento tan explosivo era el momento de intentar conseguir que nuestros usuarios nos recomendaran de alguna manera a otros miembros de su red.

    Para ello implementamos un sistema en el que las personas podían linkar su LinkedIn o su email y dar a conocer Bravado. 

    La idea funcionaba, no era perfecta, se podía mejorar, pero funcionaba y nos dio más crecimiento todavía.

    Comenzamos también a pensar en el SEO en la publicación de artículos o en hacer SEO programático con los datos que teníamos de los candidatos, al igual que hacía Glassdoor.

    Algunas de estas iniciativas se implementaron aunque con la mirada atrás y los conocimientos actuales habría puesto todo en abierto en lugar de poner muros o pop-ups para conseguir el registro. Pero eso es otro tema.

    El modelo de negocio y cómo estaba la empresa cuando marché

    Bravado tenía un modelo de negocio particular cuando estuve allí, cobraba el 15% del sueldo anual del candidato a las empresas además de un fee de $10.000 de entrada por poder usar la plataforma. 

    Por razones operacionales y errores que se cometieron en el área de marketplace o la externalización de el filtrado de perfiles hizo que no se estuvieran consiguiendo los objetivos de matching de candidatos ni de recruiting que teníamos.

    Pero en cuanto a growth lo cierto es que en un año y pocos meses habíamos pasado de tener 1.000 usuarios al mes, en el mejor de los meses, a 20.000 usuarios registrados, de los cuales el 33% completaban un onboarding de 33 pasos. 

    Es decir había más de nuevos 8.300 candidatos mensuales que podíamos matchear con empresas.

    Con haber conseguido hacer un placement de 20 candidatos mensuales a un sueldo medio de 100k, estaríamos hablando de una facturación de 200k anuales que serían $2,4 millones de dólares de facturación anual, lo que disminuiría el burn rate y nos daría tiempo para conseguir más clientes, crecer y crear otras verticales. Y esos 20 candidatos representan sólo un 0,25% de los candidatos que entraban en la plataforma mensualmente en ese momento. No era nada descabellado. Pero yo no estaba cerca de esas áreas y querían que me centrase en más crecimiento en lugar de resolver potenciales problemas de otras áreas.

    Marché de Bravado pero me llevé muchos conocimientos, alegrías y la satisfacción de un comentario de los fundadores en el viaje de empresa que hicimos a Turquía. Recuerdo la noche en Estambul cuando dijeron: “Edu, tu has conseguido desbloquear el crecimiento, y gracias a ti levantamos la ronda de financiación y estamos hoy aquí. Gracias.”

    Gracias a todo el equipo con el que trabajé, me llevo muchos buenos recuerdos y aprendizajes que darían para varios posts, desde cómo gestionar el equipo cuando muchos miembros están en países en guerra, pasando a cómo crear un club de lectura en un departamento de producto, a cómo gestionar cambios radicales en tu equipo de ingeniería y un larguísimo etcétera. 

    Si has llegado hasta aquí espero que te haya gustado y gracias por leer.

    Artículo escrito sin Inteligencia Artificial

  • ¿Qué es ser realmente Product Manager?

    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:

    1. 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.
    2. 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.