Roadmap de Producto, Procesos y Personas
Os comparto una serie de buenas prácticas sobre cómo enfocar el Roadmap de Producto, y la importancia de tener una actitud pro-activa con un Roadmap de Procesos y Personas.
Te animo a echar un vistazo a los cursos que acabo de abrir para Mayo:
Fundamentals of Software Engineering si quieres tener una base técnica para trabajar mejor con ingeniería; puedes hacerlo a tu propio ritmo. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Fundamentals of Product Analytics si quieres empezar a ser analítico, empezando a analizar datos y definir KPIs y funnels. Puedes hacerlo a tu ritmo desde ya (self-paced), o a partir del 30 de abril en un grupo con sesiones en vivo (cohort-based).
Advanced Course in Product Analytics si quieres aprender a hacer análisis avanzados y conectar métricas de negocio con producto. La octava edición comienza el 30 de abril.
Advanced Course in Product Engineering si desde ingeniería o datos quieres acercarte a negocio y producto. La cuarta edición comienza el 30 de abril.
Las startups normalmente nos centramos en tener un Roadmap de Producto, pero nos olvidamos de trazar un plan en cuanto a qué procesos queremos mejorar y cómo hacer crecer a nuestro equipo. Os comparto una serie de buenas prácticas que me han servido todos estos años.
Roadmap de Producto
En general hay mucha confusión todavía en cuanto a los roadmaps de producto. Hay startups que no tienen porque viven en el día a día, hay otras que no tienen porque el CEO cree que la visión y plan están claros aunque el equipo no lo sepa y hay otras que no tienen porque el líder de producto o técnico se niega a comprometerse.
Este artículo no pretende profundizar en las mejores prácticas de un roadmap de producto, pero sí quiero compartir una serie de consejos:
Un roadmap sirve para debatir entre el equipo y leadership cuál es la estrategia de producto unida a la de empresa. Dónde están nuestras apuestas, y qué no vamos a hacer. Esa discusión ya es oro.
Un roadmap es un plan que da una guía a los diversos equipos para que tomen mejores decisiones. Si sabemos la idea del siguiente trimestre, ingeniería puede enfocar una funcionalidad de distinta manera. Si ventas sabe el roadmap, puede estar mas atento a necesidades de clientes para pasarnos ese feedback a producto. Como todo plan, aprenderemos y lo iteraremos cada varios meses. Un roadmap debe estar actualizado al menos cada trimestre.
Recomiendo hacer roadmaps de Outcomes. En vez de describir la funcionalidad, escribe qué impacto quieres obtener en el negocio. Si lo tenéis claro, estaréis un paso más cerca de poder usar OKRs. Puede que haya temas que sean más claros descritos como la funcionalidad o la mejora técnica; pero no abuséis porque es importante ser explícito en qué queremos conseguir en el negocio.
En el eje temporal, recomiendo usar las columnas Trimestre actual, siguiente trimestre, siguientes 6 meses y siguiente año. Por ejemplo, el roadmap actual sería Q1, Q2, H2, 2024. Cuanto más cercano más detallado y completo. 2024 son ideas grandes que no vamos a atacar este año principalmente.
Yo suelo agrupar todos los Outcomes en objetivos de empresa. Así nos aseguramos que estamos alineados con la estrategia de la empresa. Esto facilita también la decisión de cómo organizamos los diversos squads.
Recuerda comunicar el roadmap al equipo de Producto y a la empresa en general. Si no comunicamos, no obtenemos los beneficios del punto dos.
Por último, ten en cuenta que puedes tener diversos roadmaps con distinto nivel de detalle, certidumbre y lenguaje. Puedes tener uno interno, otro para clientes y otro para inversores.
En el libro Product Roadmaps Relaunched, profundizan en las mejores prácticas. Si no lo habéis leído, os lo recomiendo.
Roadmap de Procesos
El foco en procesos se suele olvidar o retrasar hasta que hay problemas en cómo se trabaja, ya sea porque hay conflictos en el equipo pequeño, o porque se crece en número de personas y equipos y la falta de procesos actuales no aguanta lo que necesita la empresa. Cuando lo haces, ya estás en una posición negativa y reactiva.
La reflexión que yo siempre hago es que un equipo siempre tiene procesos y tiene una cultura. Pueden ser implícitos, explícitos o anárquicos. Siempre hay una serie de acuerdos en como trabajamos entre los diversos roles. Esos acuerdos, forma de trabajar o cultura son los primeros procesos que estamos implementando. Por tanto, aunque nos auto-engañemos, la empresa siempre tiene unos procesos.
Muchos de vosotros habréis leído mis artículos sobre cómo implementamos los diversos procesos en Ontruck. Mi personalidad y formación ingenieril tiende a estructurar casi todo. Posiblemente me pasé en algunas áreas, pero lo cierto es que conseguimos construir uno de los mejores equipos de producto, ingeniería y datos con una cultura y unos procesos de producto fuertes y duraderos. Este viernes pasado fui al off-site de Ontruck a saludarles y daba gusto ver cómo las últimas personas se habían incorporado a esa forma de trabajar muy bien. A pesar de toda la marejada que hemos vivido estos últimos dos años, siguen siendo un equipo muy productivo.
Por tanto, mi recomendación es que seáis pro-activos y defináis una cultura y un roadmap de procesos. Esto no significa que procedimentéis todo ahora. Lo que me refiero es que seáis explícitos en cómo trabajáis ahora, y qué queréis o debéis cambiar en los siguientes trimestres. Por ejemplo, puede que este trimestre pongáis foco en conseguir unos mejores refinements y que el equipo cumpla los prints; el siguiente quarter poner foco en que ingeniería trabaje el diseño de la solución con producto, y al otro quarter conseguir que los PMs estén haciendo discovery en vez de escribir las user stories.
Si hacéis esto, el equipo tiene también una guía de dónde deben poner el foco, qué se espera de ellos y pueden contribuir con ideas y mejores prácticas. Es muy bonito ver cómo gente que era pasiva, cuando le das esa visión, se convierte en pro-activa y te sorprende para bien. Por ejemplo, llevo meses ayudando en Citibox y los ingenieros han pasado de estar desconectados de negocio a estar enfocados en las métricas (KRs) para conseguirlas.
De cara a facilitar este ejercicio, estoy desarrollando un Product Maturity Model para permitir a los equipos de producto auto-evaluarse, saber qué madurez tienen (de Non-performing a Empowered Product Team) y priorizar el foco para éste y el siguiente quarter. Ya lo he aplicado en cuatro startups y el feedback está siendo excepcional. Si quieres hacer este ejercicio en tu startup, contáctame. Contaré más sobre él en uno de los próximos artículos.
Roadmap de Personas
En la gran mayoría de startups, el roadmap de personas consiste únicamente en el número de personas que debemos contratar en el corto plazo. Nos olvidamos completamente de qué perfiles y skills necesitaremos en el medio plazo, y cómo hacer crecer al equipo actual para estar en una mejor posición en el futuro.
Os comparto una serie de buenas prácticas:
Hay que saber cuándo necesitarás gente más senior o lead, y en función de las personas actuales y tiempos, decidir si les formas y les vas probando a dar más responsabilidad, o necesitarás fichar de fuera. Si esta reflexión la haces dos meses antes, estás vendido.
Hay que decidir qué skills necesitarás y quiénes las deberán tener, para formarles y darles oportunidades de con tiempo. Por ejemplo, nosotros en Ontruck decidimos que queríamos personas versátiles (T-shaped). Por tanto, invertimos en que los diseñadores pudieran hacer desde el research hasta la UI, en que los ingenieros pudieran hacer pequeños diseños o fueran full-stack (backend + mobile/frontend) y en que los analistas de datos pudieran hacer desde la ETL hasta el análisis. Eso lleva tiempo, hay que planificarlo y darles esos espacios de experimentación y aprendizaje.
Hay que saber si los perfiles actuales van en la buena dirección con su rol actual, o ese rol se le quedará grande en el futuro. Tienes que decidir si haces un plan de formación, o tendrás que hacerles una de-promoción no traumática.
Si has definido tu cultura, debes contratar asegurando que las nuevas personas tengan ese fit cultural y contribuyan a enriquecerlo. Hay que encontrar ese balance entre incorporar gente con otra forma de trabajar que no vaya a encajar, y contratar solo gente demasiado igual que no contribuya con nuevas ideas y experiencias.
En general, todo se resume en ser pro-activo para planificar y trabajar con tiempo, en vez de encontrarse con el problema o la necesidad de frente.
De cara a trabajar con las personas, lo ideal es tener un Plan de Carrera con las expectativas por puesto y seniority, pero eso es un trabajo inmenso de mas de 6 meses. Está en mi roadmap compartir una versión que podáis utilizar como base.
Por tanto, lo que yo recomiendo es definir con cada persona tres expectativas que debe mejorar en los siguientes tres meses. Darle ese foco, formación, tiempo y feedback para que lo consiga. Cada tres meses se re-evalúa y se proponen nuevas expectativas a trabajar.
Igual que se debería revisar el Roadmap de Producto cada tres meses, lo mismo deberíamos hacer con el Roadmap de Procesos y con el de Personas. Los líderes de producto debemos tener una actitud pro-activa para acercar el futuro y asegurarnos que estaremos en la mejor situación posible. Controlemos nosotros lo que nos pase. Si no tomas acciones, los problemas que no has querido trabajar se acumularán y entrarás en un bucle negativo provocando que la startup vaya peor y tus mejores personas se vayan. ¡Sé pro-activo en los productos, procesos y personas!
Para terminar, te animo a darme feedback sobre este artículo y sugerirme temas que debería profundizar o tratar en siguientes artículos.