Introducción y contexto#
En esta nueva entrada de la serie “Product management desde las trincheras” me voy a centrar en mis primeros pasos a la hora de priorizar las primeras acciones a realizar por los equipos, o como a mi me gusta llamarlo, separar el grano de la paja, y empezar a priorizar el backlog de iniciativas a nivel de CPO.
Para los lectores que os encontréis leyendo este post sin haber leído el resto de entradas de la serie, a parte de recomendaros que leaís la serie desde el principio, permitidme recordar un poco el contexto, estamos en una scale-up empresa incumbente de la industria con un product-market fit alcanzado pero donde no había la práctica de product management como tal, esta empresa es adquirida por un fondo de private equity, y traen a un CPO para profesionalizar la forma de poner en marcha las iniciativas que resuelvan las necesidades de sus clientes.
Lo primero que me gustaría destacar aquí es que priorizar el conjunto de iniciativas a nivel de CPO, no es lo mismo que priorizar el backlog de un producto aunque se pueda hacer de forma muy parecida. A nivel de CPO, se trata de seleccionar las oportunidades estratégicas y esta priorización tiene como objetivo construir y fortalecer nuestras ventajas competitivas como organización, eso requiere entender el posicionamiento estratégico de la compañía, la dinámica competitiva de la industria y además tenerlo en cuenta en varios horizontes temporales (pensad en el framework de los tres horizontes de McKinsey)
Os comentaba en la anterior entrada también que los orígenes de priorización en esta empresa, era una reunión semanal donde se reunían los recursos más caros de la compañía para indicar qué funcionalidades y tareas se iban a realizar, y con la consiguiente falta de empoderamiento de los equipos y retrasos derivados de la dependencia de los ejecutivos a la hora de resolver dudas.
Priorización Estratégica: Más Allá del Roadmap Tradicional#
Con este contexto en mente, mi intención para el post de hoy es jugar un poco al roadmap-nova (para los más jovenes, hago referencia a una serie de juegos de mesa que salieron por los años 90 con los que podrías aprender disciplinas muy diversas: alfanova para aprender a hacer cacharros con arcilla, volcanova para saber como funcionaba un volcan, serigrafic-nova para aprender a serigrafiar, choconova para hacer figuritas de chocolate, y un largo etcetera, os dejo aquí un enlace para los más nostálgicos o por si queréis ampliar el detalle), entonces vamos a diseñar nuestro propio backlog.
Hay muchas herramientas en el mercado para crear y gestionar backlogs: Trello, Jira, Youtrack, productboard, dragonboat, etc, y son grandes herramientas que realizan muy bien su función y no tengo nada en contra de ellas. Sin embargo, aquí me voy a centrar en qué componentes debe tener cada entrada del backlog y que sirven a distintos propósitos pero nos van a permitir tener un buen entendimiento de la iniciativa, para qué sirve, qué impacto tiene, qué equipo está trabajando en ella y cómo encaja dentro de la estrategia de la compañía.
Por otro lado, en mi experiencia he aprendido que fácilmente nos emocionamos con la implementación de las herramientas, yo el primero, porque obviamente tiene su impulso de productividad, puesta en marcha y no nos damos cuenta del coste que eso tiene, y porque en mi caso en concreto, nadie tenía ese mindset de product management, con lo cual no podía pasar de 0 a 100 en poco tiempo, tenía que ir construyendo esa mentalidad y esa práctica de product management poco a poco con lo cual mi aproximación en este contexto fue abordar la situación desde los primeros principios, para evitar entrar en un proceso de establecer los requisitos, buscar los proveedores de herramientas, hablar con ellos, adquirir la herramienta, onboarding y configuración de la misma, hacer un training a los equipos correspondientes, etc.
Y aquí me gustaría detenerme brevemente para comentar tres conceptos implícitos en el párrafo anterior, que a lo mejor no son tan evidentes, pero que te pueden ayudar si te ves inmerso o inmersa en un berenjenal de tal calibre.
El primer concepto es el de “la fábrica es el producto”, cómo CPO una de entre tus múltiples misiones, es la de “ordenar la casa”, establecer el conjunto de procesos y dinámicas dentro de la organización para que el producto salga bien de la fábrica, con lo cual no te tienes que preocupar tanto del detalle de grano fino del último byte de la última funcionalidad, sino que te tienes que preocupar que todo el ciclo de vida de producto a nivel de organización funcione bien, con esto lo que quiero decir que hay que prestar atención al proceso de realizar el producto y no al resultado del producto en si mismo (qué también pero eso ya se lo dejas a tus equipos).
Ojo, que no estoy diciendo que esto último no sea relevante, sólo que en mi experiencia el resultado va a depender de muchas otras variables que probablemente estén fuera de control, este último concepto lo aprendí de Jaime Rodríguez de Santiago en su podcast Kaizen y no puedo estar más de acuerdo con él, el resultado de una acción no determina si está decisión fue buena o mala, sino el proceso de la toma de la decisión es lo que hace buena o mala la propia decisión y de ahí que yo me lo lleve al concepto de “la fábrica es el producto”. Por cierto parece que esta frase es atribuida a Taiichi Ohno, que fue un ingeniero industrial japones y uno de los creadores del sistema de producción de Toyota, también conocido como Lean Manufacturing.
El segundo concepto que quería mencionar es el de la zona de desarrollo próximo o en inglés zone of proximal development, que básicamente indica que cuando dos personas con niveles muy separados de entendimiento sobre un determinado tema, será difícil que mantengan una conversación fructífera sobre el mismo, y que el aprendiz necesitará cierta supervisión y soporte para rellenar ese espacio de conocimiento, que es precisamente lo que me pasaba a mi en esta compañía, que nadie sabía lo que hacía un product manager, entonces estableciendo un backlog enriquecido conseguía entrenar sus mentes hacia este mindset.
El tercer y último concepto que me gustaría comentar es un aspecto que aprendí en el master de coaching y mentoring de UNIR, y es que en cierto modo, pensamientos, comportamientos y emociones están conectados, no me voy a detener mucho sobre esto porque hay bastante literatura, pero básicamente cuando estas en un proceso de transformación no puedes ir con una varita mágica cambiando las cabezas de las personas para que piensen de otra manera, en este caso yo quería cambiar sus pensamientos a través de forzar un cambio en su comportamiento, en este caso a la hora de rellenar la información del backlog, estaba reutilizando esta ceremonia de priorización para mi propósito.
Por cierto nótese la interdisciplinaridad aplicada en todo este proceso, hemos tomado conceptos de varias disciplinas y nos los hemos llevado a la gestión de producto, que para mi entendimiento está muy cercano a lo que es un problema complejo (CPSer approves)
Conclusión, que no necesitáis la cojoherramienta para tener un backlog optimizado y efectivo, yo en mi caso lo hice con Google Sheets, que era la herramienta que ya estaban utilizando y lo que me dediqué fue a enriquecerlo. Esto me recuerda aquella a este meme:
Diseñando un Backlog Efectivo: Componentes y Estrategias Clave#
Entonces, volviendo a la idea de cómo diseño mi propio backlog, o dicho de otra manera, qué elementos son interesantes para cada entrada del backlog, entiendo cada entrada como una breve descripción de la iniciativa y un identificador de la misma.
Cómo se trata de priorizar obviamente un aspecto muy importante es el mecanismo de priorización, que hay muchísimos, pero a mi me gusta utilizar un ICE modificado. La idea fundamental detrás de este miniframework, es entender el valor o el impacto que la iniciativa en cuestión va a tener con respecto al esfuerzo que requiere, obviamente vas a querer hacer primero las iniciativas que aporten mayor valor con menor esfuerzo, y luego lo que haces es una corrección de la prioridad introduciendo un nivel de confianza sobre tu predicción, que en mi caso este nivel de confianza, lo establecía en base al nivel de definición de la iniciativa, esto esta directamente correlado con el nivel de incertidumbre de la misma, luego para mi a mayor nivel de definición, mayor entendimiento de lo que tengo que hacer, mayor confianza sobre lo que tengo que hacer. Este concepto se refleja muy bien con el hill chart de basecamp, os dejo aquí el enlace.
En mi caso ese nivel de certidumbre venía definido por varios eventos o casuísticas:
- a veces tenía iniciativas heredadas en las que los PO ya tenían escrito las historias de usuario pero se habían despriorizado, con lo cual había un entendimiento claro de lo que había que hacer, ergo poca incertidumbre
- que hubiera pasado el equipo de UX Research por esta iniciativa y viniera en base a necesidades detectadas en los clientes, pues esto ya me da ciertas garantías de la necesidad
- que hubiera un documento de lo que yo llamo inception, que es un poco mi definición de product requirement document o PRD, en otra entrada hablaré de cual es la plantilla que intento tener para esta definición de la iniciativa o funcionalidad
- que hubiera un compromiso con algún cliente (un contrato o pago)
- que fuera un tema de compliance (cumplir con la regulación porque fuera a haber una auditoría por ejemplo).
Cada una de estas casuísticas era un parámetro a rellenar del backlog y cada una modificaba el ratio valor vs esfuerzo a la baja según el nivel de incertidumbre. Os pongo un ejemplo para que se entienda, imaginemos que tenemos la iniciativa A, que después de tener una conversación decidimos que aporta un valor de talla camiseta L (asumamos que solo tenemos cinco niveles con lo cual, L sería 3 en valor), de la misma manera definimos que el esfuerzo es algo medio, talla camiseta M (que en valor sería un 2), eso nos da una priorización provisional de 3/2 = 1.5, entonces ahora vamos a hacer la corrección, ¿están las historias de usuario escritas, ha pasado UX por allí o tengo un documento de inception? Si es que no, multiplico por 80%, ergo le estoy bajando la prioridad, vamos al siguiente evento, es algo que es un tema de compliance, si es que si pues entonces multiplico por 100% porque es casi obligatorio tenerlo con lo cual le tengo que dar prioridad, en total si multiplicamos todos los valores nos queda que tenemos una prioridad de 1.5x0.8x1 = 1.2. Al final se trata de hacerte un modelo de confianza en base a tus dimensiones de incertidumbre.
En cualquier caso, un nuevo disclaimer, aquí no se trata, de poner el numerito bien en el framework, primero porque los humanos somos malísmos midiendo en términos absolutos, sino que intentas relativizar con el resto de iniciativas, se trata de fomentar una conversación en base a los cuatro riesgos del product management: valor, usabilidad, viabilidad y rentabilidad (estos conceptos los podéis ver en el libro de Inspired de Marty Cagan.
La segunda parte de enriquecimiento es la parte de categorización o taxonomía, esta parte lo que busca es tener una manera de agrupar las iniciativas, por varias razones:
- estás curando la información y homogeneizandola para luego
- sobre este backlog vamos a construir una serie de dashboards que nos van a permitir entender donde están poniendo los esfuerzos los equipos y por extensión tu foco estratégico, a mi me gusta decir que estos dashboards van a ser tu brújula de producto
- estás elevando la conversación más allá de la iniciativa y estas haciendo pensar en un nivel de abstracción distinto en un plano más estratégico
Estas categorizaciones para mi incluyen al menos:
- Producto al que se refiere la iniciativa
- Categoría de la iniciativa pueden referirse a un modulo de un producto, a una determinada problematica dentro de tus productos, etc.
- Cliente, si estás en un negocio B2B enterprise y tus clientes tienen mucho poder de negociación podría haber iniciativas exclusivas para clientes.
- Temática estratégico, dentro de las iniciativas estratégicas del roadmap de tu portfolio donde estaría situada la iniciativa en cuestión, esto es una lista mutuamente excluyente, si no eres capaz de situarla en un ningún theme estratégico probablemente no tendrías que hacer esta iniciativa.
- Muy relacionada con la anterior estaría el objetivo que persigue la iniciativa: mejorar la UX, customer engagement, incrementar el share of wallet, captar nuevos clientes, etc.
- La última de las categorizaciones que me gusta añadir es la del stakeholder, entender si hay alguna persona que es la fuente de esta iniciativa, por ejemplo si es una iniciativa que estás haciendo para el CRO o para el CMO, esto es importante para también saber a quien acudir en caso de alguna duda.
La tercera parte del enriquecimiento tiene más que ver con el delivery, pero que me parece más relevante a la hora de generarte los artefactos y mecanismos para poder debatir con la directiva las implicaciones de incluir nuevas iniciativas, además de nuevamente a elevar la conversación a un nivel de abstracción superior:
Este componente se podría haber añadido en la fase anterior pero la he incluido aquí porque tiene que ver más con la capacidad que tienen los equipos, esta categoría adicional es distinguir si la iniciativa es de tipo: 1) Funcionalidad, 2) Tarea operativa o 3) Resolver un bug. Y ¿por qué me interesa categorizar esto?, porque cuando me construyo los dashboards y veo a que se están dedicando los equipos puedo entender el ancho de banda que tengo disponible para generar valor (y construir mi roadmap en base a un mínimo plan de capacidad):
- Si están dedicándose a crear valor es decir a hacer funcionalidades, todo ok, habría que ver que están en las líneas estratégicas que quieres.
- Si se están dedicando a resolver tareas operativas, probablemente esto se derive de una falta de cobertura de la superficie de producto o de la deuda técnica, esto puede ser un indicativo que tienes que realizar funcionalidades nuevas si quieres liberar a tu equipo de este trabajo tedioso y repetitivo (esto se define muy bien en el concepto de toil en el contexto de Site reliability engineering).
- Si se están dedicando a resolver bugs la mayor parte del tiempo, igual es que tienes un problema de calidad en los equipos, y tienes que trabajar con el CTO para una mejora en las entregas.
La otra parte que me gusta entender es una pequeña medición de los tiempos:
- Lead time: el tiempo que pasa una iniciativa en el backlog hasta que nos ponemos a hacerla
- Completion time: el tiempo que tardamos en hacerla
- Time to market: el tiempo total que tardamos desde que somos conscientes de que hay que lanzar la iniciativa hasta que la ponemos delante del cliente
Luego para cada nivel de esfuerzo saco en los dashboards estos tiempos, y esto te permite tener conversaciones con tu CEO, cuando te llega una mañana después de haber leído el último número de la revista Forbes y decirte, tenemos que hacer [”Inserte aquí la tendencia del momento”] y tu le puedas decir, vale perfecto, supongamos que es de complejidad en tamaño de camiseta L, tu tienes un track record de que tus iniciativas de talla L tardas 90 días en ponerlas en producción, entonces puedes decirle tardamos 90 días en tenerla si va razonablemente bien, ¿vamos adelante?. Una breve nota al hilo de esto, antes de comentar esto le haría dos preguntas, ¿qué equipo cuento para hacer esto? Normalmente la respuesta es que no va a venir la caballería y segundo ¿que quieres quitar del roadmap para que podamos establecer esta iniciativa?. Tener una estrategia es renunciar a cosas, y el trabajo del CPO y de un PM es decir a muchas cosas que no, pero también he aprendido a que hay que llegar a situaciones de compromiso e intentar acercar posturas, con lo cual mi consejo es cuando tengáis este tipo de conversaciones, no acorraléis a la otra persona en una situación que no tenga salida, dejadle una puerta abierta, que sea normalmente la que vosotros queréis porque sino puedes generar mucha frustración y eso te puede traer bastantes problemas.
Finalmente el equipo responsable de esta iniciativa.
Fundamentos y Conceptos Clave para el Éxito en Product Management#
Hay un aspecto que he dejado fuera de este artículo a propósito, y es que obviamente todo este enriquecimiento y toma de decisiones va a tener que estar alineado con el roadmap, no lo he hecho así, primero por el contexto en el que sucedió, empece a enriquecer el contexto del backlog porque una cosa que tenemos que tener en cuenta es que no puedes parar una compañía para tomar tu decisión, sino que tenía que construir esa mentalidad de producto sin parar maquinas con lo cual tenía que ir haciendo pequeños cambios que me llevaran en esa dirección, segundo que obviamente ya había una inercia y unos compromisos con lo cual este mecanismo era una retroalimentación para también construir mi roadmap estratégico y tercero porque hacer producto no es un proceso lineal, normalmente cuando contamos estas cosas en las clases de The Hero Camp se suelen contar en un proceso secuencial de tres partes: estrategia, discovery y delivery, pero la realidad es que no es lineal y todo estos procesos se retroalimentan y unos hacen que cambies tu estrategia, otros tus funcionalidades, etc. Echad un vistazo al libro de Nacho Bassino, Product Direction que esto lo cuenta muy bien.
Esta aproximación también difiere un poco de mi mentalidad de producto más “pura” por así decirlo y es que está muy centrada en la iniciativa en lugar del resultado, para mi la diferencia de un buen equipo de producto es que este se compromete con el resultado y te da igual el número de iniciativas que hagas para conseguir ese resultado porque el equipo tiene el empoderamiento necesario para tomar esas decisiones sobre que iniciativas abordar, pero nuevamente aquí el contexto manda, en esta empresa el nivel de madurez de la disciplina, así como del entendimiento de la organización no permitía en mi humilde opinión seguir este tipo de aproximación.
El propósito final es fallar rápido y barato, ajustando tu tasa de aprendizaje para poner delante de tu cliente aquellas soluciones a sus problemas que aporten valor y por las que estén dispuestos a pagar, cuanto más deprisa aprendas, más oportunidades de evolucionar tu producto tienes y por tanto mayor capacidad de adaptación vas a tener para abordar los retos que se te plantean.
En esta entrada soy consciente de que tampoco he hablado de como llegan estas iniciativas al backlog, eso forma parte de lo que denomino el sistema operativo de producto y que contaré en futuras entradas.
Conclusión: Claves para Mejorar la Toma de Decisiones y Estrategias de Backlog#
En resumen, los elementos descritos en esta entrada: la priorización, la categorización y el delivery, serían todos los que yo buscaría tener en un backlog enriquecido que nos permitiera a todos tomar mejores decisiones sin tener que involucrar los recursos más caros de la organización, que nos va a ayudar a elevar la conversación a un plano más estratégico y también establecer un lenguaje común a la hora de abordar la priorización de iniciativas, y por extensión dándole un mayor empoderamiento a los equipos para decidir que se hace primero y qué se hace después. Además al hacer la curación de los datos vamos a poder construir una serie de cuadros de mandos que nos permitan llevar el barco a buen puerto pero de esto también os hablaré en otros artículos.
Espero que os haya gustado esta entrada, ¿cómo enriqueceis vosotros vuestros backlogs?, ¿qué herramientas utilizais?, ¿Cómo construis vuestra brújula de producto?, escribidme para contarme como mejoraríais esta aproximación, ¿hubierais hecho lo mismo?