En la entrada anterior de nuestra serie ‘Product Management desde las Trincheras’, exploramos cómo enriquecer el backlog para una mejor visión estratégica. Hoy, vamos a avanzar sobre esta base para abordar cómo gestionar de manera efectiva el ancho de banda de los equipos de producto, un desafío crítico para cualquier CPO.
Desafios Iniciales#
Cuando empecé a trabajar como CPO, aunque varios equipos ya trabajaban con metodologías ágiles, no existía un mecanismo claro para la priorización y asignación de iniciativas, en realidad no es que no lo hubiera, se asignaban las épicas en base: 1) al track record de las funcionalidades que había hecho un equipo, si un equipo había hecho una funcionalidad se intentaba mantener ese equipo para las mejoras de esa funcionalidad 2) si era una funcionalidad nueva, se hacía una especie de round robin, teniendo en cuenta lo que un product owner (PO de aquí en adelante) pensaba que el equipo podría absorber, en resumen se trabajaba un poco como una fábrica de funcionalidades (del inglés feature factory) sin pensar mucho en la estrategia de los equipos.
Con esta situación de partida de unos equipos ya trabajando y yo recién llegado, mi principal pregunta a resolver era cuanto ancho de banda había disponible para hacer producto y eso pasaba por entender ¿qué estaban haciendo los equipos de desarrollo (que pronto serían de producto)? ¿y si estaban construyendo las cosas correctas que había que construir?.
Vamos a desgranar un poco más cada pregunta, respecto a la primera, con el backlog enriquecido que vimos en la entrada de la semana pasada, podía entender algunas de las iniciativas pero no tenía una foto completa de a qué dedicaban el tiempo sus equipos, con lo que decidí hacer un poco de genchi genbutsu, que significa ir directamente al lugar donde ocurren las cosas para entender mejor los procesos, hablar con los products owners y entender su día a día más allá que la mera sesión de priorización y me di cuenta que los POs estaban 1) escribiendo todas las historias de usuario 2) proporcionando ayuda técnica a los developers 3) realizando tareas operativas de explotación del servicio entre otras cosas 4) que les inundaban a peticiones por tierra, mar y aire: a parte de las iniciativas priorizadas, había multitud de stakeholders que les hacían llegar tareas, por email, por whatsapp, por una conversación de pasillo, de manera muy informal y sin mucho detalle y asumían (equivocadamente) que el PO tenía que tomar nota de la comanda para realizar la tarea equivalente, con los consecuentes lios correspondientes.
La segunda pregunta tiene que ver más con la estrategia y los objetivos a cumplir de la compañía, es decir, ¿qué porcentaje de las cosas que estabamos haciendo era en la dirección que la compañía se había planteado hacer? Es decir, como se alineaban esas iniciativas con los objetivos estratégicos de la compañía, con el backlog enriquecido empezabamos a asignar, pero no teníamos una foto de alto nivel, teníamos un nivel de zoom muy elevado con lo cual no nos permitía estar en el nivel de abstracción correcto para tomar decisiones más estratégicas.
También de la entrada de la semana pasada, habíamos comentado que típicamente los equipos pueden dividir las tareas del día a día en tres categorías:
- Lo que denomino features, permitidme añadir aquí algo más de detalle que no incluí la semana pasada, cuando comento la creación de valor, es un abuso del lenguaje porque como PM, en mi modelo mental, cada funcionalidad tiene que servir a un propósito y puede ser creación de valor, como generación de revenue, mejorar el engagement con los clientes o simplemente ser una funcionalidad higiénica, es decir, que si no la tienes puede producir rechazo a tus clientes, realmente no aporta mucho valor pero la tienes que tener (ejemplo, el login de usuarios). De igual manera, un CPO tiene que entender que cada producto sirve a un propósito pero de esto hablaremos otro día.
- las tareas operativas repetitivas
- los bugs
Por otro lado, como personas responsables de producto, una de nuestras principales armas son los datos que nos permiten tomar decisiones informadas sobre nuestros roadmaps y las iniciativas que llevamos a cabo, ya hablaré en otra entrada pero uno de los principios que intento establecer en mis equipos es el de ser equipos data-driven o como reza la frase de la NASA, “In God we trust, all others bring data”. En mi contexto, al no haber la función de gestión de producto anteriormente y supongo que por desconocimiento, no había mucha información disponible para tomar este tipo de decisiones más allá que la herramienta que tenían los equipos de desarrollo para documentar el proceso agile (en este caso una herramienta tipo Jira basado en tickets) y cuyo módulo de reportes no estaba muy trabajado.
Con lo cual, repasemos la situación, no teníamos mucha idea del ancho de banda que tenían los equipos para trabajar en producto, las tareas de distintos tipos venía de una forma muy desestructurada, no teníamos acceso a muchos datos y las herramientas que había disponibles no se habían trabajado para tener unos buenos reportes.
Implementación de soluciones#
Con lo cual en aras de atacar esta problemática y nuevamente acudiendo a los primeros principios sin entrar en cojo-herramientas, lo que decidí implementar fueron tres formularios en Google Forms, uno para cada tipo de tarea 1) funcionalidades 2) tareas operativas y 3) bugs. Esta acción tan sencilla me iban a permitir conseguir cuatro objetivos:
- Homegeneizar la entrada de la información, permitiendo una mejora de la calidad de la misma y proporcionando el detalle necesario para que esa información sea accionable y priorizable.
- Frenar la llegada masiva de peticiones, al poner cierta fricción, a pesar de que los formularios eran sencillos, el mero hecho de que el stakeholder se tuviera que parar a pensar y a escribir las preguntas que le hacíamos, le hacía reflexionar sobre la propia necesidad de la funcionalidad, con lo cual solo se abría la petición cuando era realmente necesario, a veces un poquito de fricción es algo bueno.
- Empezar a tener datos sobre la volumetría de las peticiones a los equipos para entender el ancho de banda dedicado a cada tipo de petición: funcionalides, tareas operativas y bugs. Una nota aquí para los más cafeteros del product management, obviamente lo ideal sería trabajar los datos con respecto al impacto de las iniciativas en los objetivos de tu estrategia, pero estábamos tan lejos de ese mindset que esta aproximación me pareció un buen equilibrio, conclusión: si no puedes empezar por medir outcomes e impacto, empieza por output y ya irás iterando.
- Al tener la información homogeneizada, en un único lugar como era las hojas de calculo asociadas a los formulario, iba a sentar las bases para crear unos cuadros de mando sobre el backlog de tareas para entender la dirección de los equipos.
Adicionalmente a estos formularios, le añadimos un pequeño desarrollo interno, que eran un par de App Scripts que permitían pasar la información de estos formularios al backlog enriquecido una vez cualificada la información procedente en los formularios.
Resultados y observaciones#
Después de implementar este mecanismo con los formularios de Google notamos una reducción de más del 50% de las peticiones informales e incrementamos la velocidad de entrega de los equipos al no tener que estar persiguiendo a los stakeholders para levantar la información que necesitaban para trabajar, además de permitirnos ajustar las cargas de trabajo con mayor precisión y alineación estratégica.
Con lo cual si vemos una foto parcial de nuestro sistema operativo de producto hasta ahora, centrándonos en el espacio del problema tendríamos algo así (en otras entradas pintaremos una foto de todo este sistema operativo de producto v1):
En el diagrama, cada forma representa un aspecto distinto de nuestros procesos de producto. En naranja aquellos procesos derivados de la utilización de los formularios para hacer una cualificación de la petición y si es de alto impacto agregarla a la sesión de priorización para tener una breve charla sobre los mismos, si no tuviera alto impacto, quedaba a la potestad de cada equipo el decidir qué hacer con la petición, si rechazarla o hacerla. Esto permitiría poco a poco darle ese empoderamiento necesario a los equipos de producto.
Por otro lado en verde, he querido plasmar la relación con el resto de stakeholders con el que como CPO, tenía sesiones recurrentes de alineamiento para revisar las necesidades que pudieran tener con respecto al equipo de producto. Nuevamente cada una de estas peticiones eran evaluadas en cuanto a valor y viabilidad tecnológica antes de añadirlas al backlog.
Conclusiones#
En resumen, en esta entrada hemos aprendido lo importante que es conocer el ancho de banda que tienen tus equipos para dedicarse a crear valor y que con pequeñas herramientas que nos permitan introducir un punto de reflexión, homegeneización y estructura vamos a ser capaces de construirnos una pequeña brújula de producto basada en los entregables de los equipos de producto (en inglés outputs) en un entorno donde todavía la mentalidad de producto se está construyendo.
En la entrada de la semana que viene veremos como construir los cuadros de mando utilizando esta información estructurada.
Espero que os haya gustado la entrada, contadme si os habéis enfrentado a este tipo de situaciones vosotros, ¿Cómo las habéis resuelto?, ¿hubierais directamente establecido mediciones en torno al impacto?. ¡Escribidme para contarme!