Hace más de nueve años, en Ontruck ya buscábamos un perfil que entonces era una rara avis: el Product Engineer. Lo llamábamos así de forma formal, pero sabíamos lo que queríamos: un ingeniero que no solo programara bien, sino que entendiera por qué estaba programando eso y cómo podía aportar mas valor a los usuarios.
En aquel momento éramos muy incipientes. El sector no tenía claro si ese perfil tenía recorrido o si la carrera natural de un ingeniero siempre pasaría por especializarse en frontend, backend o mobile.
La IA lo ha resuelto. Cuando puedes implementar funcionalidad a una velocidad que hace unos años era impensable, el reto que queda en ingeniería no es principalmente técnico: es entender bien el problema, plantear una arquitectura sólida y decidir cómo fasear la entrega para aportar valor rápido sin romper lo que ya funciona.
Ese es el Product Engineer. Y todas las personas que tenemos en el equipo de Punto tienen ese perfil. Los ingenieros que vienen de Ontruck, lo traen de serie. Los que han entrado con otras experiencias, los hemos ido formando en esta cultura de producto.
Voy a ir publicando artículos con ejemplos concretos de comportamiento. No teoría. Ejemplos reales de lo que hacemos, para que lo veáis y os haga reflexionar. Y, por supuesto, si en algún momento queréis trabajar en Punto, que sepáis exactamente qué esperamos.
Empezamos hoy por cinco ejemplos.
1. Estar atento al feedback y saber qué es urgente (sin apagar fuegos constantemente)
Un Product Engineer tiene nervio operacional. No espera a que el Product Manager le diga qué es urgente: lo detecta, lo evalúa y actúa.
El ejemplo típico: alguien del equipo de operaciones está bloqueado porque hay un problema. El ingeniero lo resuelve directamente, desbloquea a quien necesita seguir trabajando, y crea una issue donde explica la causa raíz y propone cómo abordarlo bien cuando haya espacio para pensarlo.
Lo que parece sencillo tiene mucha miga. Hay dos errores frecuentes: el ingeniero que ni mira, que está en su tarea y pasa de lo que pasa a su alrededor. Y el ingeniero que es tan servicial que prioriza cualquier cosa que le llega, sin criterio.
El equilibrio es: desbloquea lo urgente, entiende el porqué, y decide con criterio si esto merece un hotfix y ya, o si hay que crear una issue para pensar mejor la solución. Si hacemos bien las cosas, debería haber pocas urgencias. Eso también es un indicador de salud del producto.
2. Validar con datos reales y definir un plan de pruebas exhaustivo
Cuando construyes funcionalidad nueva, no basta con que funcione el happy path. Un Product Engineer entiende los datos que hay en producción antes de lanzar, y define un plan de pruebas que cubre todos los casos que existen.
En Punto tenemos un caso especialmente delicado: la gestión de impuestos en trámites. Cada impuesto tiene su conjunto de normas. Según avanzamos con clientes con casuísticas distintas, el riesgo de dejar trámites con el cálculo de impuesto incorrecto es real.
Hace unos meses, en una iteración importante de esta funcionalidad, la ingeniera responsable preparó un plan de pruebas muy exhaustivo en base a las leyes de los distintos BOEs autonómicos: todas las combinaciones de impuesto posibles, asegurando que los tests las cubrieran correctamente, y validando que encajaban con los datos que teníamos en producción.
Hay algo importante aquí que va más allá de los tests. Es una cuestión de confianza. Cuando alguien del equipo dice "esto ya está", no debería haber ninguna duda. Si has validado los casos, si has mirado los datos, si los tests pasan y tú mismo lo has comprobado, no necesitas que nadie te lo revise. Esa confianza es lo que permite que un equipo despliegue nuevas funcionalidades varias veces por día.
3. Meterse en el barro y operar el servicio
Esto es contraintuitivo para la mayoría de ingenieros: en algunos trámites de Punto el que construye la funcionalidad también opera el servicio de cara a clientes mientras valida que las automatizaciones funcionan.
La lógica es sencilla. Si eres tú quien ha implementado algo y eres tú quien comprueba que funciona revisando casos reales, el aprendizaje es inmediato porque lo sufres en tus propias carnes. Ves exactamente dónde falla, qué casos no habías previsto, dónde los usuarios hacen cosas que no esperabas.
Hace unas semanas un ingeniero revisó más de 600 expedientes manualmente. Es trabajo de barro, muchas horas, poco glamour. Pero ese dogfooding —sufrir de primera mano lo que aspiramos a que funcione— es lo que permite iterar bien.
El equilibrio, claro, es no pasarse. Si el ingeniero está siempre operando nunca mejora el producto. Pero meterse en el barro puntualmente es sano. Muy sano. Si eres ingeniero y nunca has operado lo que construyes, algo estás perdiendo.
4. Entender el problema para proponer un faseado que aporte valor antes
Un Product Engineer que sabe cuál es el problema que está resolviendo puede proponer cómo fasearlo. Alguien que solo recibe un ticket no puede.
Ejemplo reciente: una funcionalidad de gestión de impuestos en lote. Teníamos diseños validados por nuestros clientes. El ingeniero, al entender exactamente cuáles eran los problemas y cuáles eran los retos técnicos de implementación, propuso un faseado distinto al que habíamos pensado inicialmente.
Primero: mostrar cierta información que ya ayudaba al equipo durante los días de más carga. Lo implementó en un día. Luego: la vista que habíamos diseñado. Por último: el resto de acciones de acciones en lote.
¿Por qué importa? Porque en el sector de automóción, la matriculación de vehículos se concentra a final de mes. Si llegamos al día 25 con algo que ya descarga al equipo administrativo, hemos ganado cinco días de alto volumen. Si llegamos el día 1 del mes siguiente, el impacto es mucho menor.
El ingeniero tiene el conocimiento técnico para jugar con los tiempos.
5. Hacer shadowing con los usuarios
El Product Engineer no solo habla con usuarios: va a verles. Observarles en su entorno, con su flujo real de trabajo, da información que ninguna entrevista ni ningún ticket te va a dar.
Nosotros lo hacemos con los clientes más cercanos: vamos a sus oficinas cada varios meses y pasamos un par de días con ellos. El efecto es enorme.
¿Por qué? Porque los usuarios tienen muy interiorizado su flujo de trabajo. Hay cosas que hacen de forma manual que les llevan horas y que se podrían automatizar, pero para ellos es tan natural que no lo mencionan como un problema. Solo te lo encuentras si estás allí mirando cómo trabajan.
Y también pasa lo contrario: hay cosas que duelen mucho y que te las cuentan en cualquier call, pero que en realidad tienen menos impacto del que parece. El shadowing te ayuda a calibrar. A empatizar de verdad. Y a volver con claridad sobre cuáles son los problemas que realmente importa resolver.
Iré publicando más ejemplos de este tipo. El objetivo no es dar una definición de Product Engineer si no que podais reconocer estos comportamientos, reflexionar sobre los vuestros, y entender qué cultura de product engineering estamos construyendo en Punto.
También puede interesarte
Iterando el prototipo en vivo mientras los usuarios lo prueban
Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.
Vuelvo a compartir aprendizajes con una verdad incómoda: si en tu equipo todavía destináis a dos o más ingenieros para d…
