Product Ops, la pieza que falta en tu organización de Producto

Al igual que yo, seguramente han escuchado cada vez más sobre Product Ops. ¿Coincidencia? No, el tema es más profundo y parece que perdurará durante algunos años más. De hecho, el Product Ops es el rol que faltaba para acompañar el auge del Product Management, aportando más estructura a las organizaciones a gran escala. ¿Es relevante para tu contexto? En este artículo te doy las claves para reflexionar sobre ello.

🤔 Mi definición de Product Ops 

Antes de adentrarnos en el tema principal, compartiré mi definición del rol de Product Ops, ya que no existe una definición única.

Algunos afirman que es el Product Manager (PM) de la organización de productos. La analogía es fuerte e impactante. Como un PM, maneja un backlog de mejoras, eso es cierto, pero no puedo estar completamente de acuerdo con esta definición porque falta un elemento importante: el Product Ops va más allá y lleva a cabo los cambios por sí mismo.

Por lo tanto, prefiero la definición de John Cutler: “Product Ops solves problems for product teams that single teams and individuals cannot solve”. En palabras más sencillas: “El Product Ops resuelve problemas que un equipo o un individuo no puede resolver”. Esto muestra varios elementos clave:

• El Product Ops trabaja en la organización en general, no solo en un equipo o individuo, como lo hace, por ejemplo, un coach.
• El Product Ops no se limita a recomendar un cambio, también lo implementa y sigue su evolución a lo largo del tiempo.

💪 Los 3 beneficios de tener un Product Ops

Como ocurre con cualquier nuevo rol en el mundo digital, es tentador pensar que solo es adecuado para contextos ultra maduros de Silicon Valley. Sin embargo, es evidente que cada vez más organizaciones tienen Product Ops. Pero ¿por qué se habla más de esto hoy en día? Identifico tres factores principales que hacen que el Product Ops esté en alza, resumidos en el diagrama que presento a continuación.

#1: El Product Ops aporta alineación y homogeneidad en organizaciones de gran tamaño

En mi opinión, el tamaño de la organización es el criterio más importante para determinar si es relevante tener un Product Ops o no.

Si la empresa todavía es de un tamaño razonable (1 o 2 niveles de gestión), la necesidad de alineación todavía puede ser gestionada por la organización actual.

Sin embargo, cuando el número de personas en la organización es grande, surgen necesidades de homogeneidad y gobernanza, principalmente en los siguientes temas:

• Los procesos y herramientas para aprovechar las mejores prácticas, facilitar la alineación y la sincronización entre equipos.
• Las descripciones de puestos y trayectorias profesionales.
• La implementación de tableros de control que faciliten las comparaciones entre equipos y la dirección de la estrategia (especialmente los OKRs si están en uso).
• La coherencia de los roadmaps en términos de contenido (alineación con la estrategia) y formato para facilitar la lectura de todas las partes interesadas.
• La gestión de ideas de usuarios y del mercado, que se vuelven cada vez más numerosas.
  
  

#2: El Product Ops facilita el crecimiento de los equipos

Entre las organizaciones de tamaño medio y las de gran tamaño, hay muchas organizaciones para las cuales es legítimo considerar la necesidad de tener un Product Ops.

Para estas organizaciones, uno de los factores clave a considerar es el crecimiento previsto de la organización, principalmente en los siguientes temas:

• La definición de las descripciones de puestos para garantizar la contratación de perfiles adecuados, un desafío importante.
• La estructuración de los procesos de integración, que se volverán cada vez más numerosos.
• La convergencia de procesos y herramientas para evitar tener que hacer este trabajo con más personas alineadas y un historial extenso.

Preparar el futuro y acompañar el crecimiento es la razón de ser del Product Ops en organizaciones de rápido crecimiento.

#3: El Product Ops conduce hacia una mayor madurez del Producto

Si retrocedemos unos años, las dos principales prioridades de muchas organizaciones de productos eran:

• Gestionar un delivery rápido y eficiente a nivel de los equipos.
• Abordar las dependencias de desarrollo entre equipos. 

Por lo tanto, los coaches Agile y el Head of Product (u otros roles de gestión relacionados con el producto) eran suficientes para abordar estos problemas.

