La era del ingeniero de producto. Mejores prácticas e ideas

Crear software no es una tarea fácil. Cada año, se crean innumerables herramientas, marcos, funciones y tecnologías. Los medios cambian, el «cómo» cambia. Pero hay una cosa que nunca cambia: se crea software para las personas, productos digitales con los que los usuarios interactúan.

Y detrás de ese producto, hay una razón, un propósito que cumplir.

Han pasado 10 años desde la charla de Martin Fowler «No solo Code Monkeys», pero hoy es más relevante que nunca. Esa charla cambió mi perspectiva sobre cómo se debe crear el software y qué debo hacer como profesional. Dio forma a una forma de pensar que extendí al equipo de ingeniería de Paisanos, que dirijo actualmente. El punto clave: un desarrollador de software no es solo una máquina de codificación; es una persona creativa que puede contribuir a la definición, construcción y medición de un producto.

Verá, un ingeniero de software por defecto es un solucionador de problemas natural. Se sienten constantemente atraídos por la complejidad, los desafíos y la satisfacción de resolverlos. Esta complejidad está profundamente ligada a la tecnología y, gracias a su interés, se han logrado avances increíbles. Pero, ¿qué sucede cuando esta capacidad creativa y disciplinada para resolver problemas va más allá de la tecnología que debe usarse y llega a áreas que se cruzan y tienen un impacto más amplio? ¿Qué pasa si ese ingeniero, con sus características, profundiza en el «cómo» y comienza a preguntarse «por qué»?

Aquí es donde entra en juego el ingeniero de producto. Una mentalidad, un rol, una forma de crear software.

Antes de profundizar en el rol, hay algunas cosas que están impulsando el creciente protagonismo de este rol.

Un poco de contexto

Agentes, LLMs y un montón de abstracciones:

Ya está claro que todos estamos siendo aumentados por herramientas y agentes que nos ayudan a definir, diseñar y codificar. Lo que antes nos llevaba días, ahora lo podemos hacer en horas. Hace solo unos días, OpenAI anunció su modelo o1, el primero capaz de «razonar» y mejorar la precisión de las respuestas, lo que ha aumentado drásticamente el éxito de la generación de código.

‍

Y si nos fijamos en el panorama de la IA, la cantidad de posibilidades es infinita. Herramientas como Supermaven, Cursor o v0 nos brindan una velocidad que nunca pensamos que alcanzaríamos. Todo esto se traduce en un impulso significativo para la base de todo profesional: su productividad. Y cuando la productividad aumenta en toda la empresa, se necesitan menos funciones y habilidades para lograr el mismo objetivo.
Este aumento de la productividad hace que nuestro trabajo pase de simplemente codificar a validar los resultados rápidos, mejorarlos y realizar nosotros mismos algunas tareas que requieren una gran complejidad.
Esto sin mencionar las constantes abstracciones que se están creando, por lo que no es necesario construir cosas a un nivel tan bajo. Por ejemplo, hace unos años, si querías tener una aplicación, tenías que aprender Kotlin y Swift. Hoy en día, con herramientas como React Native o Flutter, tienes plataformas que proporcionan un rendimiento idéntico a la vez que mantienen la coherencia funcional y visual.
Todo esto afecta significativamente a la forma en que creamos software. No solo tenemos abstracciones que nos permiten hacer más con menos, sino que también tenemos agentes que aceleran la forma en que implementamos esas abstracciones.
‍

Esto lleva a dos caminos posibles: elegir una hiperespecialización profunda y convertirse en un experto absoluto en un área para competir a la par con un LLM o convertirse en un perfil más generalista.
‍

‍

Resultados por encima de productos

En los últimos años, las necesidades del mercado tecnológico han convertido a las empresas en fábricas de funciones, es decir, empresas que se centran en crear funciones en lugar de resolver los problemas reales de sus clientes. El exceso de liquidez del mercado llevó a centrarse en generar funciones lo antes posible para lograr el dominio del mercado. Esto se tradujo en la contratación masiva o la búsqueda de talento con salarios altísimos para adquirir conocimientos.
Junto con esto, surgieron marcos o métodos de trabajo en silos, donde los ingenieros se redujeron a simples máquinas que tomaban historias o requisitos y los convertían en código.
La actual falta de dinero en el mercado significa que las inversiones deben ser más seguras y, por lo tanto, menos riesgosas. Esto requiere adaptar una metodología de trabajo en la que el resultado no sea lo único que importa, sino el resultado. ¿Cómo vamos a lograr este objetivo empresarial con lo que implementamos?

