Product Ops como habilitador

Dec 06 2022

El rol de las operaciones de productos ha recibido una atención creciente en los últimos años, pero al igual que muchos roles que trabajan para alcanzar la madurez, surge mucha confusión e incertidumbre. Una de las mayores dudas es sobre dónde se ubican las operaciones de productos dentro de la organización, qué manejan/poseen y dónde pueden aportar valor.

Una de las mayores dudas es sobre dónde se ubican las operaciones de productos dentro de la organización, qué manejan/poseen y dónde pueden aportar valor. Especialmente desafiante cuando se introducen operaciones de productos en una organización que nunca ha trabajado con operaciones de productos.

Teniendo en cuenta la adaptabilidad del rol y la función que dependen de la organización, podríamos argumentar potencialmente que cualquier cosa y todo es un juego y potencialmente dentro de nuestro alcance.

En mi opinión, si mantenemos los principios básicos en orden, el rol se puede adaptar fácilmente a cualquier organización y el alcance es fácil de definir.

Pero, ¿qué significa eso realmente?

La palabra clave es habilitador

Incluso los expertos tienen diferentes opiniones y puntos de vista sobre el tema, pero una palabra que sigue apareciendo es ser un habilitador o habilitar al equipo.

Como lo expresó tan elocuentemente Antonia Landi en una actualización reciente de Linkedin :
“Recientemente aprendí algo importante: no explicar Product Ops como 'facilitar la vida de las personas'.

Como facilitador del trabajo, es fácil querer ser útil a toda costa, y es una historia fácil de 'vender' a nuevos compañeros y partes interesadas. Después de todo, estoy aquí para hacerte la vida más fácil, ¿por qué no me quieres cerca?

Y luego resume muy bien su opinión final con: "Mi trabajo es permitir que las personas de nuestro departamento hagan un gran trabajo".

Creo que lo importante es que, al tener claro nuestro papel como habilitadores, nos ayuda a definir un propósito y un alcance más claros.

Como habilitadores, seremos los Multiplicadores de la Fuerza como sugiere Marty Cagan en su artículo en lugar de un papel de relleno.

Pero en términos prácticos, ¿qué significa eso y cómo aplicamos esa lógica al pensar en el rol y el alcance?

Permitir no poseer

Por mucho que nos gustaría poder presentar una respuesta estándar sobre el alcance y la responsabilidad de las operaciones del producto, no podemos porque tendrá que adaptarse, dependiendo de varios factores:

Las necesidades específicas de la organización.
Dónde se ubican las operaciones del producto dentro de la organización
La madurez de la organización del producto.

Cuando habilitamos, desbloqueamos oportunidades. Ayudamos a conectar a las personas para construir las relaciones correctas. Creamos las infraestructuras para apoyar al equipo en lugar de forzarlo.

Veamos el ejemplo práctico de los comentarios de los clientes. Ya sea que la empresa tenga investigación, éxito de clientes, ventas, operaciones de clientes o ninguno de los anteriores, entendemos que los comentarios de los clientes son una parte importante del proceso de desarrollo de productos.

El desafío es que los comentarios de los clientes provienen de varias fuentes y cada uno quiere asegurarse de que los comentarios de los clientes lleguen a las personas adecuadas para tomar las decisiones correctas.

En este punto, las operaciones de productos podrían ver fácilmente como su responsabilidad engrasar la máquina y asegurarse de que eso suceda.

Lo cierto es que existen múltiples formas de abordar la situación, dependiendo de los factores mencionados anteriormente.

¿Cómo hacemos que funcione sin pisar los dedos de los pies de nadie?

Como regla general, personalmente sugiero el siguiente enfoque incremental.

Paso 1: Comience conectando los puntos

El primer paso consiste en identificar a las personas, los departamentos y la información clave para conectarse.

¿Quién es dueño de qué?
¿Quién nos ayudará a impulsar las cosas?
¿Quién necesita consumir la información y cómo?
¿Quién puede proporcionar la información y cómo?

