La aventura de Bdeo

La aventura de Bdeo se acaba hoy para mi después de dos años y pico. Y como en todas las aventuras, lo importante es cómo de divertido y enriquecedor ha sido el viaje. 

Cuando me uní al equipo, lo hice con retos muy molones:

  • Construir las bases y hacer crecer una cultura de producto, en un entorno que antes había estado más enfocado en lo que podrían ser servicios profesionales.
  • Crear y hacer evolucionar un equipo de producto, en una organización donde no existían roles como PM y PD.
  • Definir la estrategia y construir y dirigir el roadmap. Ayudar a priorizar y poner mucho foco en construir los productos correctos en el momento correcto para cambiar progresivamente una industria. 
  • Construir dinámicas de trabajo de producto. Empujar el product discovery, el research con clientes y ayudar a ser una organización más data informed
  • Empujar la excelencia en la ejecución y la entrega de valor. Meter en el ADN eso del urgency feeling y el speed for execution. 
Foto Equipo Bdeo

Después de lo que han sido 2 años muy intensos, creo que puedo contar en todas esas dimensiones una historia de éxito gracias a un equipo apasionado, comprometido y muy capaz.

Juntos no sólo hemos mejorado y escalado los productos existentes para la industria de motor; sino que además en el último año y medio hemos tenido la oportunidad de abrir el nuevo vertical de hogar lanzando desde cero dos nuevos productos que estoy segura cambiarán la escala de la compañía en los próximos meses.

Bdeo es hoy una empresa donde la función de producto tiene unas bases sólidas y un equipo con ganas, poder y ambición para seguir creciendo con todos los retos que vienen. 

Yo siento que es el fin de una etapa y que es momento de saltar a la siguiente aventura. El próximo paso será también muy retador pero lo afronto con enorme respeto, ilusión y ganas. Ayudar a liderar perfiles de producto en una compañía que está en la siguiente fase y con equipos de mayor tamaño que me enfrentarán a retos de escalado, coordinación y gestión distintos. 

Bdeo ha sido una oportunidad enorme y una etapa por la que sólo puedo estar agradecida.

 + Gracias Julio por darme la oportunidad de unirme a un proyecto con una misión tan bonita. Por darme la autonomía, la libertad y la confianza para proponer cambios y acompañarme y respaldarme poniéndolos en marcha.

+ Gracias Ruth por construir una cultura de la que da vértigo salir, por dar espacio para escuchar, proponer, mejorar y empujar siempre la excelencia y el go the extra mile. Gracias por ser siempre una sonrisa al otro lado de la mesa o de la pantalla. 

+ Gracias a toda la función de producto, desarrollo y data. Y dejadme dar las gracias más especiales a Íñigo, Sara, Rafa, Cris y Vicente. Por la exigencia, la autocrítica y las ganas de sumar y remar siempre. Por dar y recibir feedback para que todos hayamos podido crecer y ser hoy mejores profesionales. Por confiar, por esperar y por estar al 200% siempre. Por haberme ayudado a crear un espacio de trabajo retador pero seguro. 

+ Y a todos por entender y apreciar (espero) mi honestidad (ese radical candor), mi intensidad y mi exigencia como forma de hacer producto.  

Siempre digo que si te vas de un sitio sin sentir que pierdes algo y sin un poquito de miedo, es que te vas tarde. 

Bdeo es un proyectazo que tiene todos los ingredientes para ser una historia de éxito. Y ahora le toca a otras personas del equipo dar un paso adelante y ayudar a sacarla del estadio. 

Divertíos, aprended y disfrutadlo. GRACIAS y, como siempre digo, nos vemos en los bares o cuando los caminos, ojalá, se crucen de nuevo. 

¿Qué he aprendido de cómo ven otros el rol de CPO?

He aprendido mucho leyendo a todos los que han participado en el artículo que ha montado Samuel Gil para Suma Positiva sobre cuál es el rol del CPO en empresas de tecnología.

Samuel hace un buenísimo trabajo compartiendo conocimiento y experiencias en SumaPositiva. Si no conoces su newsletter, te recomiendo que te suscribas y la leas atentamente cada fin de semana con un buen café.

Ya dejé algunas ideas de cómo entiendo yo este rol pero para mi lo más interesante ha sido tener la oportunidad de ver cómo lo entienden otras personas del sector que para mi son referencia. Os quiero compartir las ideas con las que me quedo de cada uno de ellos.


Diego Mariño (Kibo Ventures, Ducksboard, NewRelic)

Diego plantea un debate interesante. «Si el CPO es el responsable último de todo lo que «salga por la puerta» de la compañía y acaba en manos de un cliente ¿el equipo de desarrollo/ingeniería ha de reportar al CPO y estar dentro de su organización (como responsable último de lo que sale por la puerta)?«

Más allá de que la respuesta a esa pregunta sea todo un melón, me resultó significativa esta reflexión también que lanza: «la principal paradoja del rol (es que) el éxito en sus objetivos es crítico para la empresa que necesita un CPO, pero se le va a juzgar por indicadores que dependen de equipos sobre los que no tiene poder de decisión».

Quizás es que yo he tenido mucha suerte, pero mi experiencia hasta ahora no ha sido ésa. Y desde luego no puedo estar más de acuerdo con Diego en que la relación CPO <> CTO y su forma de trabajar conjunta son la base del éxito del producto que se entrega.


