Product Ops: qué es y qué hace este rol de producto

read time

5 min

Antes de hablar de Product Ops, recordemos una cita familiar para cualquiera que haya crecido en los años 90 recordará que el maestro Miyagi dijo:

 "Cuando un hombre tiene hambre, es mejor enseñarle a pescar que darle un pescado".

Esto no es un debate sobre Karate Kids, ni un refrito de la sabiduría dispensada en las galletas de la Fortuna. Entonces, ¿cómo relacionamos esta dudosa metáfora con el Product Management? Hablemos del coaching, la autonomía y el empoderamiento de los Product Managers. 

Como todos sabemos, para dominar tu dan (en Thiga hablamos de un framework 😉 ), el Product Manager interviene en la confluencia de muchas habilidades. Su vida diaria es, a menudo, intensa y por desgracia, a veces, algunas tareas quedan sin priorizar.

Los grandes olvidados suelen ser la investigación de usuarios, el análisis de datos, la puesta en marcha de experimentos, etc. Hay muchas razones para ello: la falta de tiempo o de recursos, la falta de concentración, el carácter tedioso de ciertas tareas, la falta de herramientas o lo inadecuadas que pueden ser.

Para hacer frente a este dolor en la organización de Producto, ha surgido recientemente un rol cuyo objetivo sería simplificar la vida de los Product Managers (y de los equipos de Producto en general): se trata del Product Ops (o ProductOps). 

Pero, ¿por qué el sufijo "Ops"?  Para establecer un paralelismo con el papel de DevOps, estos profesionales llevan dos sombreros:

  • Proporcionar los medios y procesos de liberación para que los desarrolladores sólo tengan que preocuparse por la calidad de su código;
  • Garantizar la solidez del proceso de lanzamiento automatizando el mayor número posible de tareas y pruebas.

¿Qué pasa con ProductOps? ¿Cuáles son las funciones y los privilegios de este nuevo cargo? ¿Cuándo es pertinente considerarlo en una organización orientada a Producto? Quién sabe, tal vez con este artículo pienses que esta función no es relevante en tu organización. 

¿Qué es un Product Ops? 

Todavía no hay mucha literatura sobre el tema (aparte de un estudio reciente de Pendo y Product Collective, que es una referencia). Pero podemos resumir su declaración de intenciones en torno a 4 variables: relación con el cliente; producto; tecnología y datos.

1. Crear un entorno propicio para construir el Producto adecuado 

  • Difundir en la organización la cultura centrada en el usuario.
  • Recoger las necesidades y definir las pautas de la investigación de usuarios.
  • Permitir la experimentación de productos y vincularla a la estrategia empresarial.
  • Ayudar a los equipos de productos a optimizar el proceso de desarrollo de productos y a ganar en coherencia. Especialmente, cuando los equipos están repartidos internacionalmente.

2. Establecer una herramienta adaptada a los equipos de producto 

  • Recomendar las herramientas más relevantes para los equipos de Producto;
  • Automatizar ciertos procesos relacionados con el Producto a través de estas herramientas;
  • Instruir a los equipos en el uso de las herramientas y en las mejores prácticas.

3. Construir relaciones entre equipos y usuarios

  • Garantizar la comunicación de las opciones de productos y el roadmap en tres círculos: 
    • Primer círculo: el equipo de Producto: desarrolladores; QA y DevOps;
    • Segundo círculo: la empresa: alineación de las partes interesadas y comunicación de las decisiones;
    • Tercer círculo: el resto del mundo: comunicación del roadmap y la visión del producto a los usuarios/clientes.

4. Proporcionar a los equipos de producto todos los datos útiles, explotando un máximo de fuentes

  • Datos del producto: para ayudar al análisis y a la toma de decisiones mediante el uso de paneles de análisis; tendencias observadas en las pruebas A/B; datos de adquisición (medios sociales y campañas publicitarias); etc.  
  • Datos empresariales: explotar el conocimiento del mercado: cuestionarios y puntuaciones NPS; servicio de atención al cliente; análisis de la competencia y puntos de referencia; etc. 
  • Datos técnicos: asegúrese de tener en cuenta también los datos técnicos: sobre el rendimiento; sobre la deuda funcional y técnica, por ejemplo.

En resumen, ProductOps es un catalizador. Acelera la velocidad de toda la cadena de valor del producto. También garantiza la coherencia del enfoque del producto a escala (automatización y utillaje), independientemente de la dispersión geográfica.

 

Lao-tzu dijo "Hay que encontrar el camino"... de Product Ops en los equipos

ProductOps no pretende sustituir las funciones, sino actuar de forma complementaria. Sin embargo, hay que tener cuidado de no canibalizar las funciones existentes.

Product Ops y Product Manager

El primer riesgo que se observa es el de “desposeer” al Product Manager. En el modelo de UBER, el ProductOps se encarga de definir el alcance del producto: concentrar las necesidades y alimentar el roadmap.

Este posicionamiento, que responde al objetivo de optimizar el time-to-market de las funcionalidades, entra claramente en conflicto con una de las principales tareas del Product Manager (véase nuestro framework del Product Management).

El segundo riesgo es que ProductOps sea visto como un asistente de los equipos de producto, para realizar tareas tediosas con poco valor añadido: informes ad hoc o cuadros de mando, por ejemplo (sic). Esta es la principal trampa en la que hay que evitar caer.