Ahora, la madurez promedio ha evolucionado enormemente. Con pocas excepciones, la agilidad ya no es un problema. Los PM quieren entornos en los que puedan prosperar y que se asemejen a lo que nos venden Marty Cagan con sus "empowered teams" o Teresa Torres con su "Continuous Discovery".

Los desafíos actuales giran en torno a la capacidad de impactar rápidamente a los usuarios y medir este impacto, lo que conlleva subtemas como los OKRs, el descubrimiento constante, la coherencia de los roadmaps en relación con una estrategia común, el seguimiento de los KPIs y la centralización de información valiosa.

Por lo tanto, no sorprende ver que Alexandre Serrurier, Lead Product Ops en ManoMano, declarara recientemente en una entrevista para Productinbox que: “La integración de este rol [Product Ops] en la organización lleva a un equipo de producto a un nuevo nivel de madurez por dos razones: en primer lugar, el rol resuelve  problemas mecánicamente y, en segundo lugar, envía un poderoso mensaje, 'queremos mejorar', desde la dirección”. No puedo más que estar de acuerdo con este mensaje.

Estos tres desafíos explican por qué los Product Ops son populares en empresas en crecimiento y de gran tamaño, como Alma, ManoMano o PayFit, y también por qué están apareciendo en grandes corporaciones como Decathlon o Carrefour, debido a su tamaño y al avance en la madurez.

🤝 Sin Product Ops, la responsabilidad se vuelve responsabilidad de todos... o de nadie

Muchas organizaciones aún no han adoptado el rol del Product Ops.

Las razones válidas son varias:

• El tamaño y el crecimiento de los equipos no son suficientes (caso de las startups).
• El deseo de limitar los involucrados en la organización y empoderar a las personas que ya están presentes en estos temas.
• La madurez de la organización no justifica la presencia de especialistas en producto.

Lamentablemente, también existen malas razones:

• El desconocimiento del rol.
• El deseo de algunos de mantener su territorio.

Sin Product Ops, la responsabilidad de abordar los problemas sistémicos recae en otros, en detrimento de sus otras responsabilidades. Pero, ¿quiénes son estos?

El más obvio: el Head of Product 

¿Por qué el Head of Product -o cualquier otro rol de gestión que podría encontrarse en una organización de producto- parece ser la persona más obvia para asumir estas responsabilidades? Con su visión transversal, es la opción por defecto, sobre todo en start-ups y scale-ups. Y tiene varios argumentos a su favor:

• Suele ser el más experimentado.
• Tiene la responsabilidad jerárquica de hacer evolucionar a los Product Managers.
• Tiene un fuerte interés en que el proceso de productos sea fluido y eficiente para sacar el máximo provecho de sus equipos y asegurarse de que sus subordinados se sientan bien.

El Head of Product puede abordar la mayoría de los temas de un Product Ops, pero si es necesario priorizar, naturalmente se centrará más en los relacionados con la gestión (descripciones de puestos y trayectorias profesionales) y la estrategia (dirección y roadmaps).

También se les puede consultar sobre temas más operativos como procesos y herramientas, pero al no ser los principales afectados, es más apropiado que otras personas se encarguen de ello.

Desafortunadamente, su tiempo es limitado, y se enfoca en gran medida en la estrategia de productos y la alineación con otros departamentos de la empresa. No puede asumir por sí solo todas las responsabilidades de un Product Ops. Además, con el tiempo y según el número de personas que gestiona, esta situación no es sostenible si lo queremos hacer correctamente.

También ten en cuenta que si hay varios Heads of Product, es importante asegurar que exista alineación entre las prácticas, herramientas y descripciones de puestos de todos los equipos de producto.

Los más generosos: los Product Managers

Los Product Managers son los primeros afectados por procesos defectuosos y, ante esto, pueden sentirse como salvadores. Esta situación también tiene la ventaja de responsabilizar a los PM en la eficacia del proceso de producto. Este argumento es la razón por la cual empresas como Backmarket y BlaBlaCar, por ejemplo, han optado conscientemente por no tener un Product Ops. Es honorable, pero requiere equipos maduros que estén dispuestos a abordar estos problemas en beneficio de toda la organización.

