Por qué elegí ser Product Engineer
Cuando comencé mi carrera como desarrollador web, estaba convencido de que mi trabajo era resolver la mayor cantidad de tickets posible, usando el mejor código posible. Cada vez que una tarea llegaba a la columna de “Done”, daba mi trabajo por terminado.
Pero llegó un día en que eso cambió.
Entré a trabajar en una startup de salud y me encontré con un factor que resultaba determinante en la ecuación: la necesidad del usuario.
Mi código ya no era para dar a conocer los servicios de una empresa ni para que alguien pudiera comprarse una linda remera. En salud es distinto: el usuario tiene un malestar o una preocupación impostergable. Si la aplicación falla, es lenta o requiere demasiado esfuerzo para entender su uso, le estamos sumando un problema extra en un contexto de vulnerabilidad.
No hay segundas oportunidades, no hay más tarde, no hay mañana.
En ese momento fue cuando me di cuenta de que me gustaban más los problemas que las soluciones. Antes de abrir el editor de código, necesitaba entender el porqué y el para quién. Dejé de ser un desarrollador para convertirme en un Product Engineer.
¿Es para todos este rol?
La respuesta simple es no. Es un rol que no encaja en todos los contextos.
- Si trabajamos en una Software Factory, nuestra forma de aportar valor es optimizando al máximo el tiempo de trabajo para poder hacer una mayor cantidad de entregas.
- Si vamos al caso de Big Tech, sos una pieza dentro de un sistema gigante, por lo que la especialización técnica suele ser lo más requerido.
El Product Engineer vive y destaca en Startups y Scale-ups.
Son entornos de alta incertidumbre, equipos pequeños y la distancia entre el código que uno escribe y el usuario final es mínima. En este contexto, tener ingenieros que entiendan el negocio es una ventaja enorme: nos permite iterar rápidamente y descartar ideas antes de gastar la más mínima energía en ellas.
Más allá del código
Lo que define a este rol es que el trabajo comienza mucho antes de escribir una línea de código y termina mucho después de hacer el release. El Product Engineer no recibe tareas; participa del proceso de punta a punta:
- Discovery: Es el momento de entender cuál es el problema de nuestro usuario. Si fallamos acá, lo próximo no sirve de nada.
- Planificación: Decidimos qué construir, pero sobre todo, qué NO construir. Los recursos en una startup son limitados; priorizar de forma correcta es vital.
- Implementación: Nuestro lugar de confianza. El momento de escribir la solución técnica.
- Medición: El momento de la verdad. Vamos a ver el impacto de lo que lanzamos. ¿Logramos resolver el problema?
Es un loop infinito donde las métricas mandan. Quizás, resolviendo el problema, agregamos nuevas fricciones. O lo resolvimos de una forma rústica y podemos mejorarlo. O tal vez entendimos mal la necesidad del usuario y volvimos todo aún más complejo.
La tecnología al servicio del producto
¿Cómo cambia esto en el día a día de un ingeniero?
Fundamentalmente cambia la toma de decisiones. No voy a elegir una tecnología o la forma de hacer algo porque es tendencia o por una experiencia previa; ahora las decisiones se toman por su impacto en el producto:
- Implementar Feature Flags para permitir releases progresivos que reduzcan el riesgo del negocio.
- Estrategias de Local-First para eliminar la latencia y la frustración del usuario si la conexión falla.
Estos son algunos ejemplos que no son verdades universales, sino decisiones que se pueden llegar a tomar dentro de un contexto específico.
Entender el negocio te hace mejor ingeniero. Nos obliga a abrir nuestra mente y ampliar nuestro conocimiento a cosas como métricas de conversión o retención, ventas o soporte.
Para cerrar
El Product Engineer no es un recurso más que se encarga de cerrar tickets. Es un rol central que tiene la capacidad de entender las necesidades de negocio y convertirlas en realidad haciendo uso de su capacidad técnica.
En los siguientes artículos voy a profundizar sobre cuáles son las métricas que debemos mirar como ingenieros de producto y cómo comunicarse y negociar con los diferentes stakeholders sin morir en el intento.