No estudié para ser Product Engineer: cómo llegué igual

Esta mañana, antes de las nueve, ya tenía abiertos VS Code, una consola de Supabase y un Excel de veintipico de versiones con el nombre: FIJI Calcs v3.23b.xlsx. Lo que estoy construyendo es un producto que valida brokerages de real estate en Estados Unidos. En el fondo, es traducir esa planilla a un sistema sobre el que se apoyen decisiones de compra-venta de millones de dólares. Cada celda con fórmula es una decisión de producto que tengo que entender antes de tocar una línea de código.

Hace cinco años, mi día empezaba muy distinto. Cursaba el último año de Bioingeniería en el ITBA, en plena pandemia, encerrado, leyendo papers sobre cáncer colorrectal con metástasis hepática. Mi tesis era un intento honesto de aplicar machine learning para predecir mortalidad y mutación del gen KRAS en pacientes oncológicos, en colaboración con el Hospital Italiano de Buenos Aires. No era un trabajo final más: estábamos probando una hipótesis real, contra papers reales, con tutorías de un equipo médico que nos explicaba conceptos de diagnóstico para que pudiéramos relacionarlos con los resultados que arrojaban nuestros algoritmos. En la carrera no veíamos ML ni programación con esa profundidad, así que aprendíamos a demanda y contra deadline. Fue agotador. También fue lo que me convenció de que me gustaba más construir herramientas que usarlas.

El salto a software, sin embargo, no llegó por la tesis. Mi primer trabajo formal fue en una empresa de mantenimiento de equipos médicos, optimizando procesos a nivel nacional. Era un buen lugar para arrancar, pero la dinámica presencial no cerraba con lo que yo buscaba: vivía a casi dos horas en colectivo de la oficina y el rol podía hacerse perfectamente remoto. Ese desfase me hizo prestar atención a lo que sí quería: trabajar de forma remota, meterme en una industria donde pudiera construir productos, no solo optimizar procesos existentes. Por esos meses me llegó la oferta de una software factory. Mejor paga, modalidad remota, y la puerta de entrada a una industria que ya venía coqueteando desde la tesis. Acepté. Llevaba un año entrenando modelos en Python, pero nunca había trabajado en un equipo de software de verdad. Git, code reviews, deploys, todo eso lo aprendí sobre la marcha. Lo que sí traía, sin saberlo del todo, era la forma de pensar problemas que me había dejado la tesis.

De esa decisión a hoy pasaron cuatro años, una startup en Techstars, un equipo en California, y clases de Técnicas Digitales a chicos de cuarto año en mi ex colegio secundario en Posadas.

Lo que la bioingeniería me dio (y no era código)

Cuando entré a software pensé que llegaba con dos cosas: un año entrenando modelos en Python para la tesis, y los nervios de no saber Git. Cuatro años después, descubrí que lo que más uso todos los días no aprendí ni en Python ni en Git. Lo aprendí cursando ingeniería.

La carrera me enseñó a ver problemas como procesos, y a dividir esos procesos en partes más pequeñas hasta que cada una se vuelve tratable. No es una habilidad épica. Es la base de todo. Esta semana, antes de escribir una línea de código para una pantalla nueva, me senté a dibujar en una hoja qué datos entraban, en qué orden se cruzaban, qué dependía de qué, y dónde estaban las decisiones que el usuario podía cambiar. Recién después abrí el editor. Materias como Señales y Sistemas, Fisiología Cuantitativa o Machine Learning compartían esa lógica: ningún problema interesante se resuelve de una sola vez, se resuelve por capas.

Pero el aprendizaje más fuerte no fue técnico. Fue cómo trabajar con gente que sabe de algo que yo no sé. En la tesis, los médicos del Hospital Italiano sabían oncología y yo sabía algo de ingeniería. La dinámica era escuchar el dolor real, entender el contexto clínico, y devolverles una propuesta que les sirviera. No tenía sentido que yo intentara volverme oncólogo. Tenía sentido que yo me apoyara en ellos para hacer lo que ellos no podían hacer solos.

Hoy hago lo mismo, pero con gente de real estate, de fintech, de operaciones de negocio. El dominio es otro. La forma de trabajarlo, no tanto.

Los primeros meses en software: lo que subestimé

Mi primera semana fue caótica. Me hicieron instalar herramientas que nunca había escuchado: Git, Node.js, VS Code, Figma. Mi primera tarea fue desarrollar un alta de usuario en el backend usando TDD con programación orientado a objetos. La primera semana!! Yo todavía estaba averiguando para qué servía cada ícono del editor.