En comparación con el alcance de un Product Ops, los PM se centrarán principalmente en lo que más les afecta, es decir, todo lo relacionado con lo operativo: los procesos, las herramientas y la gestión de dependencias.

Este tipo de organización puede ser visto como una oportunidad para que un PM evolucione hacia un puesto de Head of Product, ya que abordará cuestiones transversales a los equipos y, potencialmente, algunas como la estrategia o aspectos de recursos humanos que no están dentro de sus competencias actuales.

La intención es loable, pero existen dos riesgos importantes: el primero es la implementación de soluciones sesgadas por la única consideración de la necesidad de un PM; el otro es que nadie se haga cargo de un problema de manera global y encuentre una solución de contingencia en su propia área de responsabilidad.

Los más cercanos: los Coaches

Un coach tiene la misma misión que un Ops: mejorar la organización. Las aproximaciones son diferentes:

• El Coach trabaja con individuos y equipos, impulsando el cambio.
• El Ops trabajará en la organización, con un enfoque en la escalabilidad, liderando el cambio (por supuesto, previa consulta).

La diferencia es sutil, lo reconozco, y es por eso que muchos Product Ops actuales son ex coaches. La postura cambia. La temporalidad también: el Product Ops se inserta en el tiempo, mientras que el coach generalmente llega para ayudar temporalmente a superar una etapa.

Cuando se habla de coaches, se piensa principalmente en los coaches ágiles. ¿Puede un coach ágil ser un buen Product Ops? En términos de habilidades interpersonales en coaching y gestión del cambio, sí, sin duda. En cuanto a las habilidades técnicas en producto, es posible, pero no es una verdad absoluta. Depende en gran medida de su disposición para ir más allá del delivery.

La peor solución: ¡Nadie!

Por supuesto, no tener un Product Ops simplifica la organización al tener una persona menos involucrada, pero esta situación solo es viable bajo dos condiciones:

• La primera condición es que forme parte las responsabilidades de los puestos de trabajo y que se les dedique tiempo.
• La segunda condición es que las personas se sientan motivadas y capaces de abordar estos problemas transversales.

Si no se cumplen estas dos condiciones, es probable que la organización continúe enfrentando problemas sin armonización de prácticas.

En resumen, todas las responsabilidades de un Product Ops pueden ser asumidas por los roles actuales de la organización, pero en mi opinión, el resultado no es favorable y es solo una solución por defecto. Sí, los equipos serán más conscientes de los procesos interdepartamentales, pero el costo a pagar es demasiado alto, con una pérdida de enfoque de los equipos y personas que pueden no estar capacitadas para liderar el cambio.

🔮 ¿Qué le depara el futuro al Product Ops?

Si, como yo, estás convencido de que el Product Ops aporta un valor real, es hora de contemplar su futuro con una pregunta central: "¿Todas las organizaciones de productos adoptarán este rol?". Aquí están mis predicciones, dignas de la adivina Madame Irma.

#1: Las startups continuarán operando como hasta ahora, sin Product Ops. Las alineaciones entre equipos seguirán siendo manejables por los PM y el Head of Product, posiblemente con un Coach de Producto en apoyo ocasional.

#2: Las scale-ups seguirán invirtiendo en estos roles para acompañar su crecimiento. Aquellas que no tengan un Product Ops serán tan raras como un trébol de cuatro hojas (pero eso no necesariamente traerá buena suerte).

#3: Las grandes corporaciones se convertirán en el nuevo campo de juego para los Product Ops, con núcleos de Product Ops emergiendo, incorporando parcialmente otros perfiles en áreas específicas (Recursos Humanos, Finanzas y Tecnología) además de Product Ops. Esto es lo que está haciendo actualmente Decathlon con su "Product Office". Poco a poco, estos núcleos reemplazarán a los centros ágiles para guiar las transformaciones de producto.

#4: Cada vez más Product Managers seniors se inclinarán hacia carreras en Product Ops para atender estas necesidades en crecimiento.

#5: Thiga lanzará un framework de Product Ops para ayudar a comprender qué es este rol, su alcance y las habilidades requeridas 😉.

Foto Ryoji Iwata de en Unsplash.

Para obtener más información sobre las organizaciones de productos: descarga nuestro libro Agile Product Management