¿Cómo saber si estamos desarrollando el producto equivocado?

Por Ricardo Colusso

Ricardo Colusso

Una guía para resolver problemas frecuentes del Product Management digital. Cómo detectar si el desarrollo de tu producto va en una dirección incorrecta. Y un conjunto de repelentes y antídotos para prevenir a tiempo una posible caída en “la trampa de construir”

La adopción de los valores y herramientas ágiles para el desarrollo de productos está acelerando la transformación digital en las empresas, porque permite crear equipos empoderados, reducir riesgos a través de desarrollos iterativos-incrementales, y 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!!!.

El problema es que a veces no nos tomarnos el tiempo de validar previamente si lo que queremos desarrollar resolverá problemas reales de los usuarios de una manera efectiva y atractiva.

Revisemos cuatro conceptos importantes del Product Management Digital:

Outputs: es la cantidad de software funcionando que entrega un equipo de producto, medida en funcionalidades, story points, etc.
Outcomes: son 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: 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 esos cuatro conceptos 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 construir porque sí?

Aquí van algunos síntomas:

1- Las expectativas de adopció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 a priori consideramos crítica e indispensable, pero su valor no fue 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 contra el desarrollo de funcionalidades que terminan siendo un desperdicio?

- Para evitar entrar en el modo vertiginoso del Product Delivery al 100% sugerimos a conocer el mindset de Product Delivery y utilizar algunos de sus conceptos 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 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 y eventos de la Comunidad Ágil. Desde Kleer 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. 

Ricardo Colusso es M.B.A., Lic. en Sistemas, trainer/coach en Kleer, especialista en Innovación Aplicada, Métodos Ágiles y Transformación Empresarial. Kleer tiene el objetivo de co-crear ambientes humanos más conscientes y asombrosos. Más información sobre el autor y sobre Kleer en http://www.kleer.la/

Entradas populares de este blog

Amdia realizó el Digital Media Summit 2019

Glassdoor se expande a Latinoamérica lanzando su sitio en Argentina, Brasil y México

3 maneras en las que los marketers ponen en peligro la lealtad del cliente