Lo raro es que el problema no era entender el sistema. La cabeza ingenieril funcionaba: podía leer la complejidad, descomponerla, ver los trade-offs de cada decisión. El problema era la ejecución. Sabía el qué y el por qué; me faltaba el cómo en código. Hasta hoy me identifico más con esa descripción que con la del developer puro.

Pero el aprendizaje más caro de esos primeros seis meses no fue técnico. Fue darme cuenta de que estaba peleando con una identidad que yo mismo me había impuesto. "Soy ingeniero, tengo que poder aprender esto solo". Horas y horas frente a la computadora, sin pedir ayuda, en una época sin IA que te diera una mano. El síndrome del impostor crecía porque las tareas se acumulaban y yo seguía empecinado en no preguntar. Burnout, miedo a quedar en ridículo, todo eso. Y lo más absurdo es que mi objetivo original nunca había sido convertirme en el mejor desarrollador del equipo. Mi objetivo era entender cómo trabajaba un equipo técnico para algún día poder liderar uno. Pero la cabeza me jugaba en contra y me empujaba a buscar ser experto en lo que no hacía falta.

El click vino de una charla con mi tech lead. Yo le entregaba tarde porque iba ampliando casos de uso por mi cuenta, basados en hipótesis mías, no en problemas reales del usuario. Me explicó algo simple que cambió mi forma de trabajar: hecho es mejor que perfecto. Estaba invirtiendo Pareto. En vez de 20% de esfuerzo para 80% de resultado, gastaba 80% para sacar un 20% extra que nadie había pedido. Y eso no era prolijidad. Era un cuello de botella para el equipo.

Ese fue el primer aprendizaje grande que tuve que desaprender de la facultad. El siguiente vino más tarde, cuando empecé a darme cuenta de que mi mayor fortaleza no estaba donde yo más estaba esforzándome.

De Trainee a Product Engineer: lo que movió la aguja

Mi error como Junior fue querer tocar todo. TypeScript, Angular, Express, Tailwind, Bootstrap, PHP, Next.js, lo que apareciera. Cada tecnología nueva la sentía como una caja que tenía que conquistar. El resultado era predecible: era razonable en muchas cosas, pero no era confiable en ninguna.

El primer salto real vino cuando elegí un stack y dejé de saltar de árbol en árbol. TypeScript se volvió mi lenguaje y todo lo demás creció alrededor: Node con Express, Next.js, patrones de diseño, arquitectura. Tener un norte me permitió empezar a pensar en problemas más grandes que el ticket que tenía adelante. En esa etapa lideré varios proyectos end-to-end como Semi Senior: una plataforma marketplace de servicios, una plataforma B2B de gestión, un dashboard interno de trazabilidad. Entre todos, alrededor de 1.500 usuarios activos.

Pero el salto a Product Engineer no vino por escribir mejor código.

En esos proyectos descubrí algo que ahora me parece obvio: el cliente nunca llega con una feature pedida. Llega con un dolor, un proceso manual que le come horas, un cuello de botella que no entiende cómo destrabar. La feature es la traducción que nosotros hacemos de ese dolor. Y para que esa traducción sea buena, alguien del equipo tiene que tener la mirada del producto entero, más allá de su rol. Ese fue el lugar que empecé a ocupar.

A nivel equipo, lo que aprendí fue parecido. Cuando entré, el equipo cerraba sprints al 60% de predictibilidad. Para cuando dejé el rol, estábamos al 90%. No fue magia: fue identificar dónde se acumulaban los tickets sobre el final del sprint, repensar el refinamiento priorizando flujos antes que tareas sueltas, y cambiar el código-luego-testeo por testeo en paralelo. La diferencia no la hizo escribir más rápido. La hizo entender el sistema completo y mover la palanca correcta.

Si tuviera que resumir los cuatro años en un solo hábito, sería este: antes de tocar código, antes de elegir arquitectura, antes de cualquier decisión técnica, entender lo más posible el dolor del usuario. Volverte experto en su problema, no solo en tus herramientas. Después de cuatro años, sigo creyendo que ese hábito vale más que cualquier herramienta nueva que aparezca en el camino.

Techstars y producto bajo presión: cuando el código deja de ser lo más importante