A veces, podemos descubrir soluciones ya existentes y sacarlas a la luz. Si esos sistemas y prácticas de apoyo funcionan lo suficientemente bien, es posible que podamos dar un paso atrás sin mucha intervención.

En otros casos, podemos darnos cuenta de que faltan demasiados eslabones entre las soluciones existentes y necesitaremos brindar más apoyo para mitigar esas deficiencias.

Potencialmente, podemos llegar a la conclusión de que no existe una infraestructura real y necesitaremos ser aún más activos que las dos versiones anteriores. Sin embargo, y esto es importante, esto no significa que debamos asumir la gobernanza. Puede ser un indicador temprano, pero aún no está escrito en piedra.

Paso 2: Apoyar la infraestructura

En los tres casos presentados en el paso anterior, ahora necesitaremos brindar algo de soporte, pero variará mucho para cada uno.

En el primer caso, se trata de soportar esa conectividad hasta que sea capaz de sostenerse a sí misma. No como dueños, sino como facilitadores o conectores.

El segundo caso presenta un poco más de complejidad, donde necesitamos apoyar la conectividad, pero también necesitamos ayudar a definir los modelos de trabajo de las piezas faltantes. En este caso, si somos dueños de la obra o simplemente la apoyamos, dependerá de si tenemos propietarios existentes que tengan más sentido que nosotros.

En el caso final, necesitamos tener una parte más activa y, a veces, debemos ser los conductores. Aquí somos los dueños al menos durante el proceso de ideación, definición y lanzamiento. Pero no necesariamente propietarios a largo plazo.

Paso 3: Poseer solo lo que tiene sentido, cuando tiene sentido

Aquí es donde debemos ser realmente estrictos sobre si nos hacemos cargo de algo o damos un paso atrás y dejamos que los equipos se hagan cargo ellos mismos.

En el primer caso, es más fácil, porque ya tienen la infraestructura existente para poseer todo. Ayudamos a desbloquear la eficiencia en esos modelos de relación y trabajo. Eso es todo.

En el segundo caso, debemos estar seguros de quién debe ser el propietario de la solución. Product Ops podría poseerlo temporalmente hasta que exista el equipo o la infraestructura necesarios. En el ejemplo de los comentarios de los clientes, si hay un equipo de éxito del cliente u operaciones del cliente, tiene mucho más sentido que sean los dueños. Mantenerlo en Operaciones no tendría sentido a largo plazo y “luchar” por él sería un esfuerzo inútil.

En última instancia, similar a la opción anterior, debemos tener claro si la solución se encuentra dentro del alcance de Product Ops a largo plazo. Si tiene sentido, entonces Ops debería poseerlo y evolucionarlo.

Sin embargo, si no está dentro del alcance definido para las operaciones del producto, debemos estar preparados para dejarlo ir una vez que esté listo.

Deberíamos estar felices de pasárselo a los propietarios que tengan más sentido. Deberíamos apoyarlos para que se apropien. Su éxito es parte de nuestro éxito y de no soltar a nuestro “bebé”.

Esa es una parte importante de ser el habilitador. Queremos apoyar a los equipos a través de los desafíos complejos y luego ayudarlos a estar preparados para apropiarse de esas soluciones en el futuro.

Pensamientos finales

Probablemente una de las cosas más difíciles de asumir un rol de operaciones de productos es saber que trabajará en muchas cosas que potencialmente no tendrá en el futuro.

Se trata de invertir nuestro tiempo y esfuerzos en producir nuestro mejor trabajo y luego, a veces, entregárselo a otros.

La recompensa está en ver cómo otros se benefician de tu intervención y cómo ellos mismos maduran y evolucionan gracias a tu apoyo y asesoramiento.

Al tener un enfoque incremental, podemos comprender mejor nuestro nivel de intervención y evitar usar demasiados sombreros o asumir más de lo que podemos masticar.

En última instancia, queremos desbloquear los superpoderes de la organización del producto. Al querer ser dueños de todo, podríamos mostrar un gran impacto inicialmente, pero a la larga, nos convertiríamos en bloqueadores de la innovación y la evolución de la organización.