El ingeniero de producto (The Product Engineer)

 (nandinfinitum.com)
71 puntos por GN⁺ 2025-09-01 | 8 comentarios | Compartir por WhatsApp
  • La ingeniería de software en su sentido tradicional está llegando a su fin, y está surgiendo el paradigma de la ingeniería de producto basado en IA
  • El ingeniero de producto es un rol híbrido entre product manager y desarrollador full-stack, un builder autónomo y orientado a resultados que se responsabiliza de todo el ciclo, desde la planificación hasta el despliegue
  • Con base en un enfoque AI-native, capacidades en T y mentalidad centrada en KPI, estos perfiles se organizan no por equipos sino por funciones (features), asumiendo responsabilidad end-to-end sobre onboarding, pagos, notificaciones, etc.
  • En la etapa de producto realizan ideación, análisis de mercado, investigación de usuarios y diseño de producto; en la etapa de ingeniería se encargan de arquitectura, diseño de sistemas, desarrollo frontend y backend
  • La IA es una herramienta especialmente poderosa en áreas definibles y determinísticas (D&D), y es muy probable que las organizaciones evolucionen del triángulo tradicional PM-diseñador-ingeniero hacia una estructura de colaboración entre ingenieros de producto e IA

Background

  • La ingeniería de software tradicional ya no es válida
    • La publicación del lenguaje C por Dennis Ritchie en 1972 fue el último cambio de paradigma realmente fundamental
    • Desde entonces, los avances no han sido más que optimizaciones y abstracciones para facilitar la escritura y transformación de código máquina
    • Durante mucho tiempo, la productividad se midió por la eficiencia temporal y espacial del código, su longitud y su legibilidad
  • Ahora estamos entrando en un paradigma completamente nuevo, y es poco probable que volvamos a la era pasada del “raw coding”
  • John Carmack comentó recientemente que las mejores herramientas para construir en el futuro pasarán del código escrito a mano a la guía de IA
    • Por eso, para los ingenieros se vuelve importante desarrollar “product skills” y aprovechar las mejores herramientas
  • La ingeniería de software evolucionará gradualmente hacia la ingeniería de producto (Product Engineering)

¿Qué es un ingeniero de producto (Product Engineer, PE)?

  • Un rol que combina al Product Manager con el ingeniero de software full-stack
  • Un perfil responsable de todo el ciclo de vida del producto y directamente vinculado al éxito o fracaso del mismo
  • Características principales de un ingeniero de producto:
    • AI-native: usa los LLM no como complemento, sino como herramienta central
    • Capacidades en T: posee profundidad técnica en ingeniería y, al mismo tiempo, una comprensión amplia de producto, datos y diseño
    • Orientación a resultados: se hace responsable de KPI como retención, conversión y activación
    • Capacidad de ejecución autónoma: puede llevar una idea → documento de planificación → diseño → despliegue con supervisión mínima
  • Cambios en la estructura del equipo
    • Los ingenieros de producto forman lean teams pequeños pero altamente especializados
    • En lugar de separar frontend/backend/infraestructura, la organización gira en torno a feature squads centrados en producto o funcionalidad
    • La alineación ya no se hace por stack, sino por outcomes
    • Ejemplo: una persona se encarga del onboarding, otra de pagos y otra de notificaciones
    • Cada una asume la responsabilidad end-to-end de toda la funcionalidad, desde UX hasta la capa de datos
    • Es decir, la estructura pasa de “equipos de frontend/backend/infraestructura” a “squads independientes por funcionalidad”
  • El ingeniero de producto tiene dos dimensiones:
    • Dimensión de producto (pre-development)
    • Dimensión de ingeniería (desarrollo y etapas posteriores, in/post-development)

