Por Ricardo Colusso
Una guía para detectar y resolver problemas frecuentes del Product Management Digital
La adopción de los valores, principios y herramientas ágiles para el desarrollo de productos está acelerando la transformación digital en las empresas porque nos permite contar con equipos empoderados y efectivos, reducir riesgos a través de desarrollos iterativos-incrementales, y realizar mejores estimaciones para ser más predecibles.
Sin embargo los métodos ágiles no nos ayudan a liberarnos de lo que Melissa Perri llama “The Build Trap” (la trampa de construir), que podría resumirse como el poner demasiado foco en incluir todas las funcionalidades posibles en un producto y cuánto más rápido . . . mejor!!!, pero sin tomarnos el tiempo de validar previamente si lo que queremos desarrollar resolverá problemas reales de los usuarios de una manera efectiva y atractiva.
“El desarrollo de productos no es fácil. De hecho, la mayoría de los esfuerzos en desarrollar productos fallan, y la razón más frecuente es que desarrollamos el producto equivocado.”
Henrik Kniberg (ver cita original en inglés)
En este artículo encontrarás:
- Una revisión de las diferencias entre Product Delivery/Product Discovery y entre Outputs/Outcomes
- Cinco maneras de detectar si el desarrollo de tu producto va en una dirección incorrecta
- Un conjunto de repelentes y antídotos para prevenir y remediar a tiempo una posible caída en “la trampa de construir”
Outputs/Outcomes, Product Delivery/Product Discovery
Para comenzar vamos a revisar cuatro conceptos importantes del Product Management Digital:
Outputs
La cantidad de software funcionando que entrega un equipo de producto, medida en funcionalidades, story points, etc.
Outcomes
Los impactos (beneficios) que genera un equipo de producto en usuarios, clientes y el negocio
Product Delivery
a) todas las tareas relacionadas con desarrollar y poner en producción funcionalidades nuevas o mejoradas en el producto o también
b) lo que el equipo desarrolla
Product Discovery
todas las actividades y herramientas orientadas a entender qué necesitan los clientes para validar tempranamente si nuestro producto:
- Resolverá problemas relevantes
- Brindará valor a usuarios y cliente
- Producirá los resultados de negocio esperados
De los cuatro conceptos anteriores resulta que:
- Si las métricas de éxito de un equipo de producto y una transformación digital consisten en OKRs (Objective Key Results) asociados a Outcomes sabremos en todo momento si estamos avanzando o no en la dirección correcta.
- Si realizamos actividades continuas de Product Discovery sobre funcionalidades planeadas antes de desarrollarlas -validando que resuelvan efectivamente problemas de los usuarios, les resulten atractivas y aporten a nuestros objetivos de negocio — , reduciremos la incertidumbre y el riesgo de crear algo que luego no sirva, no se use o no esté alineado con lo que queremos lograr.
El problema de medir Outputs
Métricas de Output tales como las cantidades de story points o de user stories entregadas por Sprint nos distraen de la visión del producto y nuestros objetivos de negocio. De esa forma quedamos más propensos a caer en la trampa de trabajar a destajo para agregar más funcionalidad porque sí, sin darnos tiempo para validarlas con usuarios reales, resultando en productos generalmente más complejos y menos atractivos.
¿Cómo detectamos que estamos cayendo en la trampa de sólo construir porque sí?
Aquí van algunos síntomas:
1- Las expectativas y promesas de adopción o retorno a la inversión no se cumplen, lo cual se atribuye a que el producto aún no cuenta con funcionalidad suficiente. (“Cuando el producto permita realizar X, Y & Z, ahí sí vamos a tener muchos más usuarios!”)
2- El producto tiene muchas funcionalidades que pocos usuarios aprovechan, y los diseñadores tienen que hacer malabares para asegurar una usabilidad aceptable. (“Sabemos que cada tipo de usuario necesita sólo el 20% de la funcionalidad total, pero cada diferente tipo de usuario necesitan un 20% distinto!”)
3- Hay un backlog kilométrico que incluye toda la funcionalidad que apriori consideramos crítica e indispensable, pero cuyo real valor no ha sido validado con usuarios y clientes reales (“Tenemos todo el roadmap programado y al equipo repleto de trabajo para los próximos 18 meses”)
4- Historias de usuario impuestas a presión por uno o varios Stakeholders, pero que no fueron validadas con usuarios y clientes reales en sus contextos (“Esto lo pidió el CEO!”)
5- Historias de usuario que no recorren un ciclo de vida completo porque debemos tenerlas refinadas de modo urgente para que el equipo de desarrollo siga generando outputs (“¡Necesitamos que tengan trabajo para el próximo Sprint!”)
Finalmente, ¿cuáles son los antídotos y repelentes contra el desarrollo de funcionalidades que terminan siendo un desperdicio?
- Para evitar entrar en el modo vertiginoso del Product Delivery al 100% sugerimos comenzar a conocer el mindset de Product Delivery y utilizar algunos de sus conceptos, prácticas y herramientas.
- Si percibes que en tu equipo y organización están obsesionados con Product Delivery y los Outputs en detrimento de Product Delivery con métricas de Outcomes (impactos), te sugerimos:
1- Hacer visible el problema internamente en forma iterativa e incremental, primero a través de conversaciones con las personas que consideres más receptivas a las propuestas de mejora y con menos aprehensión a los cambios
2- Diseñar y realizar un experimento de Product Discovery que demande muy poco tiempo (por ejemplo a través de un prototipo), ponga foco en aprender sobre las necesidades reales de los usuarios, y esté formulado rigurosamente
3- Seguir publicaciones, asistir a webinars y leer libros relacionados con Product Discovery, Lean UX y Product Management Digital
4- Participar de foros en redes sociales, eventos de la Comunidad Ágil, y este grupo de Telegram
Desde Kleer también ofrecemos un Taller de Product Discovery de 2 días, tanto en modalidad abierta como in-company, además de acompañamiento a Product Managers/Product Owners y equipos de trabajo. Ver detalles aquí
Publicado originalmente en http://rcolusso.blogspot.com