Manuel Vida (Genially)

También coincido con cómo Manuel resume en una frase el principal reto de un responsable de producto: «alinear la visión y estrategia del CEO con las iniciativas del equipo de producto y viceversa. Es decir, reducir desalineamientos entre la visión y la ejecución«.

Igualmente me gustó leer dos cosas en lo que yo también insisto mucho.

  • Un CPO es un desatascador de cosas, quien empuja para que las cosas sucedan. Él dice algo muy parecido: «El CPO busca el acuerdo del C-level antes de ir adelante con iniciativas clave. El rol de CPO no debería ser una figura solitaria que actúa por su cuenta, pero sí debería empujar para que las cosas pasen».
  • Recopila problemas. Haz que quienes te piden cosas te cuenten la necesidad a resolver, pero no dejes que enuncien la solución. Él lo dice así: «Intenta huir de las soluciones disfrazadas de objetivos, sobre todo si no están respaldadas con datos. Tampoco desprecies una buena hipótesis
  • Haz que el equipo pueda estar enfocado. Rechaza iniciativas. O pospónlas para más adelante. Gestiona el «no» y haz que los stakeholders entiendan los motivos. Sobre la necesidad de foco, Manuel dice: «No intentes llevar más iniciativas adelante de las que el equipo sea capaz de abordar. Esto vale para toda la empresa en realidad«.

José Ramón Pérez Agüera (McKinsey, Mercadona Tech, Amazon, Jobandtalent, Tuenti)

Me gustó que habla de cultura de producto y de la formación y crecimiento del equipo. Me dio rabia ver que son dos cosas de las que yo hablé demasiado poco en mi parte 🙂

Tan seguro está José Ramón de que una de las funciones esenciales del CPO está en montar un buen equipo de producto que dice que «el producto del CPO es el propio departamento de producto y como tal debe diseñarlo de manera que se convierta en una organización dentro de la empresa capaz de aportar valor».

También habla de saber delegar y dar ownership a los product managers. Algo tan necesario pero tan complejo de conseguir. «Es un error no resistirse a la tentación de decirles a los product managers qué producto deben construir. En mi caso, en la mayoría de ocasiones, mi equipo ha llegado a conclusiones con las que yo como product manager no estaba de acuerdo, pero siempre he tenido claro que mi rol como CPO no es el de construir el producto ya que esta tarea es responsabilidad de los product managers y de los equipos en los que se integran.»

Otro asunto clave: un CPO pegado al barro y que se haya pegado con la realidad, más allá de las recetas mágicas que todos hemos leído en libros de referencia. «Cualquier CPO experimentado puede repetir como un loro lo que ha leído en Inspired o en cualquiera de los libros referenciados más arriba. El problema reside en que la teoría sobre cómo hacer producto y cómo montar organizaciones de producto es fácil de entender, pero muy difícil de aplicar, ya que no en todos los casos se aplican los mismos principios. Un asesor, consultor o CPO in residence que no pase suficiente tiempo en la organización, y por suficiente tiempo me refiero a al menos un año, no será capaz de implementar un modelo de organización de producto exitoso por falta de comprensión de los detalles y matices que definen a cada organización.»

Y por último, el rol del CPO como un desbloqueador de problemas y un filtro o paraguas para que el equipo esté enfocado. «El CPO debe ser capaz de inspirar a sus equipos sin decirles lo que tienen que hacer, debe ser el principal ayudador, preocupado siempre de eliminar los bloqueos que los equipos puedan tener en un modelo de servant muy claro y por ultimo pero no por ello menos importante debe ser un paraguas que mantiene a sus equipos centrados mitigando esos chaparrones que muchas veces caen y donde el CPO debe ser capaz de lidiar con eficiencia sin que los equipos se vean afectados y pierdan el foco».


Javier Escribano (OnTruck, TouristEye)

Con Javi tengo la suerte de tener una relación un poco más cercana y conozco su visión de producto. He aprendido mucho de él, le he lanzado muchas preguntas.

Sabe mucho de negocio, así que no me sorprendió ver que un mensaje fuerte que lanza es que producto es un apoyo a la venta y a la gestión de clientes fundamental. «Un buen líder de producto debe traer negocio a la empresa. Debe estar en el negocio, ser capaz de hacer challenge a decisiones de negocio, proponer cambios e incluso liderar pilotos y equipos de negocio si se le requiere. Debe hablar y vender a clientes todas las semanas. Y debe pensar en oportunidades de negocio para dentro de 6 meses.»

Y también insiste en la necesidad de que el CPO mantenga el foco y ayude al equipo a estar centrado. «Es clave que sepa priorizar y enfocar al equipo, mientras maneja y mantiene la relación con todos los departamentos de negocio. A más personas de negocio, más peticiones de problemas y features. Debe saber fijar la cultura en la empresa para que se hablen de problemas, se prioricen pensando en la empresa y no en cada departamento. Debe pedir y dejar hueco al equipo para que entiendan bien los problemas, en vez de saltar a las soluciones dadas. Debe proteger esos experimentos de producto o tecnología que no son prioritarios en el corto plazo, pero tienen mucho potencial a futuro. Debe saber cuándo invertir en soluciones a corto plazo y cuando pegar un salto.»