The Product

  • La dimensión de producto del ingeniero de producto se superpone con el trabajo tradicional del Product Manager y se encarga de la planificación y dirección del producto
  • Product Ideation (ideación de producto)
    • Es el proceso de definir y concretar las funciones centrales del producto, su propuesta de valor (Value Proposition) y el grupo objetivo de usuarios
    • Establece con claridad por qué existe el producto y quién es su cliente objetivo, sentando la base para el desarrollo posterior
  • Mind-mapping
    • Consiste en diagramar y visualizar las ideas o tareas derivadas de un concepto central para entender el panorama general
    • Se utiliza como herramienta para compartir y desarrollar ideas dentro del equipo
  • Brainstorming
    • Es el proceso de registrar ideas individualmente y luego compartirlas con otras personas para mejorarlas, complementarlas y validarlas
    • A través de la colaboración se amplifica la diversidad y creatividad de las ideas
  • Discovery
    • Es el proceso de explorar las necesidades de los clientes e investigar oportunidades de mercado para encontrar un producto que alinee los objetivos del negocio con el valor para el usuario
    • Incluye entrevistas con usuarios, análisis de competidores e investigación de mercado
  • Selection (priorización)
    • Consiste en decidir qué funciones o proyectos abordar primero con base en la dirección estratégica, los objetivos del negocio, las necesidades del cliente y las tendencias del mercado
    • Busca la opción de ejecución más efectiva dentro de recursos limitados
  • Market Analysis (análisis de mercado)
    • Analiza el entorno de mercado en el que se ubicará el producto, así como la competencia, el tamaño del mercado y las oportunidades y amenazas
    • Se utiliza para definir el posicionamiento del producto y la estrategia de crecimiento
  • User Research (investigación de usuarios)
    • Es el proceso de comprender en profundidad el comportamiento, las necesidades y los puntos de dolor de los usuarios
    • Aporta la base para mejorar la experiencia del usuario con datos
  • Product Design (diseño de producto)
    • Incluye diseño UI/UX, diseño de servicios, diseño de interacción y pruebas con usuarios
    • A través de prototipos y pruebas iterativas, garantiza una experiencia amigable para el usuario
  • Aunque estas funciones tradicionalmente las realizaba el Product Manager, el ingeniero de producto las ejecuta con mayor agilidad usando herramientas de IA
    • La IA tiene limitaciones para generar ideas realmente nuevas, pero es muy potente para revisar patrones existentes o complementar ideas repetitivas
    • Lo importante es que la visión del producto debe estar liderada por personas, y la IA debe usarse como soundboard para refinar y corregir ideas

The Engineer

  • La dimensión de ingeniería del ingeniero de producto es la etapa en la que las especificaciones planificadas se ejecutan e implementan en la práctica
  • Incluye cuatro áreas principales:
    • Arquitectura de software: decisiones estructurales
    • Diseño de sistemas: definición y concreción del sistema
    • Desarrollo frontend: implementación del diseño visual y la interfaz de usuario
    • Desarrollo backend: optimización de lógica de negocio y diseño de base de datos
  • Por supuesto, también son importantes otros temas de ingeniería como testing, monitoreo e integración de IA, pero en la mayoría de los proyectos la prioridad es construir y desplegar rápidamente un producto SLC (Simple, Lovable, Complete)
  • Los LLM para programación muestran una fortaleza particular en entornos definibles y determinísticos (D&D), por lo que el aporte de la IA es mayor en la dimensión de ingeniería

  • Planning

    • La etapa clave para usar IA de forma efectiva es la planificación
    • Si se le entrega a la IA la intención del proyecto como requisitos bien estructurados, la calidad del código mejora mucho a largo plazo
    • Al definir Rules (conjunto de reglas), el AI coder puede consultar de forma continua directrices a nivel sistema
      • Ejemplo: reglas de actualización de documentación, registro de cambios de arquitectura, estilo de código, criterios de pruebas
    • Ejemplo de estructura de reglas:
      • Sincronización de documentos en /docs, así como README y CHANGELOG
      • Redacción de ADR (Architecture Decision Record) cuando haya cambios importantes en dependencias o arquitectura
      • Generación de clientes API con OpenAPI Generator y uso de plantillas TypeScript axios
      • Acceso a datos con patrón repository y estandarización del manejo de errores
      • Definición clara de criterios para pruebas unitarias, de integración y E2E
    • En la mayoría de los IDE esto puede generarse automáticamente con /Generate Cursor Rules

  • Software Architecture

    • La arquitectura son decisiones que forman el esqueleto de la base de código y como su costo de cambio es alto, hay que ser cuidadoso desde etapas tempranas
    • Aspectos a considerar:
      • Monolito vs microservicios, serverless vs contenedores
      • Gestión de dependencias y definición de límites de integración
      • Modularización y separación de responsabilidades
      • Protocolos de comunicación como REST, GraphQL, gRPC o event bus
      • Estrategias de escalabilidad (como escalado horizontal)
    • Rol de la IA:
      • Comparar ventajas y desventajas de patrones alternativos de arquitectura
      • Generar diagramas con Mermaid.js
      • Redactar borradores de ADR
      • Pero la decisión final requiere criterio humano y expertise de dominio

  • System Design

    • El diseño de sistemas es el proceso de concretar la arquitectura en servicios reales, flujos de datos, máquinas de estado e interfaces
    • Tareas principales:
      • Definir APIs y límites de servicio
      • Modelar datos y diseñar el flujo de datos entre capas
      • Estrategias de manejo de errores y recuperación ante fallos
      • Modelado de transiciones de estado y flujos de trabajo asíncronos
      • Redacción de documentos de diseño y revisión de casos límite
    • Posibilidades de uso de IA:
      • Generar borradores iniciales de diseño
      • Simular problemas de concurrencia y casos límite
      • Redactar interfaces API, esquemas y máquinas de estado
      • Comparar patrones de diseño y dar retroalimentación
      • Ayudar a validar diseños como si fuera un “ingeniero junior”

  • Frontend Engineering

    • El frontend se encarga de la implementación del diseño visual y de la funcionalidad del cliente
    • La IA muestra muy buen desempeño en el ecosistema JS, especialmente con frameworks ampliamente usados como React
    • Tips para mejorar el rendimiento de la IA:
      • Proporcionarle lineamientos de marca (fuentes, colores, espaciado, reglas responsive) en forma de capturas o documentos
      • Generar código UI consistente mediante Tailwind config, variables CSS, etc.
    • También se puede probar la conversión de código mediante herramientas Figma-to-code (como Tempo)
    • Si se le da a la IA la definición de componentes repetitivos y reglas responsive, resulta más fácil producir una UI consistente con la marca

  • Backend Engineering

    • El backend se encarga de la implementación de la lógica de negocio, diseño de base de datos, construcción y optimización de APIs
    • La IA es especialmente efectiva en tareas definibles y determinísticas (D&D)
    • Técnicas efectivas:
      • Importación de documentos: cargar directamente en el IDE especificaciones de API y documentación técnica para que la IA las consulte y reducir alucinaciones
      • Uso de workspace: en proyectos con frontend y backend separados, integrar las carpetas para aportar contexto y ayudar a la IA a entender mejor la estructura general del proyecto