Centrarnos únicamente en los resultados no garantiza que proporcionemos valor. Sin embargo, al hacer que nuestro equipo se centre en crear un comportamiento específico para los clientes que impulse los resultados empresariales, nos aseguramos de que se centren en la solución correcta y se mantengan alineados con la entrega de valor.

‍

De vuelta a las raíces

El ingeniero de software de los años 90 no era solo una máquina de codificación; de hecho, no olvidemos que los creadores de Agile son ingenieros. En aquel entonces, recibíamos las necesidades del cliente directamente, construíamos algo, lo enviábamos, veíamos los comentarios y lo repetíamos.
Hoy en día, empresas como Perplexity, Telegram y PostHog tienen equipos muy pequeños que interactúan directamente con sus clientes y tienen un éxito increíble. Algunas, como Perplexity, tienen equipos de 50 personas con solo dos PM.

Por lo tanto, si bien la tecnología y las metodologías han madurado enormemente, las necesidades de las empresas hacen que el ingeniero de software de los años 90 sea más relevante que nunca.

‍

El ingeniero de producto

Para empezar, quiero destacar dos referencias que describen perfectamente el papel de un ingeniero de producto.

Por un lado, en una oferta de trabajo de Incident.io, mencionan:

«Preocúpate más por los resultados y el impacto que por la implementación exacta o las herramientas utilizadas para resolver el problema».

Del mismo modo, un tuit que hacía referencia a algo que decía uno de los fundadores de ExtendHQ:

‍

Básicamente, los ingenieros de producto o «ingenieros con mentalidad de producto» son ingenieros con un profundo interés en los productos que fabrican. Son personas que quieren entender cómo se toman las decisiones, cómo las personas usan el producto y les gusta formar parte de la definición del producto. Se trata de personas que participan no solo en la construcción activa, sino también en la ideación, la definición, el seguimiento y la mejora continua, y buscan constantemente el impacto de lo que hacen.

Si nos fijamos en la forma general en que trabaja un desarrollador, la mayoría de los desarrolladores de software se centran por completo en la fase de creación y envío. Su trabajo, por lo general, consiste en tomar una definición, crear software, generar un resultado y repetir.

Sin embargo, el ingeniero de producto da un paso atrás y un paso adelante. Participan en el proceso de creación de principio a fin, desde el momento en que se define algo hasta el momento en que se envía y es necesario medirlo.

‍

‍

Ingeniería de producto por etapa

Piensa y define: conoce el por qué

El ingeniero de producto es diferente; busca entender no solo el «cómo» y el «qué», sino también el «por qué» detrás de las decisiones y el propósito de su trabajo.

El primer paso en este cambio es acercarse al usuario y empatizar con la persona que utilizará el producto. Fomentar la empatía pasa por la interacción directa, sin intermediarios, y por usar el producto como si fuéramos uno de ellos. Los productos tienen más éxito cuando quienes los crean están cerca de quienes los usan.

En la actualidad, gran parte de las aportaciones de los usuarios provienen de PM o diseñadores que ya han hablado con los usuarios, lo que crea un cuello de botella. El problema es que esta información está depurada y carece de todo el contexto y la profundidad. Es posible que los ingenieros pasen por alto detalles críticos que solo ellos pueden entender o sobre los que pueden preguntar. Es importante recopilar comentarios de primera mano.

Así como es esencial entender a los usuarios directamente, también es crucial entender el modelo de negocio: cómo gana dinero la empresa, qué la hace rentable, el mercado y la competencia. El enfoque de un ingeniero de producto no es solo construir, sino también tomar decisiones que afecten tanto a los usuarios como a la empresa. Para ello, necesitamos estar bien informados.

Es increíblemente importante mencionarlo porque cuando combinamos la capacidad de entender el esfuerzo tecnológico y las compensaciones con la comprensión del impacto que las cosas que construimos tienen en los usuarios, obtenemos un superpoder. Podemos mapear rápidamente las características en una matriz de impacto y esfuerzo para priorizar lo que se debe poner a disposición de los usuarios. Además, podemos cuestionar lo que se ha definido y proponer alternativas que generen el mismo impacto pero con mucho menos esfuerzo.

Nuestro principal objetivo aquí es hacerse cargo de la hoja de ruta y del trabajo pendiente, siendo los que ayudan a decidir y definir lo que se construirá a continuación.

Debes dividir tu tiempo entre la programación y las actividades relacionadas con el producto. Encuentre el equilibrio que mejor se adapte a sus necesidades: le recomiendo una división 70/30 (como la bebida argentina Fernet) u 80/20, con un 70% u 80% dedicado al tiempo de codificación.

‍

‍

‍

Creación: codificación de extremo a extremo impulsada por IA

