Existe una tendencia hace un tiempo de productizar las responsabilidades y funciones de roles IT para afrontar los nuevos desafíos de la industria. Es decir, darles una capa estratégica de negocio e incrementar el alcance de su trabajo. ¡Veamos en qué dirección la industria está yendo!
El próximo 23/06, comienza la 7ma edición de mi curso "UX Research con Jobs-to-be-done". Para más información, puedes seguir este enlace.
Product Engineer, Product Designer, Product Analyst, Product Ops… Y la lista continúa.
Quizás ya lo hayas notado hace un tiempo: ¡los roles de IT se están productizando!
Pero, ¿qué es esta tendencia que aparentemente llegó para quedarse?
La productización (si encontrás una palabra mejor, te animo a compartirméla) implica tomar responsabilidades y aspectos de la dinámica de trabajo de un Product Manager y llevarlos a roles funcionales para extender el alcance y profundidad de su trabajo.
Esta tendencia comenzó principalmente con los dos roles claves en la tríada de producto, bajo el lema “todos hacemos producto”:
UX/UI Designer transiciona a Product Designer.
Developer transiciona a Producto Engineer.
No se trata solo de un cambio fancy de título para presumir en LinkedIn: es un giro 180° en el propósito de cada rol.
Además de su tarea funcional clave, ahora tanto diseñadores como desarrolladores deben ser conscientes completamente del ciclo de desarrollo de producto, y tomar decisiones end-to-end que influyan sobre la experiencia general del usuario y los resultados de negocio.
¿Y qué significa todo esto?
Implica, por ejemplo, que un Product Engineer no solo escriba código, sino también valide la factibilidad de sus tareas, se involucre en pruebas de calidad y DevOps, y haga trazabilidad de la feature que ha desarrollado una vez lanzada para monitorear resultados y aprender.
También implica que, un Product Designer, diseñe no solo considerando los objetivos de un usuario, sino entendiendo el contexto del negocio y la industria, y que pueda idear soluciones para mejorar KPIs de activación, retención, monetización, entre otros.
Productizar entonces quiere decir agregar nuevas capas de responsabilidad a un rol de IT para que puedan trabajar con una perspectiva más orientada al producto y negocio.
Pero… ¿por qué productizar?, ¿es una moda o tiene una “causa justa”?
Algunas de las principales razones, en mi opinión personal, son:
👉🏼 La ventaja competitiva ya no está en la capacidad de construir tecnología → los outcomes y la generación bidireccional de valor se anteponen al output (entregable).
👉🏼 Desarrollar producto, sobretodo a escala, es una actividad altamente compleja e interconectada → se necesita mayor consciencia del impacto final del trabajo.
👉🏼 Las células de producto cada vez gozan de mayor autonomía, y con ello, de mayor responsabilidad con respecto a las métricas de negocio → esto requiere que todos compartan un contexto similar y estén alineados en torno al problema por resolver.
👉🏼 La cultura centrada en el usuario es una verdad de industria y los datos de negocio son más accesibles que nunca → la toma de decisiones ya no pertenece a unos pocos.
👉🏼 El auge de la IA en el mercado laboral lleva a que muchos roles funcionales se interesen por extender el valor que aportan al participar de desafíos más estratégicos → no quieren quedar obsoletos.
Por todo esto, las empresas cada vez más apuestan en roles IT que tengan una fuerte cultura de producto arraigada en su mindset.
Productizar no se trata de cambiar el propósito de un rol ni su tarea funcional clave, pero si otorgarle un nuevo punto de vista que considere la big picture de cómo un negocio opera.
Sin más por agregar, ¡veamos algunos roles que estuvieron productizandose en este último tiempo!
Históricamente, el rol del desarrollador se centró en la implementación de requerimientos funcionales, definidos por lo general por otras personas en el equipo.
Construir features, resolver bugs y desempeñar otras tareas técnicas eran la moneda corriente de todos los días.
Esto hace un tiempo que está cambiando, debido a que ya no alcanza con solo asegurar una ejecución eficiente (que ya eso implica un montón, lo sé), sino que es importante entender el por qué detrás de lo que se hace.
Un Product Engineer es un perfil técnico que entiende profundamente el producto, los objetivos del negocio y las necesidades del usuario.
Se involucra desde temprano en actividades de Discovery, trabaja en la validación técnica de los supuestos que sostienen su idea, sugiere alternativas más eficientes y, especialmente, mide el impacto de sus esfuerzos.
Un Product Engineer no se queda sentado preguntando: “¿qué hay para hacer?”, sino que adopta una mentalidad más de “¿por qué estamos construyendo esto y cuál es la mejor manera de resolverlo?”.
Propone, piensa, idea, planifica, monitorea… no solo ejecuta.
Un UX/UI Designer está a cargo de la definición de la experiencia de usuario y del diseño visual de la interfaz, aunque, en mi experiencia, muchas veces termina siendo un 80% de UI y un 20% de UX.
De todos modos, eso no quita que, tradicionalmente, el rol del UX/UI Designer haya estado más centrado a satisfacer las metas del usuario que los objetivos del negocio.
No por querer llevar la contraria, sino porque no eran una prioridad. El cliente es la prioridad, y eso está bien, pero hasta cierto punto.
Un Product Designer adopta una mirada más estratégica acerca del diseño del producto, considerando necesario un balance adecuado entre metas de usuario y objetivos de negocio.
Es una función que no se conforma con un 80% UI y 20% UX, sino que busca involucrarse más activamente en la definición del problema y liderar así un Product Discovery.
No solo entrevista usuarios, sino también lee métricas, interpreta resultados, contribuye a las decisiones sobre la dirección general de producto en el Roadmap.
No solo vela por los intereses del cliente, sino también por los del negocio, diseñando así ideas que sean funcionales a métricas clave.
El análisis de datos es una actividad fundamental en el ciclo de desarrollo de producto.
La interpretación de datos y recolección de insights permiten aprender lo que está bien y lo que está mal para así ajustar la ejecución estratégica en la dirección correcta.
Para ello, el Data Analyst era un rol clave, que responde a pedidos específicos como generar reportes, construir dashboards y entregar análisis sobre el negocio.
La cuestión, es que muchas veces, se apoyaba de herramientas de BI como Tableau, Looker Studio, Qlikview e incluso plataformas de Web Analytics como GA4, que si bien pueden otorgar datos interesantes, no están pensadas para medir con precisión usabilidad de producto.
En función de esta problemática, nacieron múltiples plataformas de análisis 100% dedicadas a producto como Amplitude, Mixpanel, PostHog, Heap y Kissmetrics, entre otras.
Estas plataformas concedieron “superpoderes” al Data Analyst para darle una perspectiva mucho más rica en producto, lo que dió origen al rol de Product Analyst.
Un Product Analyst es un socio estratégico del equipo de producto, que entiende perfectamente cómo manipular distintos eventos y propiedades para ayudar a identificar oportunidades de mejora, medir experimentos y validar hipótesis.
Un Product Analyst no solo analiza datos, sino que busca entender el comportamiento de los usuarios e identificarlos en distintos segmentos y cohortes.
Adquiere mayor consciencia sobre cómo los esfuerzos de un equipo se relacionan con los resultados de negocio que se buscan.
Por último, hay una función de producto que durante los últimos años estuvo ganando mucha relevancia: Product Operations.
Esta función se construye a partir de la base de distintos otros roles tradicionales en un equipo de desarrollo, cuyas responsabilidades confluyen para lograr un rol más holístico.
No los reemplaza directamente, obvio, pero sí que toma un poco de cada uno para garantizar la integración de prácticas de producto en la empresa.
Veamos cada uno primero:
Un Delivery Manager coordina la ejecución de tareas y que el entregable sea bueno.
Un Agile Coach busca que las metodologías den resultados y sean bien ejecutadas.
Un analista de operaciones trabaja sobre los flujos de trabajo internos para optimizar.
Un CX Strategist consume feedback de usuarios para compartir oportunidades de negocio a producto.
Product Ops surge como un rol integrador que escala la práctica de producto.
No tiene un producto a su cargo, sino que habilita a los equipos de producto a trabajar mejor: optimiza procesos, sistematiza herramientas, facilita el acceso a insights de Research, estandariza métricas y ayuda a tomar decisiones informadas.
Así es, un poco de operaciones, un poco de Project Manager, un poco de UX/CX.
Un rol especialmente útil en organizaciones de producto que comienzan a escalar.
La productización de roles IT es una tendencia relevante porque responde a una realidad de industria donde los principales desafíos ya no están en la implementación técnica de una solución, sino más bien en la adecuación estratégica del producto en el mercado.
Que no se confunda: el aspecto funcional de cada puesto sigue siendo el core de su rol.
Un Product Engineer que no sepa programar no tiene ningún propósito.
Un Product Designer que no sepa diseñar no puede realizar su trabajo básico.
La productización no se trata de reemplazar las habilidades técnicas, se trata de agregar capas de estrategia de negocio y producto al rol funcional.
De hacer que cada rol tenga una visión más holística sobre el ciclo de desarrollo de producto.
Que un Product Designer no solo diseñe, sino que también vele por las métricas de negocio.
Que un Product Engineer no solo desarrolle, sino que se preocupe por el end-to-end del nuevo release a los usuarios y todas las actividades que eso implica.
Para alcanzar estos nuevos roles productizados no solo se necesita de un cierto nivel de seniority, sino, principalmente, de un cambio cultural.
Una cultura que empuje a los distintos colaboradores a expandir su área de interés e involucrarse en asuntos que tradicionalmente no fueron parte de su función.
Si estos roles están bien implementados, los beneficios tanto para los colaboradores (en términos de desarrollo profesional) como para el negocio (en términos de resultados) serán muy notables.
¡Eso fue todo por hoy!
Muchos éxitos.
1. Aprende con Lumi: mi app de microcursos es ideal para desarrollar y fortalecer habilidades de Product Management con pequeñas píldoras de contenido de tan solo 5 minutos.
2. Descubre mis cursos: súmate a mis cursos tanto en vivo como grabados que realizo sobre Product Management. Puedes aprender sobre Product Analytics y Jobs-to-be-done, entre otros temas.
3. Mentorías 1-1: consulta por mi servicio de mentorías 100% personalizadas, donde te acompaño en tu desarrollo como Product Manager y te aconsejo en la resolución de los desafíos que tengas en el camino.
4. Consultoría de producto: acompañó a equipos y empresas a superar los principales bloqueos y obstáculos relacionados con la gestión del desarrollo y diseño de productos digitales.
Conocimiento práctico sobre Product Management en solo 5 minutos, cada martes.