General Tips for the Product Engineer

  • Always work at the frontier

    • Es importante usar siempre los modelos más recientes
    • Los modelos más nuevos pueden comprender proyectos más grandes gracias al aumento del tamaño de la ventana de contexto
    • También mejoran en capacidad de razonamiento, reducción de alucinaciones y mayor estabilidad

  • Use thinking mode

    • Activar Thinking mode mejora mucho la calidad de las respuestas del modelo
    • Si existe la opción, debería activarse siempre
    • Si no está disponible, se puede lograr un efecto similar incluyendo la palabra “ultrathink” en el prompt

  • Be hyper-specific

    • Al pedirle algo a la IA, hay que escribir de forma específica y clara
    • Siempre se deben incluir objetivo, restricciones, decisiones de diseño, snippets de código relevantes, rutas de archivos y nombres de componentes
    • Ejemplo de buen prompt:
      • Agregar tracking analítico al formulario de /src/pages/SignUp.tsx
      • Cuando el usuario haga clic en ‘Submit’, enviar el evento sign_up_started mediante la función trackEvent()
      • El evento debe tener debounce
      • Incluir como propiedad el dominio del correo del usuario (por ejemplo, gmail.com)

  • Provide visual context

    • En tareas de frontend es especialmente importante proveer contexto visual
    • Como los LLM para programación pueden entender imágenes, adjuntar capturas de diseño o capturas de mensajes de error causados por bugs ayuda a que la IA resuelva el problema más rápido

  • Work in small iterations

    • En lugar de pedirle a la IA una tarea grande de una sola vez, conviene dividirla en partes pequeñas e iterar
    • Es efectivo implementar primero la funcionalidad básica e ir mejorándola gradualmente
    • Lo ideal es dividir el prompt en varias instrucciones claramente definidas

  • Stay curious

    • En internet existen innumerables tips y casos de prompt engineering
    • Participar en comunidades o redes relacionadas permite conocer las técnicas más recientes y aprender rápidamente buenas prácticas de uso

