Publicación de Thiga España

🚨Cuando el lanzamiento de producto se convierte en tu peor pesadilla🚨 Todo iba "perfecto"... hasta que no lo fue. Semanas y semanas trabajando en el lanzamiento de un producto. El roadmap está claro (o eso crees), las funcionalidades parecen listas y la fecha de lanzamiento ya está anunciada con bombos y platillos. Pero entonces… comienzan las señales de caos. Los desarrolladores te dicen que algunas historias de usuario no cumplen con el definition of done. El equipo de QA te avisa que las pruebas de regresión no han ido bien y faltan automatizaciones críticas. Los stakeholders empiezan a presionar: "¿Cómo que vamos a retrasar la fecha? ¡Es un evento importante!". Te aferras a la idea que todo se va a solucionar con unas cuantas trasnochadas. Pero la realidad es otra: La funcionalidad estrella tiene bugs. La comunicación entre equipos se vuelve caótica. Los tiempos no cuadran, el alcance se desborda y el Go/No Go meeting parece más un ring de boxeo que una mesa de decisiones. Y ahí estás tú, un Product Manager con el café frío, la presión en el techo y el lanzamiento en la cuerda floja. 🫠 Un lanzamiento fallido no se da por un único error, sino por una suma de pequeños problemas que no se resolvieron a tiempo: ❗ Falta de planificación y visibilidad: No hubo un desglose claro de historias de usuario pequeñas y funcionales. ❗ Expectativas irreales: Nos comprometimos con una fecha fija sin ajustar la hipótesis de entrega a medida que surgían problemas. ❗ Sin variables de ajuste: No consideramos reducir el alcance o reforzar el equipo antes de que fuera demasiado tarde. ❗ Pruebas insuficientes: Las pruebas de regresión se dejaron para última hora y no priorizamos los casos críticos. ❗ No hubo una reunión Go/No Go estructurada: Nadie paró a decir "esto no está listo". El paso a paso correcto para evitar el caos 🚀 1️⃣ Planifica y proporciona visibilidad: Divide el backlog en historias de usuario pequeñas y concretas. Ten fechas hipotéticas, no absolutas, y ajústalas conforme avanza el desarrollo. 2️⃣ Define variables de ajuste: Si surgen problemas que amenazan la fecha: Retrasa el lanzamiento. Reduce el alcance (entrega menos funcionalidades, pero que funcionen bien). 3️⃣ Organiza pruebas de regresión: Prioriza los casos críticos (los más usados por el usuario). Automatiza lo que puedas para ganar tiempo. 4️⃣ Realiza un Go/No Go meeting: Reúne a las partes clave para validar si el producto está listo para desplegar. Define bien los criterios de "esto se puede lanzar". 5️⃣ Elige la estrategia de entrega adecuada: Entrega continua: Funcionalidades independientes, rápidas y con valor. Release planificado: Agrupa funcionalidades coherentes y con impacto. Un buen lanzamiento no es cuestión de suerte, es cuestión de previsión y control. Cada variable debe estar en el radar. 💬 ¿Y tú? ¿Qué problemas has enfrentado al lanzar un producto? Cuéntame tus experiencias y buenas prácticas para convertir los "caos" en lanzamientos exitosos. 🚀

La mayoría de los equipos de producto se enfocan únicamente en construir funcionalidades, gestionar sprints y releases, olvidando la pregunta fundamental: ¿Por qué estamos construyendo esto? Los productos no fracasan siempre por problemas técnicos, fracasan en gran medida por falta de una visión compartida que guíe las decisiones e impida que nos convirtamos en "fabricas de funcionalidades". Acabo de publicar una guía completa sobre cómo crear una visión de producto efectiva, incluyendo: Un Framework práctico Un Template descargable Te dejo el link en el primer comentario. #ProductManagement #productvision #BuildInPublic