Los ingenieros de producto tienen la capacidad de crear software de principio a fin de forma independiente y autónoma, es decir, tanto en el frontend como en el backend. Dado que se trata de una función generalista, es importante confiar en las herramientas para mejorar el flujo de trabajo y la productividad.

Por un lado, las herramientas de IA como Cursor o SuperMaven, que ahora son una parte esencial del flujo de trabajo, nos permiten programar en pareja constantemente con un modelo que contiene un vasto conocimiento. Esto aumenta considerablemente la productividad, hasta el punto de que algunas tareas son prácticamente como pulsar la tecla «TAB» hasta que necesitas corregir algo.

Otro punto importante es que su empresa invierte mucho en herramientas de desarrollo y fundaciones. Será muy difícil encontrar tiempo para entender los «porqués» y analizar los resultados si sigues realizando tareas manuales que no deberías realizar, como configurar la infraestructura. Herramientas como IaC (Infrastructure as Code), por ejemplo, le permiten implementar y actualizar su infraestructura de forma rápida y consistente. EAS Build (para dispositivos móviles) o Amplify (para web) le permiten realizar la implementación en tiendas o en la web con solo pulsar un botón. Sus procesos de procesamiento y de CI/CD deben ser muy precisos para que pueda empezar a dedicar su tiempo a otras cosas además de a la codificación.

A menudo, cuando empezamos la transición a este puesto, nos damos cuenta de que podríamos ahorrar mucho tiempo creando una plataforma para aumentar nuestra eficiencia y eficacia. Imagínese: si la IA le diera un impulso significativo en la actualidad, cuánto más podría optimizar automatizando los demás procesos que podrían crear cuellos de botella.

También es importante tener en cuenta que el la complejidad puede ser lo que realmente dicte si debes concentrarte más en ser un generalista o un especialista. De hecho, el tiempo también puede ser un factor que lo determine, ya que dividir las responsabilidades puede ser algo en lo que apoyarse cuando la empresa necesita avanzar un poco más rápido.

‍

Barco: experimentos y lanzamientos

Algo relacionado con lo que comentamos anteriormente sobre pensar y definir es que podemos ver las funciones que lanzamos como experimentos a pequeña, mediana o gran escala. Y como en cualquier experimento, no es necesario cubrir todos los casos y criterios de aceptación antes de lanzar una función, ya que esto nos ralentizaría. Lo que necesitamos es publicarla rápidamente y con orientación, y luego aprender qué debemos mejorar.

Para ello, es importante contar con una sólida canalización de CI/CD, que debería ser la base por defecto para el desarrollo, pero también hay que adoptar Pruebas A/B e indicadores de funciones. Ambas son herramientas extremadamente útiles que te ayudarán a realizar experimentos de forma segura y continua, con la capacidad de revertirlos rápidamente si algo sale mal.

Los indicadores de funciones, por un lado, permiten lanzar un conjunto de funciones a un subconjunto de usuarios y centrarse en mejorar una métrica específica. Por ejemplo, podrías lanzar una nueva función solo para el 30% de los usuarios más activos. A medida que obtengas resultados positivos, puedes ampliar el alcance de forma gradual hasta lograr una implementación completa.
Las pruebas A/B funcionan de manera similar, donde puedes dirigir diferentes variantes de la misma función al mismo grupo de usuarios y evaluar cuál es la mejor manera de presentar la función. Esto te permite determinar qué alternativa tiene la tasa de conversión más alta y es más beneficiosa para el producto.

Hay muchos productos que permiten esto. En Paisanos, utilizamos Posthoga, sistema operativo del producto que tiene todo lo necesario para implementar esta estrategia de manera efectiva.

‍

‍

Mide y aprende: ciclo de aprendizaje continuo

Un ingeniero de producto se centra en el cliente y su trabajo principal no es solo crear funciones, sino también rastrear el impacto de esas funciones en los usuarios.

Si lanzamos funciones sin la capacidad de medir lo que ocurre, estamos volando a ciegas y no podemos ver el rendimiento de la función. Es como conducir un coche a 100 km/h con los ojos vendados: al final, te estrellarás.

El descubrimiento de productos debe ser continuo. Como ingeniero de producto, es fundamental aprovechar herramientas como el análisis de productos, las encuestas, las entrevistas y las pruebas de usabilidad para contribuir a la iteración y el aprendizaje constantes. Obtener información directamente de tus usuarios, en lugar de confiar únicamente en las definiciones de gestión de proyectos, te ayuda a evitar los cuellos de botella. Hay muchas herramientas para ello. Puedes usar Google Analytics, Hotjar, Amplitude u otros más generales como el Posthog mencionado anteriormente. Además, no te olvides de la observabilidad del sistema. Los registros son importantes, al igual que las métricas de su sistema, y también extraerá los datos directamente de la base de datos cuando necesite información específica. Ciertos resultados apuntarán en esta dirección.