Closing thoughts

  • A pesar de la revolución de la IA, hay capacidades que no serán reemplazadas en el futuro cercano o que incluso ganarán más valor
  • Dominio de herramientas CLI (por ejemplo, git)
    • Git es la herramienta más eficiente para gestionar versiones de código y rastrear cambios
    • Como la confiabilidad del código generado por IA es baja, es indispensable poder volver a un estado anterior o empezar de nuevo
    • Por eso, la capacidad de usar herramientas CLI como Git será cada vez más importante
  • Fundamentos de ingeniería
    • Capacidad para gestionar technical debt y mantener la modularización y encapsulación del código
    • La IA puede no garantizar consistencia en el estilo de código (convenciones de nombres, principio DRY, modularidad)
    • Por eso, la capacidad del ingeniero para mantener directamente los principios básicos tendrá aún más valor
    • Aun así, a largo plazo esto podría cambiar a medida que la IA escriba cada vez más código
  • Habilidades sólidas de comunicación
    • La capacidad de redactar documentos, prompts y especificaciones claras y estructuradas tiene un efecto multiplicador
    • La IA no infiere intenciones como un humano, sino que solo ejecuta lo que se le indica, por lo que la claridad es esencial
    • Buenas especificaciones, prompts bien definidos y documentación sistemática mejoran la productividad y la calidad de los resultados
  • Cambio de poder dentro de las organizaciones
    • Las tareas técnicas serán asumidas gradualmente por la IA, ya que encajan con su naturaleza D&D (Definable & Deterministic)
    • A medida que la ejecución se vuelva más barata y generalizada, ganará más valor la capacidad de gestionar la IA y empaquetar resultados para comunicarlos a ejecutivos y accionistas
    • En las grandes empresas, el proceso real de ejecución no se ve y solo se entregan los resultados, por lo que la comunicación estratégica y la presentación de resultados influirán en el poder
    • Es probable que los managers que alinean y transmiten estos resultados terminen teniendo más poder que quienes implementan directamente la tecnología
  • Perspectiva de cambio en la estructura organizacional
    • Cuanto más nueva sea la empresa (startup), más rápido se reflejará el rol del ingeniero de producto
    • A medida que la IA gane más autonomía durante el crecimiento, la estructura tradicional del triángulo PM–diseñador–ingeniero podría debilitarse
    • En su lugar, podría surgir una nueva topología de equipo compuesta por pods pequeños liderados por ingenieros de producto con sensibilidad de producto y copilotos de IA que apoyen todo el stack

References

Lecturas relacionadas

8 comentarios

 
devstudyman7 2025-09-10

La generación eficiente con plantillas no necesita tokens.
Los puntos débiles del vibe coding definitivamente existen. Da la impresión de que, aunque los tokens estén baratos por esa guerra de desgaste, también quedan claros los límites del prompting en vibe coding. En el artículo lo llaman el fin, pero personalmente no lo creo. No todo el mundo puede convertirse en experto en prompting. También creo que el propio vibe coding será reemplazado.
 
karthus321 2025-09-09

En el caso de las grandes empresas, hay que hacer nuevo desarrollo sobre legacy code escrito durante años, y no sé cómo PM/PO ocupados con la comunicación y la alineación de incentivos podrían cubrir incluso el desarrollo solo con vibecoding. Creo que en una empresa pequeña sí sería posible.
 
mixed 2025-09-02

Pensándolo un poco, si funcionara así como aquí, también da la impresión de que esto es algo para lo que realmente hace falta una persona.
Da la sensación de que quizá un Product Engineer con IA podría hacerlo.
 
feel5ny 2025-09-02

¿Qué será más rápido: que un PO aprenda desarrollo o que un desarrollador aprenda el rol de PO?
 
kwon5604 2025-09-02

Es difícil generalizar, pero en general, muchas personas en roles de PO, PM y diseño parecían tener la perspectiva de que los avances de la IA han abierto más oportunidades para quienes trabajan como PO y PM.

En cambio, muchos desarrolladores parecían esperar que, gracias a los avances de la IA, puedan desarrollar productos mejor por su cuenta, sin necesidad de PO, PM ni diseñadores.

Habrá que ver cómo evoluciona esto en adelante jaja
 
jmonaco 2025-09-01

Muy buen contenido y me identifico bastante con él.
He estado construyendo mi carrera con este enfoque desde hace 2 años y, como el alcance de lo que se puede implementar está limitado según el tamaño de la organización, he pasado por algunos ensayos y errores personales. Hasta ahora, los resultados han sido muy buenos.
 
tested 2025-09-01

Parece un rol en el que el PM/PO también se encarga del desarrollo usando vibe coding.
 
howudoin 2025-09-01

Es un punto muy importante. Pero en un entorno real es muy difícil. Por lo que se percibe, en cualquier organización a la que vayas siempre hay una cierta proporción de personas que quieren trabajar movidas por la obsesión por la calidad. En la práctica, el PE también incluye gestión de personas. Es decir, no solo depende de la capacidad individual, sino que también está fuertemente influido por la capacidad de la organización para gestionar su cultura corporativa.