La mayoría de los cambios de carrera ocurren en silencio: un proyecto termina, otro comienza y, poco a poco, aparece un nuevo cargo en LinkedIn. El mío no fue así. Empezó con una sola pregunta incómoda en una demo de producto: Ok... y qué quieres que haga con eso
Esa pregunta desveló un punto ciego en mi trabajo como ingeniero de datos y me lanzó a un camino inesperado: de construir canalizaciones impecables a asumir la visión de una plataforma de datos como un producto. Esta es la historia de cómo pasé de la comodidad del código a la ambigüedad de las necesidades humanas y lo que aprendí en el trayecto.
La pregunta que me persiguió: por qué. Presentábamos a la dirección logística de Austrian Post un mapa de calor dinámico que seguía en casi tiempo real la congestión de paquetes en centros logísticos. Lo alimentábamos con una canalización de streaming que ingería decenas de miles de eventos por minuto. La interfaz era limpia, los datos recientes y la latencia inferior a 15 minutos. Por cualquier métrica de ingeniería, era un éxito.
Mientras guiaba la demo, amplié en un centro de distribución. Aquí detectamos un aumento del 43 por ciento del volumen entrante respecto a la línea base para esta hora. Silencio. Un responsable senior de operaciones se inclinó y preguntó: Ok... y qué quieres que haga con eso
La pregunta me dejó sin aire. No fue desdén, fue honestidad. Entendí una verdad incómoda: no habíamos creado una herramienta de apoyo a decisiones, sino un espejo estadístico. Técnicamente elegante, operativamente incompleto.
Le había entregado la señal, pero no el significado. Le mostré algo interesante, no útil. La anomalía era real y los datos correctos, pero no la vinculé a sus decisiones: redirigir furgonetas, convocar antes al turno de noche, retrasar salidas. Para él, ese número era ruido hasta venir acompañado de una recomendación o una alerta.
Durante semanas, la pregunta Qué quieres que haga con eso resonó en mi cabeza. Cambió mi enfoque: de entregar salidas a habilitar resultados. De responder qué, a perseguir sin tregua el para qué.
En otro entorno, aquel feedback habría acabado como una petición para la versión 2.0. En nuestra cultura, que valora el impacto por encima del output, no fue crítica, fue una invitación a resolver el problema de fondo.
Como ingeniero de datos me había forjado sobre el cómo. Disfrutaba la lógica elegante de una buena canalización. Sin embargo, aquel panel marcó un punto de inflexión. No bastaba con que los datos fueran rápidos y correctos; debían ser significativos. El por qué dejó de ser segundo plano para convertirse en lo esencial. Esa obsesión por el propósito inició mi transición a Product Owner de Plataforma de Datos: del territorio cierto del código a la ambigüedad de las personas.
Una cultura de curiosidad, no solo de código. Mi cambio estuvo íntimamente ligado a la dinámica entre mi empresa, Agile Actors, y mi cliente, Austrian Post. Donde otros viven rigidez, yo encontré flexibilidad y una visión que ve a las personas como inversiones en evolución.
No fue solo un lema. En una planificación, revisábamos tareas de canalizaciones priorizadas por esfuerzo técnico. Pregunté en voz baja: Cuáles de estas ayudarán de verdad al negocio en los próximos meses Cambió la conversación. Replanteamos prioridades, llamamos a usuarios internos y ajustamos el plan por impacto real, no por complejidad. Mi Chapter Lead en Agile Actors lo valoró como mejora continua, no como desvío de alcance. Dio un paso más y abrió una conversación sobre mi desarrollo para acercarme al negocio y crear más valor.
Aquel apoyo fue decisivo. Cuando Agile Actors patrocinó mis certificaciones PSPO, no fue una excepción, sino la expresión de una creencia: invertir en la curiosidad paga los mejores dividendos. No formaban solo a un ingeniero de datos; cultivaban a un futuro líder capaz de tender puentes entre lo técnico y los objetivos del cliente.
De construir canalizaciones a trazar una visión de producto. Ese respaldo convirtió una ambición personal en una ruta clara. Mis mentores me introdujeron en un concepto revolucionario para un servicio postal centenario: tratar toda nuestra plataforma de datos como un producto interno.
Tradicionalmente éramos un equipo de servicio que ejecutaba pedidos, montaba pipelines y arreglaba bugs. La mentalidad de plataforma como producto lo cambió todo. Infraestructura, herramientas y datasets ya no eran solo activos técnicos; eran productos con clientes internos: analistas, data scientists, desarrolladores y decisores. Mi trabajo pasó a ser Product Owner de esa plataforma.
Una de mis primeras iniciativas fue crear un marco reutilizable de ingesta para alimentar nuestro lakehouse en Databricks. Hasta entonces, incorporar una nueva fuente implicaba escribir código Spark a medida, flujos frágiles y lógica duplicada.
Le dimos la vuelta: diseñamos un framework que permite a los data engineers dar de alta nuevas fuentes solo con archivos de configuración, definiendo mapeos de esquema, frecuencia de actualización y reglas de calidad en YAML con código mínimo. Abstrajimos la complejidad y dimos un estándar gobernado y escalable para aterrizar datos en el lago.
Además del framework, entregamos un ecosistema: documentación, guías de onboarding, plantillas reutilizables y acuerdos de servicio confiables. Lo que tomaba semanas pasó a horas. El salto fue cultural tanto como técnico. Dimos autonomía a los equipos asegurando consistencia y calidad en toda la plataforma.
Pronto empecé a crear roadmaps de funcionalidades, priorizar mejoras según feedback interno y alinear entregas con casos de uso transversales. El cambio del cómo técnico al por qué estratégico fue como pasar de programar pipelines individuales a moldear cómo toda la organización trabaja con datos.
Lo que conservé y lo que aprendí. No se trató de borrar mi pasado, sino de construir sobre él. Conservé el pensamiento sistémico para comprender de punta a punta, desde el escáner en la mano del cartero hasta la confirmación final de entrega. Mantuve la descomposición de problemas para trocear retos enormes como mejorar la eficiencia de entrega en pasos accionables, igual que al diseñar una canalización compleja. Y preservé el respeto por la calidad: la obsesión por la integridad de datos se volvió arma secreta al hablar de productos de datos confiables.
Tuve que aprender gestión de stakeholders al incluir logística, ventas, finanzas y dirección en Austrian Post, entendiendo sus lenguajes y negociando acuerdos. Aprendí el arte de decir no. El responsable regional quería un panel en tiempo real con cada camión sobre un mapa actualizándose al segundo. Como ingeniero sabía que era factible. Como Product Owner debía preguntar para qué. Tras entrevistar a los despachadores, descubrimos que no necesitaban el mapa llamativo, sino una alerta fiable cuando un camión se proyectaba con más de 30 minutos de retraso. Construimos el sistema de alertas, más simple y valioso. Decir no a la función wow en favor de la que funciona dio vértigo, pero fue lo correcto. Y abracé la ambigüedad, tomando decisiones con información incompleta, avanzando para aprender e iterar en lugar de esperar la respuesta perfecta.
Encontrar ritmo en el caos con Scrum. Cuando Agile Actors ofreció patrocinar mi certificación Professional Scrum Product Owner, era escéptico. Asociaba Scrum con rituales rígidos. La formación fue reveladora: un marco empírico para navegar la ambigüedad con intención.
En un producto de datos en Austrian Post, valor puede ser escurridizo. Es una alerta que evita que se rompa una clasificadora, un proceso que optimiza rutas y ahorra combustible, o un modelo que mejora la corrección de direcciones. La formación me enseñó a hacerlo tangible. Aprendí a definir una Meta de Producto clara y descomponerla en Metas de Sprint concretas.
Esto transformó nuestro trabajo. La meta dejó de ser construir una canalización para convertirse en proveer al equipo de Calidad de Direcciones una fuente diaria confiable de devoluciones para validar su nuevo algoritmo de corrección.
La retrospectiva de sprint encarnó nuestra mentalidad de crecimiento compartida. En una retro descubrimos que la planificación fallaba porque la experta clave del negocio solo estaba disponible los jueves. Propusimos un espacio de cocreación los miércoles. No está en la guía de Scrum, pero fue la adaptación que necesitábamos para que el marco funcionara en nuestro contexto.
Cambiar el teclado por una brújula. Lo más difícil fue interno. Mi confianza nacía de resolver con mis manos. En un proyecto crítico, el equipo sufría un problema de rendimiento en modelos dbt que procesaban datos de escáneres en hubs. La construcción tardaba tres horas en vez de treinta minutos. Me picaban los dedos por entrar a depurar macros Jinja. Sentí ansiedad, miedo a perder credibilidad técnica.
Mi Chapter Lead me dijo: Puedes demostrar que aún dominas lo técnico, pero el equipo no necesita otro par de manos, necesita dirección y foco.
Fue un punto de inflexión. Aprendí a liderar por influencia, no por instrucción. Mi valor ya no estaba en el código, sino en la claridad de la visión. Debía empoderar al equipo de ingeniería y apartarme para que volaran.
Una nueva definición de hecho. Hoy empiezo con una necesidad de datos y termino cuando alguien puede actuar con confianza. Hecho ya no es escribir una canalización a medida para traer una única fuente, sino ver un dataset fluir al lakehouse mediante nuestro framework de ingesta con solo un archivo de configuración. Es que un ingeniero incorpore un sistema en horas en lugar de semanas, o que un analista consulte datos consistentes y bien documentados sin temer transformaciones opacas. Es que un data scientist experimente con datos frescos y confiables porque la plataforma garantiza calidad y disponibilidad.
Pasé de construir yo mismo a habilitar que otros se muevan más rápido, más seguros y con más autonomía. Hecho ya no es código que funciona, es una plataforma que empodera. Es que un científico de datos despliegue un nuevo algoritmo de validación de direcciones en minutos, no semanas, porque la plataforma lo hace posible. Dejé de completar tareas para habilitar resultados.
Convertirme en Data Product Owner no borró mis raíces de ingeniería, les dio propósito. El cambio fue posible gracias a la colaboración entre una consultora que invierte en su gente y un cliente que confía para resolver problemas reales. Aprendí que el mayor crecimiento surge cuando tienes el valor y el respaldo para construir no solo lo correcto, sino lo correcto en conjunto.
Mirando atrás, lo más duro no fue aprender marcos de producto o gestionar stakeholders. Fue soltar la creencia de que mi valor estaba en el código que escribía. Mi valor pasó a ser la claridad que aporto, las preguntas que formulo y los resultados que habilito para otros.
Ese giro, de outputs a outcomes y del qué al por qué, cambió mi carrera y la manera en que entiendo el impacto en cualquier rol técnico. Si estás en una encrucijada similar, mi consejo es simple: mantén la curiosidad, haz las preguntas incómodas y no temas cambiar el teclado por una brújula.