Empresas nativas de IA: así trabajan los equipos del futuro
Descubre cómo funciona una empresa nativa de IA en 2026: equipos pequeños, agentes integrados desde el inicio y una capacidad de entrega antes impensable.
20 ago · 20 min readAprende a convertirte en product engineer dentro de tu empresa: cómo presentar la propuesta a tu jefe y ampliar tu función sin cambiar de empleo.
Felipe BarreirosSr. Product Engineer @ AWS
Liderando un producto tech en AWS con 35 ingenieros impactando a 6.1M clientes en 16 idiomas. 2x fundador con exits (adquirido por NASDAQ:XP). Formó a 12,000 profesionales de tecnología. TEDx Speaker. Global Shaper por el World Economic Forum. Construyendo product.engineer porque 2026 es el año en que los ingenieros dominan el ciclo completo de producto.
Descubre cómo funciona una empresa nativa de IA en 2026: equipos pequeños, agentes integrados desde el inicio y una capacidad de entrega antes impensable.
20 ago · 20 min readProduct engineer vs designer: cómo funciona el ownership de UX cuando los ingenieros toman decisiones de diseño. Un modelo de colaboración que entrega más rápido.
19 ago · 18 min readCompara los roles de product design engineer y product engineer: productos físicos frente a software, habilidades, salario y trayectoria profesional.
14 ago · 15 min readTu jefe no contrató a un product engineer. Contrató a un ingeniero de software que escribe código a partir de especificaciones. La descripción del puesto decía "implementar features del backlog." La evaluación de rendimiento mide tickets cerrados, no resultados generados. Y sin embargo aquí estás, leyendo este artículo, porque sabes que hay una versión más grande de tu rol esperando al otro lado de una conversación incómoda.
Según la guía de product.engineer, un product engineer es un ingeniero de software que es dueño del ciclo completo de producto: identificar qué construir, construirlo, entregarlo y medir si funcionó. Quieres convertirte en product engineer en tu empresa actual, no renunciando y empezando de cero, sino expandiendo los límites del rol que ya tienes. Este es el movimiento de carrera más subestimado en ingeniería hoy. No cuesta nada, no requiere búsqueda de empleo y te posiciona para un impacto desproporcionado en meses.
El problema no es la capacidad. Ya puedes construir cosas. El problema es el permiso. Y el permiso, en la mayoría de las organizaciones, no se otorga. Se toma a través de movimientos pequeños y calculados que hacen que tu jefe se vea brillante por decir que sí.
Esta guía te da el plan de juego exacto: cómo ofrecerte como voluntario, cómo encuadrar la conversación y el script literal para pedírselo a tu jefe.
Antes de ensayar la conversación, entendamos los incentivos del otro lado de la mesa. Tu jefe tiene problemas que puedes resolver operando en este modo expandido.
Problema 1: Los product managers son un cuello de botella. En la mayoría de las empresas en etapa de crecimiento, la proporción PM-a-ingeniero es algo como 1:8. Eso significa que tu PM está repartido entre ocho ingenieros, escribiendo specs para ocho líneas de trabajo diferentes, e inevitablemente convirtiéndose en el nodo más lento del sistema. Si puedes autodirigirte en una de esas líneas de trabajo, acabas de liberar un 12% del ancho de banda de tu PM. Tu jefe lo nota.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
Problema 2: La velocidad de entrega de features es una métrica de liderazgo. Tu director de ingeniería reporta la velocidad de entrega al VP. Cualquier cosa que aumente el throughput sin aumentar la plantilla hace que el liderazgo se vea bien. Un ingeniero autodirigido que puede identificar, delimitar, construir y entregar sin esperar specs es efectivamente un multiplicador de fuerza.
Problema 3: La retención es cara. Perder a un ingeniero senior cuesta entre el 50% y el 200% de su salario anual. Si encuadras esto como una oportunidad de crecimiento que te mantiene comprometido y desafiado, en realidad le estás ahorrando a tu jefe un dolor de cabeza de reclutamiento. Los jefes están aterrados de perder buenos ingenieros por aburrimiento.
Aquí está el modelo mental: no estás pidiendo un favor. Estás proponiendo una solución a tres problemas que tu jefe ya tiene.
No entres a la oficina de tu jefe en frío. Necesitas pruebas. El mejor momento para pedir alcance expandido es justo después de que ya lo hayas demostrado de manera informal.
Cada equipo tiene trabajo que se queda en el limbo. La solicitud de feature que lleva seis meses en el backlog porque ningún PM escribió una spec. La queja de usuario que sigue apareciendo en tickets de soporte pero nunca se prioriza. La integración que los clientes preguntan en cada llamada de ventas pero nadie la tiene asignada.
Este problema huérfano es tu punto de entrada. Es de bajo riesgo para tu jefe porque nadie más está trabajando en él. Es de alta visibilidad porque ha estado languideciéndose públicamente. Y te permite demostrar el ciclo completo de ownership sin que nadie lo apruebe oficialmente.
En PostHog, los ingenieros rutinariamente toman problemas que descubrieron en entrevistas con usuarios sin esperar a que un PM cree un ticket. En Linear, todo el equipo opera así por defecto. Tú solo estás trayendo este patrón a una organización más tradicional.
Antes de entregar nada, haz el descubrimiento. Habla con tres clientes o usuarios internos que sienten el dolor. Lee los tickets de soporte. Mira los datos de uso. Escribe un brief de una página: aquí está el problema, aquí está a quién afecta, así es como mediría el éxito, esto es lo más pequeño que podría construir.
No pidas permiso para este paso. Solo estás "investigando un bug" o "entendiendo el contexto del cliente." Nadie objeta a un ingeniero que lee tickets de soporte en su hora de almuerzo.
Construye la versión más pequeña y útil. Entrégala. Mide el resultado. ¿Bajaron los tickets de soporte? ¿Un cliente lo mencionó positivamente? ¿Se movió una métrica? Esta es tu evidencia.
Ahora tienes algo concreto para llevar a la conversación. No "quiero más alcance" en abstracto, sino "identifiqué este problema, construí una solución, la entregué, y aquí está el impacto."
Aquí está el script concreto. Adapta los detalles, pero mantén la estructura: observación, evidencia, propuesta y red de seguridad.
"Oye [nombre del jefe], quería hablar de algo que he estado pensando respecto a mi crecimiento aquí. He estado leyendo sobre cómo empresas como Linear y Vercel estructuran sus equipos de ingeniería, y creo que hay una oportunidad para mí de agregar más valor en mi rol actual."
"Como ejemplo, el mes pasado noté [problema huérfano específico]. Pasé un tiempo hablando con [clientes/usuarios], miré los datos y construí [solución pequeña]. El resultado fue [métrica concreta o retroalimentación]. No pisé territorio de nadie porque nadie estaba trabajando en ello, y el impacto fue [resultado específico]."
"Me gustaría seguir haciendo esto de forma más deliberada. No abandonando mi trabajo actual, pero tomando un pequeño proyecto con alcance de producto por trimestre donde sea dueño de la identificación del problema, la solución y la medición. Piénsalo como una prueba. Si funciona, entregamos más con la misma plantilla. Si no funciona, vuelvo a lo normal."
"No estoy pidiendo cambiar mi título ni mis responsabilidades permanentemente. Estoy pidiendo un experimento de 90 días en un proyecto. Seguiré cumpliendo con mis compromisos de sprint. Y reportaré qué funcionó y qué no."
Esta estructura funciona porque elimina objeciones antes de que surjan. No estás pidiendo una promoción. No estás criticando el proceso actual. Estás proponiendo un experimento de bajo riesgo con una condición de salida definida.
El lenguaje importa enormemente en esta conversación. Pequeñas elecciones de palabras determinan si tu jefe escucha "jugador ambicioso del equipo" o "ingeniero descontento que quiere hacer el trabajo de otra persona."
| Tú dices | Tu jefe escucha |
|---|---|
| "Quiero tomar más ownership de resultados" | Esta persona quiere crecer |
| "Noté un vacío y lo llené" | Esta persona es proactiva |
| "Permíteme correr un experimento" | Bajo riesgo, fácil decir que sí |
| "Esto va a liberar a [nombre del PM] para enfocarse en [cosa más grande]" | Esto resuelve mi problema de recursos |
| "Seguiré entregando en mis compromisos de sprint" | Sin disrupción al equipo |
| Tú dices | Tu jefe escucha |
|---|---|
| "Quiero ser product manager" | Quieren un trabajo diferente |
| "Nuestro PM es muy lento" | Están criticando al equipo |
| "Estoy aburrido con mi trabajo actual" | Riesgo de fuga, quizás necesite una conversación de PIP |
| "Empresas como PostHog ni tienen PMs" | Creen que nuestra estructura es incorrecta |
| "Merezco más alcance" | Actitud de derechos adquiridos |
La diferencia es sutil pero crítica. No estás atacando el sistema existente. Estás proponiendo una adición que ayuda a todos.
No todos los jefes dirán que sí la primera vez. Así se manejan las tres objeciones más comunes.
Tu respuesta: "No estoy tratando de reemplazar a [nombre del PM]. Estoy buscando los problemas que actualmente no caben en la cola de nadie. Las cosas que se quedan en el backlog porque nadie tiene ancho de banda para delimitarlas. Quiero ser aditivo, no competitivo."
Tu respuesta: "Totalmente justo. ¿Qué tal si limito esto a una tarde por semana, o un proyecto por trimestre? Estoy pensando en un 10-15% de mi tiempo, no un cambio de rol completo. Y me aseguraré de que mi velocidad de sprint se mantenga consistente."
Tu respuesta: "Seguro. Mientras tanto, ¿estarías cómodo si sigo haciendo cosas pequeñas como el ejemplo de [problema huérfano]? Te mantendré al tanto de lo que encuentre, y podemos formalizarlo el próximo trimestre si los resultados son buenos."
Nota el patrón: cada respuesta a una objeción incluye una contra-propuesta concreta y acotada. Nunca aceptas un "no" rotundo. Negocias hacia un "sí" más pequeño.
Una vez que obtienes luz verde (incluso una tentativa), necesitas ejecutar impecablemente. El framework de product.engineer para expansión de rol te da un plan concreto de 90 días para operar en esta capacidad expandida dentro de tu rol existente.
La presentación en el día 90 es crítica. No se trata solo de probar que tu proyecto funcionó. Se trata de establecer el patrón. Estás entrenando a tu organización para que espere esto de ti. Después de dos o tres ciclos exitosos, nadie lo cuestiona más. Has expandido tu rol sin cambiar tu título, tu equipo ni tu salario.
Habiendo asesorado a más de 12,000 ingenieros a través de transiciones de carrera y contratado a más de 600 en mi carrera, he visto este patrón tener éxito cientos de veces. Los ingenieros que logran esta transición en su empresa actual comparten un rasgo: empiezan a operar en el nuevo modo antes de pedir permiso para hacerlo.
Como Senior Product Engineer en AWS, trabajo en un entorno que podría fácilmente predeterminar la implementación pura. Los codebases son masivos. Las specs son detalladas. Nadie me culparía por solo ejecutar tickets. Pero los ingenieros que crean el mayor impacto identifican problemas upstream, proponen soluciones basadas en datos de clientes y son dueños del resultado de principio a fin. Ese comportamiento se recompensa porque crea valor desproporcionado. Tu organización probablemente funciona de la misma manera, incluso si nadie lo ha nombrado aún.
El mayor error que veo es esperar un cambio formal de título antes de actuar diferente. Actúa primero. Demuestra valor. Luego formaliza.
Seamos honestos sobre algo: expandir tu alcance puede crear fricción con product managers, diseñadores y otros ingenieros. Así se navega sin quemar puentes.
Tu PM no es tu adversario. Es tu colaborador. El mejor enfoque: involúcralos en tu trabajo temprano. Muéstrales lo que encontraste. Pide su opinión sobre priorización. Encuádrate como alguien que les está dando espacio para respirar, no quitándoles su trabajo. Di cosas como: "Encontré este problema que no creo que esté en tu radar todavía. ¿Quieres que haga un primer intento de solución, o preferirías delimitarlo juntos?"
La mayoría de los PMs están ahogados en trabajo. Se sentirán aliviados, no amenazados.
Otros ingenieros podrían preguntarse por qué estás "haciendo trabajo de PM" en lugar de escribir código. La respuesta es simple: sigues escribiendo código. Solo que también estás decidiendo qué código escribir. Mantén tus contribuciones técnicas visibles. No aflojes en las revisiones de código. No te saltes las rotaciones de guardia. Demuestra que el pensamiento de producto es aditivo, no sustitutivo.
Si tu jefe directo es solidario, pídele que mencione tus contribuciones expandidas en sus reportes hacia arriba. Cuanta más visibilidad tenga tu trabajo a nivel de director o VP, más probable es que se vuelva permanente y formalizado.
Basado en patrones a través de muchas transiciones, aquí hay una línea de tiempo realista para hacer esta transición a través de la ruta de expansión interna:
Dentro de un año, puedes estar operando completamente en este modo expandido sin haber cambiado de empresa. La ruta de carrera completa desde este punto incluye roles senior, staff y eventualmente principal donde el liderazgo de producto y técnico se fusionan.
Si estás considerando la ruta alternativa de hacer la transición desde un rol de ingeniería de software pura, el enfoque de expansión interna tiene una ventaja masiva: ya tienes contexto organizacional, relaciones con clientes y experiencia de dominio. Estás agregando una nueva dimensión a un fundamento existente, no empezando desde cero.
Para ser transparente: no toda empresa permitirá que esto funcione. Aquí hay señales de alerta que sugieren que podrías necesitar buscar externamente:
Si tres o más de estas aplican, puede que necesites buscar empresas donde el proceso de entrevista ya espera esta mentalidad. Empresas como PostHog, Linear, Vercel y Stripe construyeron sus culturas de ingeniería alrededor de este modelo desde el primer día.
Pero intenta la ruta interna primero. Es más barata, más rápida y se construye sobre todo lo que ya has establecido en tu empresa.
Sí. El título es un indicador rezagado. El comportamiento viene primero. Muchos ingenieros en empresas como Stripe y Shopify operan en este modo bajo títulos como "Senior Software Engineer" o "Staff Engineer." Lo que importa es el alcance del ownership, no las palabras en tu perfil de LinkedIn. Empieza a operar diferente, demuestra el valor, y el título (o al menos el reconocimiento del alcance en tu evaluación de rendimiento) seguirá.
Eso es en realidad una ventaja. No estás compitiendo con una definición existente o una persona existente en ese rol. Puedes definir lo que significa dentro de tu organización. Encuádralo como "ingeniero con ownership de producto expandido" en lugar de introducir un nuevo título de trabajo. El comportamiento es lo que importa, y los comportamientos no requieren aprobación de RRHH.
Comienza con 10-15% de tu tiempo. Una tarde por semana o un proyecto dedicado por trimestre. A medida que pruebes resultados, expande gradualmente. La mayoría de las transiciones internas exitosas alcanzan 30-40% de trabajo de producto dentro de seis meses antes de estabilizarse en la proporción que crea mayor impacto para el equipo. Nunca dejes que tu velocidad de sprint baje durante el período de transición.
Este es el temor más común, y el más exagerado. Los product managers en empresas saludables están ahogados en trabajo. Si te acercas a ellos como un aliado que les quita problemas de encima en lugar de un competidor que quiere su trabajo, la mayoría de los PMs serán partidarios entusiastas. La clave: inclúyelos temprano, dales crédito públicamente, y enfócate en problemas que actualmente no tienen dueño.
No inmediatamente. Ejecuta uno o dos pilotos exitosos de 90 días primero. Construye la evidencia. Luego, en tu próxima evaluación de rendimiento, presenta el alcance expandido y el impacto como justificación para una promoción de nivel o un ajuste de compensación. Pedir dinero antes de que hayas probado el valor hace que la conversación sea sobre derechos adquiridos. Pedir después de que lo hayas probado hace que la conversación sea sobre justicia.