A qué cosas el product owner debe decir que no? Primero, a aquellos requerimientos que son impuestos sin fundamentos o que incluso teniéndolos no pueden ser priorizados. Las cosas como son, cuando uno es PO llegan muchos pedidos de diferentes stakeholders que muchas veces no son otra cosas que soluciones pre concebidas a problemas que posiblemente no existen. La responsabilidad del PO es priorizar por valor, y para que eso pase, necesariamente debe estar abordando el dolor de un cliente o dando solución a las tareas de este de una manera más simple a cómo el cliente lo hace hoy en día. Por lo tanto, es clave decir que NO a algunos requerimientos que no mueven o muevan poco la aguja. Por otro lado, el producto owner también debe saber decir que no dentro de su squad o célula, por qué? por qué muchas veces las historias de usuario que se crean y trabajan no cumplen con el DoD (definition of done) y en estos casos, dado que es responsabilidad del PO aprobar una historia, también será el responsable de decir que NO a una aprobación de nuevas funcionalidades desarrolladas. ven algún otro motivo por el que deba decir que no? #productowner #DoD #priorizacion

Este post de la genia Catalina Diaz Saez me recordó algo importante sobre el rol de Product owner y es que es necesario tener un liderazgo capaz de sostener ese NO a los stakeholders y eso es clave para el éxito de la célula y su espíritu ágil. En distintas organizaciones me tocó ver y estar sin esa espalda lo que en concreto se tradujo en problemas con la célula que no se podían resolver dentro de la célula (y con esto se pierde el liderazgo del PO dentro de la célula) El rol PO y su capacidad de NO es crucial para priorizar el valor y no ceder frente a la "velocidad" que pueda impulsar el departamento comercial a través del dueño de la célula (que suele ser TI) y termina desvirtuando la agilidad.

Hecho significa hecho. Y cuando hablamos de “hecho”, nos referimos a que tu Definition of Done debe, como mínimo, llegar hasta que el usuario perciba el valor, es decir, hasta que llegue a Producción. No trates de aparentar en las métricas lo que no estás logrando en la realidad. Podemos engañarnos y decir que “hecho” es cuando está listo para una Release Candidate, pendiente de QA, en DEV o incluso cuando hago el primer commit. Pero al final, a tu equipo le pagan por entregar valor al usuario, y ese valor solo se entrega cuando realmente llega a sus manos. Otro día hablamos de cómo las features flags pueden mejorar tus flujos de ciclos de trabajo y desatascar cuellos de botella. Pero por ahora, quédate con la idea de que “hecho” es mucho más que simplemente “terminado”.

💣 💥 El coste de la Complejidad en la creación de Producto ⤵ ⤵ Recientemente, leí un artículo de Kris Gale, que me dejó pensando sobre un tema que muchas veces pasamos por alto: el coste de la complejidad en la creación de un producto digital. Kris Gale sostiene que la complejidad no solo incrementa los costes, sino que crea una deuda técnica que lastra la evolución de nuestros productos a largo plazo. Algunos puntos clave para mí a la hora de crear producto digital: 💢 El coste oculto de añadir características: Cada nueva característica introduce un coste marginal que puede multiplicarse exponencialmente. Lo que parece una simple feature hoy puede resultar en horas de soporte, re-factorización y mantenimiento en el futuro. Nos mentalizamos que ese “pequeño desarrollo” no es complejo implementarlo, pero nos olvidamos del ciclo de vida de producto más allá de la implementación inicial. Un ejemplo, cuando añadimos una nueva opción en la configuración del producto. Puede parecer algo pequeño, pero ¿cómo afecta al onboarding de nuevos usuarios? ¿Cuántas nuevas prueba deberemos cubrir? ¿afecta a la infraestructura subyacente?, etc. 💢 Convertimos Bugs en "features": Curiosamente, Gale habla de cómo algunas veces los comportamientos inesperados o bugs terminan siendo parte del producto por inercia. Esto no solo añade complejidad, sino que genera expectativas falsas en los usuarios y dificulta su manejo en futuras actualizaciones. 💢 El impacto en la velocidad del equipo: Gale también resalta que la velocidad no depende solo del esfuerzo individual, sino de cómo manejamos la complejidad colectiva. A veces, la clave no es trabajar más rápido, sino simplificar el sistema desde el inicio para que futuras iteraciones sean más ágiles. 💢 El papel del Product Manager en la simplicidad: Los Product Managers juegan un rol vital en mantener la simplicidad. Gale sugiere que, en lugar de preguntar "¿qué tan difícil sería?", deberíamos plantearnos "¿cómo aumenta la complejidad con esta nueva funcionalidad?". 🎯 Mi pregunta es: ¿Cómo manejáis vosotros la complejidad en vuestros equipos? ¿Analizáis el impacto a largo plazo en el ciclo completo de producto antes de añadir nuevas funcionalidades? #productmanagement #product #innovation