Sin embargo, si lo comparamos con DevOps, este último no es responsable de la calidad del código, sino de la simplicidad y robustez de las versiones de producción. Por lo tanto, el ProductOps no será responsable de la elección del roadmap ni de la priorización. Sí debe proporcionar a los Product Managers los elementos necesarios para tomar las decisiones correctas en función de los datos o de los comentarios de los usuarios. 

Cuántos Product Managers me han dicho ya que quieren dedicar más tiempo al user discovery con la UX, a observar sesiones con herramientas de grabación, a analizar comentarios en las tiendas de aplicaciones, a explotar la analítica... ProductOps es un agregador de necesidades.

Por ejemplo, ayudará al Product Manager a priorizar el roadmap, proponiendo una puntuación RICE detallada basada en las numerosas fuentes de datos que dispone (para destacar el alcance y el impacto, por ejemplo). 

En resumen, el ProductOps debe facilitar al Product Manager el acceso a la información correcta y útil para la toma de decisiones. Debe seguir siendo un proveedor de medios (outcomes) y no de datos fijos (outputs) sobre el Producto. 

 

ProductOps y DevOps

Algunos artículos explican que la coordinación de los desarrollos y despliegues —que entra claramente en el ámbito de DevOps—, forma parte de los privilegios de ProductOps.

A veces, incluso se asigna a ProductOps la tarea de crear herramientas para supervisar y automatizar las entregas. Estas tareas se suelen asignar al Scrum Master y luego, generalmente, se transfieren al equipo de desarrollo, que se ha vuelto autónomo.

ProductOps debe elegir sus batallas. Dependiendo de la empresa en la que trabajan, pueden tener diferentes enfoques: muy orientados a las herramientas, a los datos o incluso a las operaciones del producto.

La persona sabia buscará el "equilibrio" adecuado en la organización 

Como todas las características de la organización, la implementación de este nuevo rol es tentadora. Pero antes de ceder a esta tendencia de producto, debes preguntarte si es apropiado para tu organización. En una organización "como producto", una elección debe responder a un painpoint para un beneficio identificado. 

Tres factores pueden justificar su introducción:

  • Crecimiento significativo del número de equipos de producto, lo que lleva a la necesidad de homogeneizar prácticas y herramientas. 
  • Necesidad de operar con equipos dispersos geográficamente, con el riesgo de no alinear las visiones y la no coherencia de las características.
  • Una organización basada en equipos que no son estables o que tienen alcances que cambian rápidamente. Por ejemplo, en organizaciones con equipos de impacto.

La cuestión de la forma correcta de organización de Producto suele ser compleja. No quiero hacer una metáfora citando la noción de equilibrio típica del taoísmo (yin yang...), pero ¿dónde situar este rol sin poner en duda la organización del Producto? 

Cualquiera que sea la organización de destino, tendrá que cumplir las leyes que definen una organización de productos:

  • La ley del cliente/usuario: la obsesión por el impacto del usuario es la razón de ser de la organización.
  • Ley del Equipo Pequeño: se supone que el trabajo debe ser realizado por pequeños equipos autónomos, trabajando en ciclos cortos y siguiendo la Ley del Cliente (Time-to-Impact).
  • Ley de la Red: toda la organización hace un esfuerzo continuo por eliminar la burocracia, la jerarquía y los procesos innecesarios.

Ya se ha dicho bastante en el artículo: por definición, la función de ProductOps cumple la primera ley. Pero, ¿qué pasa con las leyes 2 y 3? Añadir una función de ProductOps a cada equipo parece excesivo, ya que ampliaría el número de miembros de cada equipo. Tampoco garantizaría la coherencia (herramientas y flujos de trabajo del producto) de la que es responsable el ProductOps.

Si hubiera un modo óptimo, podría ser un equipo dedicado, una especie de equipo de componentes "ProductOps". Su objetivo sería facilitar los modos de funcionamiento de los demás equipos en autonomía: establecimiento de planes de etiquetado generalizados, pruebas de concepto sobre herramientas de análisis de productos, automatización de prácticas, visualización del feedback de los usuarios, puesta en común de los roadmaps, etc.

Todos estos proyectos se priorizarían, por supuesto, en el backlog de ProductOps. Los Product Managers serían partes interesadas/consumidores.

Recuerda: la organización es un Producto, que responde a los painpoints. La implantación de ProductOps puede ser una respuesta para simplificar la vida de los Product Managers en casos de fuerte crecimiento, dispersión geográfica y/o inestabilidad del equipo. No es la respuesta a todos sus males. 

En función del “dolor” de la organización, son posibles muchas otras respuestas: subcontratar la investigación de usuarios, estandarizar los experimentos o los indicadores clave que hay que supervisar en cada equipo, etc.

Por último, los retos de la creación y la evolución de las organizaciones de productos se abordan en nuestras formaciones de Thiga Academy dedicadas a los equipos de producto.

 

Publicado el 09 dic 2021

Actualizado el 27 nov 2022

clipboardCopiar el enlace
Escrito por
Victor Dulieu
Victor Dulieu

Próximos eventos

LPCx Madrid: B2B2C

calendar

24 Marzo 2022

Apúntate

La Product Conf Madrid 2022

calendar

19 mayo 2022

Apúntate

Filles_ordinateur

¿Quieres compartir con el mundo tu pasión por los temas de producto?

Cada mes, más de 20.000 entusiastas del producto digital visitan nuestro media. Comentarios, opiniones controvertidas... ¡compártenos eso que tienes en mente!

 

Contactar con la redacción