Su responsabilidad va más allá de definir, construir y enviar. También debes asegurarte de que todo sea medible, convirtiendo los objetivos en un conjunto de métricas que determinen si se han alcanzado o no.

La idea es desarrollar la intuición del producto, y esta intuición se desarrolla con el tiempo al pasar por múltiples iteraciones de ideas, experimentos, creación de prototipos y análisis del impacto de todo lo que publicas.

Recuerda que los productos tienen más éxito cuando quienes los fabrican están cerca de quienes los usan.

‍

Por dónde empezar

En primer lugar, la cultura y la organización de su empresa pueden limitar su participación en ciertas actividades (como la definición de características). Recuerda que este puesto no es para todas las empresas, y es posible que simplemente algunas no estén preparadas para desempeñarlo debido al tipo de servicio que brindan.

Si su empresa se centra en generar impacto y es relativamente pequeña o mediana, es probable que este puesto mejora la forma en que se implementan las cosas. En las empresas más grandes, esta función puede ser valiosa como puente entre los equipos de productos, ingeniería y datos.

Si estás interesado en ocupar este puesto, aquí tienes algunos consejos que pueden ayudarte:

• Desarrolla una mentalidad de producto: Empieza a pensar más allá del código. Comprenda el panorama general del producto que está creando: su propósito, los problemas que resuelve para los usuarios y los objetivos empresariales que respalda. Aprenda a preocuparse tanto por el «por qué» como por el «cómo». Empieza por preguntarte las razones detrás de ciertas definiciones de los directores de proyectos o diseñadores. Tambien puedes unirte a las reuniones de definición o análisis en calidad de oyente. Esto es clave para involucrarse en el contexto empresarial y comprender cómo piensan sus colegas de otras áreas.
• Acércate a tus usuarios: Interactúa regularmente con los usuarios. Analice sus comentarios, realice entrevistas y participe en las pruebas con los usuarios. Cuanto más cerca esté de los usuarios, mejor comprenderá sus necesidades y sabrá cómo crear funciones que se adapten a ellas. Empieza por unirte a las entrevistas con los usuarios en calidad de oyente.
• Mide el impacto: Familiarízate con las herramientas que te permiten medir el éxito de las funciones que lanza. Esto podría incluir solicitar el acceso a herramientas de análisis de productos, encuestas o herramientas de medición del sistema, como Grafana o Kibana. Poder hacer un seguimiento del impacto de lo que construyes es crucial para la mejora continua. Empieza simplemente por observar.
• Desarrolle habilidades completas: Fortalecer tus habilidades de desarrollo integral te dará la autonomía necesaria para trabajar en todo el sistema (tanto el frontend como el backend) y gestionar las funciones de principio a fin. Empieza despacio, elige una pequeña función que te gustaría implementar de principio a fin y levanta la mano para empezar a trabajar en ella.
• Adopta la experimentación: Aprenda a tratar cada función como un experimento o una prueba. Usa las pruebas A/B, las marcas de funciones y otras herramientas para publicar funciones, recopilar datos y mejorar de forma iterativa en función de los comentarios reales de los usuarios.
• Tomate tiempo: Utilice herramientas que aumenten su productividad, como el LLM, la automatización específica de la plataforma y las canalizaciones de CI/CD. Esto le permitirá centrarse en tareas de nivel superior y garantizar que no se quede atrapado en el trabajo repetitivo. Recuerda que debes dividir tu tiempo entre el tiempo de codificación y el tiempo de producto.
• Aprendizaje continuo: Manténgase al día con las últimas tendencias en tecnología y gestión de productos. Obtenga información sobre los marcos, las metodologías y las herramientas que lo convertirán en un ingeniero de producto más eficaz.

Por último, y lo más importante, sé curioso.

La curiosidad es el rasgo más valioso que podemos tener como ingenieros porque abre la puerta a descubrir cosas fuera de nuestro radar. Este descubrimiento constante lo convierte en un mejor ingeniero y mejora su empresa.

Recuerda que trabajamos 8 horas al día, algunas más, otras menos, y para disfrutar realmente de lo que hacemos, necesitamos tener un propósito. Intenta hacer que la experiencia sea más agradable y busca el propósito detrás del producto que estás creando o del servicio que ofreces. Hará que tus días sean más satisfactorios y te permitirá tener un impacto en muchas personas a tu alrededor y en todo el mundo.

‍

Gracias por leer.

Mantén la curiosidad.

‍

‍