La realidad es que a tus clientes NO les importa: → Si tu producto fue difícil de construir. → Si invertiste muchos recursos en él. → Si tus stakeholders están felices. → Si usaste Scrum para construirlo. → Si tu producto tiene varias funcionalidades. → Si para usarlo solo necesitas hacer X clics. → Si usaste X tecnología. Lo único que les importa es si resolvieron su problema. Todo lo demás es secundario. #ProductRocks

Las historias de usuario son las que definen desde un inicio cual será la entrega del equipo, si están creadas sin sentido para el cliente la entrega tampoco tendrá sentido para el cliente. ¿Sientes que tu equipo trabaja guiado por unas buenas historias de usuario? Si sientes que deben mejorar, puedes adquirir un curso empresarial con Cris Rúa, escríbenos: +573246476262 💙 #scrum #userstories #historiasdeusuario #productowner #criteriosdeaceptacion #crisrua

SENTRIO permite a los #ProductOwners gestionar eficazmente sus proyectos con paneles intuitivos y herramientas predictivas. La plataforma ofrece una visión completa del estado de los productos digitales y predice la fecha estimada de finalización con el #Burndown Global. Además, ayuda a corregir el rumbo del proyecto y a reducir riesgos. 🔍 ¿Qué métricas clave de gestión de errores puedes analizar con SENTRIO? ➡️ Change Failure Rate ➡️ Mean Time to Recovery ➡️ Mean Time Between Failures ¡Optimiza flujos de trabajo y asegura entregas puntuales! Pide una demo gratuita de SENTRIO aquí 👉 https://buff.ly/3ZLJQjk #ProductManagement #Agile #VSM #ValueStreamManagement #DevOps

Cómo ser PO/PM/Lider de Equipos de Desarrollo, y matarlos en el intento… (y de paso, morir también), o para los que gusten de titulares más doctos: Antipatrones de un PO/PM/Lider de Equipos de Desarrollo: ❌ Di que si siempre a todas las ideas y propuestas, sueños y aspiraciones de la alta administración y al negocio, sin buscar la justificación del aporte de valor que están haciendo; ❌ Con lo anterior, cámbiale las prioridades a tu(s) célula(s), especialmente al medio o a los 2/3 del Sprint. El Dev Team no te olvidará… ❌ Planifica e idea el producto solo, sin ayuda de nadie, no le preguntes ni al negocio ni a los stakeholders… Es más, improvisa y no declares el Product Goal… ❌ No escales ni con la PMO ni de forma directa a tu Sponsor y Negocio el roadmap y como este evoluciona en el tiempo… ❌ Llena el PB de HU como si fueran detalles de requerimientos hasta el más mínimo rincón… y nunca, nunca, dejes que sea un instrumento vivo… No aceptes cambios… ❌ Que tu producto, en su primera salida, no te avergüence un poquito…sino que se encuentre perfecto, hasta el último detalle y con el 100% de funcionalidad construida… que lo complejo sustituya a lo simple… ❌ No dejes que el equipo se auto organice, dales órdenes e instrucciones de cómo tienen que evaluar y hacer sus tareas… ❌ Pide estados de avance al ScrumMaster, o mejor aún, asiste a las dailys para escuchar estados de avance… ❌ Si tuviste incidentes en Producción, deja que Continuidad Operativa se preocupe, ya no es tu problema…