En nuestra entrada de hoy de la serie de product management desde las trincheras, vamos a hablar de los equipos de producto.
Como ya sabréis los que habéis seguido la serie, fui, como CPO, el primer empleado de la práctica de producto en una compañía donde no había una función de producto dedicada, sino que más bien estaba diluida a lo largo y ancho de la organización.
Contexto Inicial#
En otras entradas hemos hablado del diagnóstico de la situación y del ancho de banda del equipo de producto una vez que estaba formado, pero eso no lo tienes desde el día uno, o al menos yo no lo tenía.
Es cierto que cuando realizas el proceso de selección para este tipo de puestos, sueles realizar un caso de negocio en el que intentas plantear los principales retos que te presenta el equipo de hiring sobre el contexto organizacional al que te vas a enfrentar (ya hablaremos de esto otro día, pero me gustaría saber vuestra opinión sobre hacer este tipo de servicios de consultoría “pro-bono” cuando aplicas a un trabajo. A mí al final es algo que me parece interesante y es como un puzzle, pero también tiene un coste de oportunidad, con lo cual la pregunta es cómo se dimensiona para que no sea demasiado tedioso para el candidato o candidata). En estos casos, normalmente, suelo introducir una visión sobre el equipo necesario para atacar los retos y propuestas de solución planteados en el caso. Como bien sabemos, el product management es un deporte de equipo y, aunque el product manager tradicionalmente es un perfil bastante generalista (más especializado en los últimos años), hay que ser consciente de que, por muy bueno que sea un product manager, no puede hacer lo de los panes y los peces.
Importancia del Equipo#
Con lo cual, para mí, lo más importante como CPO, si quería mover la aguja de la organización y tener más impacto, no me valía únicamente con influenciar desde la gestión del backlog; tenía que empezar a construir un equipo de agentes del cambio que llevaran esta práctica en la interacción diaria con los principales stakeholders. En ese sentido, lo que procuré desde etapas tempranas fue tener acceso y control sobre los equipos de desarrollo. Esto no siempre es posible, pero si lo consigues, vas a tener más control sobre tu propio destino. Entonces, en este caso, pacté con la organización y con el CTO disponer de las figuras encargadas de gestionar los equipos en esta organización, que era el equipo de los product owners (POs).
Definición de Roles#
Hay bastante literatura sobre lo que es un PO y un Product Manager (PM), y podéis echarle un vistazo al libro Inspired de Marty Cagan para una definición un poco más canónica. No me detendré en el detalle, pero para mí, un PO es un rol que viene de las metodologías ágiles y está más pegado al delivery, mientras que el PM está más pegado a la estrategia y al negocio. En este caso concreto, los POs básicamente eran escribas, o traductores de requisitos a historias de usuario, y creo que había mucho talento desaprovechado. Mi intención original era reciclar a estos POs en la medida de lo posible para convertirlos en los primeros PMs.
Organización del Equipo#
Una vez capturados estos recursos de desarrollo, iba a permitirme determinar en qué se iban a centrar los equipos. Uno de los aspectos que he aprendido a la hora de gestionar los equipos de producto es que estos tienen que estar organizados de una forma que refleje la estrategia de la compañía. Tiene que haber una intencionalidad en su definición de objetivos. Es decir, si dentro de tus líneas estratégicas está poner foco en el crecimiento, lo normal es que tengas un equipo dedicado a eso al menos un 80% de su tiempo. Por supuesto, todo depende del número de equipos con los que cuentes. No olvidemos que tener una estrategia es decidir qué es lo que no vas a hacer.
Esto se hace así porque hay estudios que indican que cuanto más estabilidad hay en el contexto de las tareas de los equipos, el rendimiento de los mismos es mayor, porque obviamente hay menos cambios de contexto que permiten una mayor concentración en el problema a resolver y hay muchas sinergias entre unas iniciativas. En cierto modo, pones a los equipos a pensar en los problemas en las tres B (del inglés Bed, Bus, and Bathroom). En organizaciones como Amazon, suelen hablar de un STL, Single Thread Leader (que es la evolución natural del two-pizza team; echadle un vistazo al libro Working Backwards para ampliar este concepto). En este caso, nuestro STL sería el PM de este equipo.
Alineamiento Estratégico#
En el contexto de una empresa adquirida por un fondo de private equity, probablemente necesites tener algún equipo dedicado a prestar atención a las necesidades de producto en torno al crecimiento inorgánico proveniente de las adquisiciones (M&A), otro equipo dedicado al BAU (business as usual), es decir, a los productos actuales y necesidades de tus clientes más mainstream, y probablemente otro equipo a iniciativas core o proyectos especiales de transformación (las reformas de la casa, que te van a llevar a la revalorización de la compañía).
Roadmap vs. Release Plan#
Por supuesto, este alineamiento de los equipos y de la estrategia estará dirigido por un artefacto comúnmente utilizado: el roadmap. Esta palabra, por otro lado, está bastante maltratada y se utiliza en varias acepciones que muchas veces van en contra de la mentalidad de producto. Sobre roadmaps también hay mucha literatura escrita; a mí me gusta particularmente el libro Roadmap Relaunch de Todd Lombardo, pero sobre todo lo que me gustaría es discernir el documento de roadmap y el documento de plan de despliegue (o release plan).
El primero es estratégico, está sujeto a cambios y sirve para tener una conversación (es una herramienta de comunicación) sobre el qué y el por qué. Normalmente, suele tener ciertos horizontes temporales, pero no suele tener compromisos de entrega (a pesar de que en determinadas situaciones sí se pueden tener; no hay que ser muy papistas. Como os dije en las primeras entradas, podría darse el caso de que tengáis un proyecto con un inicio y fin claros y, en ese caso, las fechas son un impepinable, por ejemplo, para la adaptación a una nueva regulación X).
El release plan o rollout plan es el plan de entregas, que es táctico y te cuenta el cómo, qué funcionalidades y cuándo se van a entregar. Normalmente, hay menos incertidumbre y de ahí que sea el preferido por muchas organizaciones, porque da una sensación de mayor control, aunque sea a costa de los resultados.
Recordemos que los equipos de producto se comprometen con los resultados, que precisamente es lo que defines en el roadmap, pero no se comprometen con la funcionalidad, dado que el objetivo se podría conseguir vía varias funcionalidades o varias iniciativas. En ese sentido, da más empoderamiento a los equipos.
En mi caso, al trabajar para un fondo de PE, intentaba trabajar los dos artefactos con los equipos. Sin embargo, el roadmap lo trabajábamos con un horizonte temporal mayor y el release plan lo trabajábamos más a corto, precisamente por esa diferencia en cuanto al nivel de incertidumbre.
Por otro lado, como decíamos, tener una estrategia es renunciar (Rumelt approves), pero para la parte que has decidido hacer, y como comentábamos en el post anterior, vas a tener un ancho de banda limitado para hacer cosas con los equipos. Es decir, vas a tener una capacidad instalada con la que trabajar que te va a permitir hacer más o menos cosas y, por tanto, también establecer los horizontes temporales para conseguir los resultados esperados.
Conclusión#
En resumen, la formación de los equipos de producto tiene que ser intencional y alineada con la estrategia global de tu portfolio. Hay diversos artefactos con distintos niveles de incertidumbre, así como horizontes temporales, que puedes utilizar para transmitir las iniciativas, a nivel estratégico como es el roadmap y a nivel táctico como es el release plan, y para poder establecer estos horizontes temporales e iniciativas vas a tener que tender y elaborar tu plan de capacidad.
Espero que os haya gustado esta nueva entrada. En la siguiente entrada, entraré en detalle en cómo componer los equipos de producto. ¿Os habéis enfrentado a esta situación? ¿Cómo habéis capturado vuestros recursos de desarrollo? ¿Utilizáis ambos artefactos como el roadmap y el release plan? Escribidme y lo comentamos. ¡Hasta la semana que viene!