En paralelo a mi trabajo en la software factory, me sumé como Product Engineer a una startup que entró al batch W24 de Techstars en Nueva York, dentro del programa Stellar & MoneyGram Accelerator. Lo primero que se sintió distinto fue la velocidad. Necesitábamos avances semanales para tener datos reales de usuarios sobre cada cambio. Eso obligaba a una integración que en una empresa más tradicional no se vive: mientras el equipo de ventas vendía la forma en que resolvíamos un problema, los desarrolladores la estábamos construyendo. Lo que ventas prometía, nosotros lo teníamos que hacer realidad la semana siguiente.

El momento en que entendí que mi rol había cambiado no fue una review brillante de código. Fue rediseñar un onboarding.

El producto tenía un onboarding largo que pedía mucha información personal antes de dejar al usuario probar nada. Los datos mostraban lo predecible: la gente abandonaba en el medio. La hipótesis fue que el costo de entrada era demasiado alto para alguien que todavía no sabía si el producto le servía. La decisión fue invertir la lógica: pedir lo mínimo indispensable para que el usuario pudiera probar, y recién después, con una persona acompañando, ir completando datos según hicieran falta. El engagement post-onboarding subió 40%.

Lo importante de esa anécdota no es la métrica. Es lo que me marcó del proceso: yo no estaba pensando en si una clase estaba bien tipada. Estaba pensando en por qué un usuario abandonaba en la pantalla tres y qué pasaba si la sacábamos. Esa es otra silla, otro músculo, otro tipo de problema.

Lo que más me llevé de Techstars no se enseña en un curso. Compartir mesa con founders, ver cómo piensan la ejecución, cómo tratan a la tecnología como herramienta y no como fin, me abrió la cabeza. Salí del programa con una idea que sigue dando vueltas: en algún momento quiero construir un producto propio que la gente realmente use.

Hoy: construir, enseñar, y seguir sin manual

Hoy mi semana se reparte en tres mesas. La primera es el producto en el que trabajo hoy, una plataforma de real estate para el mercado estadounidense. La segunda son mis clases de Técnicas Digitales en IPSAJ (Instituto Politécnico San Arnoldo Janssen), mi ex colegio en Posadas, frente a chicos de cuarto año. La tercera son los casos paralelos: problemas reales de empresas o personas que voy mirando para entender si puedo construir herramientas que les sirvan.

Las clases me sorprendieron por algo que no esperaba. Cuando uno tiene que explicarle un concepto técnico a chicos de 16 años, no alcanza con saber el tema. Hay que diagramar el camino mental para que el otro llegue a entenderlo. Esa preparación, paradójicamente, es lo que más usé después en reuniones con stakeholders adultos. Aprendí a defender una postura técnica sin volverla densa, a explicar trade-offs con ejemplos, a aceptar preguntas que me sacaban del guion. Antes me daba miedo decir "no sé, lo voy a investigar". Ahora es una de las frases que más uso, y descubrí que no te hace ver más débil, te hace ver más confiable.

Los casos paralelos son el tercer lado del triángulo. Lo último que me llamó la atención fue ver cómo un hospital en mi ciudad sigue administrando turnos del personal de salud y trazabilidad de equipos médicos con procesos manuales. Es casi simétrico a lo que hago hoy, traducir Excel a sistema, pero en un dominio que conozco desde la bioingeniería. Todavía no es proyecto, es conversación. La lógica que sigo es la misma de siempre: entender el dolor primero, ver si se puede aliviar con tecnología, y si vale la pena construir. Si arranca, mejor para todos. Si no, me queda como aprendizaje.

Si tuviera que ser honesto sobre lo que más me falta, no es técnico. Es comunicación. Mi inglés todavía no está al nivel que quiero para reuniones largas con equipos del exterior, y eso a veces me hace dudar en momentos donde tendría algo para aportar. Las soft skills de liderazgo las estoy construyendo en paralelo, pero todavía me siento más cómodo siendo el que ejecuta que el que decide por otros. Y la visibilidad pública no la tengo: hasta hace poco mi único canal era LinkedIn y conversaciones uno a uno. Este blog es parte de eso. La idea no es presentar un perfil terminado. Es documentar el camino mientras se hace.

---

Cuatro años después de aceptar una oferta que no entendía del todo, sigo sintiendo que estoy aprendiendo sin manual. Pero ya no me asusta. Aprendí que el manual no existe para nadie, y que el método que traje de la bioingeniería, dividir el problema, escuchar a los que saben, iterar contra la realidad, funciona en cualquier dominio donde el dolor del usuario sea real.

Si algo de esto resuena con tu camino, el que estás haciendo o el que estás dudando empezar, escribime. Los mejores aprendizajes de estos cuatro años los tuve en conversaciones de ida y vuelta.