Un ingeniero de producto (product engineer, en inglés) es la persona que se hace responsable de que tu producto digital funcione y resuelva lo que tu negocio necesita, no solo de que el código que le pediste quede escrito. Decide qué debe hacer la primera versión y qué se deja para después, la construye, la publica y la mantiene funcionando. Un programador, en el sentido más común de la palabra, recibe una tarea definida por otro y la ejecuta bien. Los dos roles son legítimos y los dos escriben código; la diferencia está en quién toma las decisiones y quién responde por el resultado. Escribo esto porque es lo que más me preguntan los founders antes de contratar, y porque elegir mal el rol sale más caro que elegir mal la tecnología.
TL;DR
- Un programador ejecuta tareas que otro definió. Un ingeniero de producto define qué se construye, lo construye, lo publica y responde por el resultado.
- Si en tu empresa nadie decide qué va en la primera versión y qué no, ese trabajo lo terminarás haciendo tú, sin experiencia, o no lo hará nadie. Ahí es donde un ingeniero de producto paga.
- Si ya tienes un CTO o un líder técnico que decide, lo que necesitas es un buen programador. Contratar de más también es un error.
Qué hace un ingeniero de producto
La forma más corta de explicarlo: un ingeniero de producto responde por el producto, no por los tickets. Cuando un cliente me entrega su app móvil, su sitio o plataforma web, o su chatbot con IA, lo que recibe a cambio es una sola persona responsable de que eso exista, funcione y siga funcionando. Eso incluye cosas que normalmente se reparten entre cuatro perfiles: entender el negocio, definir el alcance, diseñar cómo se resuelve, escribir el código, publicarlo y mirar qué pasa después.
Lo que define el rol no es la lista de tareas, sino dónde empieza y dónde termina la responsabilidad. Empieza antes de que exista una tarea, en la conversación donde se decide qué vale la pena construir. Y termina después de que el código está escrito, cuando el producto lleva meses en manos de usuarios reales y hay que decidir qué se arregla, qué se mide y qué viene después.
En mi caso trabajo así desde 2019, como contratista independiente, para founders y equipos que no tienen un líder técnico en casa. Antes trabajé dentro de equipos con la estructura tradicional, y esa experiencia es justamente lo que me hace valorar el rol de programador cuando la estructura existe.
Qué hace un programador, y por qué no es una crítica
Un programador recibe una especificación, una tarea o un diseño, y lo convierte en software que funciona. Es un trabajo difícil y hay programadores excelentes que no quieren ni deberían tener que decidir qué se construye. En un equipo con un product manager, un diseñador y un líder técnico, ese reparto es correcto: cada uno decide en su terreno y el programador puede concentrarse en hacer bien la parte más técnica.
El problema aparece cuando contratas a un programador y no tienes a nadie que haga el resto. Las decisiones no desaparecen; alguien las toma igual. Si no hay quien las tome con criterio, pasan una de dos cosas:
- Las tomas tú, que conoces tu negocio pero no sabes qué es caro de construir, qué es frágil o qué va a doler dentro de seis meses.
- Las toma el programador de forma implícita, tarea por tarea, sin ver el conjunto y sin que nadie le haya pedido que lo vea.
Ninguna de las dos es culpa del programador. Le pediste que ejecutara y ejecutó. El hueco estaba en el rol que nadie ocupó.
La diferencia en una tabla
| Programador | Ingeniero de producto | |
|---|---|---|
| Qué recibe | Una tarea definida por otro | Un problema del negocio |
| Qué entrega | Código que cumple la tarea | Un producto publicado y en uso |
| Quién decide el alcance | Alguien más | Él, contigo |
| Qué pasa si la tarea estaba mal planteada | La hace igual, o pregunta | La cuestiona antes de empezar |
| Qué pasa cuando algo falla en producción | Depende de quién lo detecte | Es su responsabilidad detectarlo |
| Cómo se mide su trabajo | Tareas completadas | Resultados del producto |
| Quién habla contigo | A menudo un intermediario | La misma persona que escribe el código |
La fila que más importa es la tercera. Definir el alcance de la primera versión es donde se gana o se pierde el dinero de un proyecto, y es precisamente la parte que un programador, por definición del rol, no hace.
Sigue leyendo
Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:
Lee el artículo completo en ramonchancay.me →
Publicado originalmente en www.ramonchancay.me/es/blog/que-es-un-ingeniero-de-producto.
Top comments (0)