Esta es la segunda parte del artículo que publiqué sobre las técnicas efectivas de priorización. Si no leíste la primer parte, te recomiendo ampliamente que lo hagas, ya que contiene la que para mi es la forma más efectiva de priorizar en la construcción de productos digitales.
De todas formas, en este artículo voy a explayar las primeras 3 de las 7 técnicas que considero más relevantes con sus pros, sus cons, y en qué momentos puede cada una funcionar mejor.
Las opciones para priorizar
A modo introductorio reitero la matriz del primer post con el resumen de técnicas:
Los 2 ejes del gráfico se refieren a la búsqueda del “valor” que aporta lo que estoy priorizando. Exactitud es cuan cuantificable es la estimación de valor que genera la técnica, y complejidad es el nivel de esfuerzo que implica llegar a estimación de valor.
1. Juicio de expertos
- Complejidad: baja
- Exactitud: baja
El juicio de expertos es la opción más simple y menos exacta: básicamente se prioriza según la opinión del propio Product Manager, o de algún stakeholder con conocimiento de la industria (o incluso puede ser en base a juicio de clientes).
En mi experiencia esto se hace (y funciona relativamente bien) en proyectos pequeños con un “dueño de negocio” (en general es realmente el dueño de la compañía) que tiene mucho conocimiento del problema y la solución que quiere, entonces no vale la pena hacer ejercicios de priorización (considerando incluso que los vetaría si no diesen de acuerdo a sus decisiones).
Definitivamente no lo recomiendo salvo para casos muy particulares.
2. El modelo de Kano
- Complejidad: medio baja
- Exactitud: medio baja
El modelo de Kano propone dividir las funcionalidades que quiero implementar en 3 categorías:
- Necesidades básicas: si no están generan gran insatisfacción, pero si están no generan una satisfacción mayor (por ejemplo, la capacidad de escribir en un editor de texto)
- Necesidades de performance: estos son los que generan mayor satisfacción cuando están y mayor insatisfacción cuando no. No son críticos para el uso del producto, pero serán un factor de decisión contra competidores (por ejemplo, la capacidad de agregar imágenes en un editor de texto)
- Deslumbrantes: son aquellas características no esperadas por el usuario, que generan gran satisfacción si están, pero no generan insatisfacción si no se encuentran (por ejemplo, la capacidad de dictar oralmente a un procesador de texto).
Volviendo a ejemplificar con mis desventuras cómo Product Owner en el juego social de Poker, nos tocó priorizar entre un tutorial y un rediseño de las mesas de juego. Si bien el rediseño era importante y creíamos que por mejorar el atractivo íbamos a incrementar la retención, era claramente un “Deslumbrante”, no cubría necesidades básicas ni de performance. El cambio el tutorial, para el segmento de usuarios que era nuevo al poker, era una necesidad básica: no iban a poder usar el producto si no sabían jugar.
Uno de los principales problemas con este método es que si bien categorizamos los resultados, no nos provee ninguna facilidad para priorizar entre 2 features del mismo grupo (algunos pueden objetar que por ejemplo entre dos funcionalidades “necesidad básica”, una puede ser más básica que otra, pero el modelo en si no aporta nada en estos casos, es mera opinión subjetiva).
Si bien el modelo me parece muy interesante para compararte contra competidores y entender qué y cómo valora el usuario tu producto, no lo aconsejo cómo técnica de priorización.
3. Matriz de priorización
- Complejidad: media
- Exactitud: medio baja
También conocida por su nombre en inglés “Scorecard”, consiste en armar un cuadro de doble entrada con las funcionalidades que voy analizando y su puntaje (de 0 a 10 o de 0 a 100) para cada dimensión alineada con los objetivos del producto.
Cada dimensión suele tener un peso relativo, así que el valor final de la idea que está siendo evaluada es la sumatoria de la multiplicación de su puntaje por el peso de la dimensión.
En el siguiente ejemplo queda más claro y es relativamente fácil de implementar con un simple excel:
Mi propia experiencia paso a paso
Esta fue la primer técnica que utilicé cuando quise “profesionalizar” mi técnica de priorización, cuando empecé en el producto de alquiler de autos. Así lo implementé:
1) Elegir criterios en base a los objetivos del negocio
Determiné una lista de 9 factores (definitivamente muchos, si lo volviese a hacer buscaría que sean 4 o 5 como máximo) y subfactores que estaban alineados a los objetivos de negocio generales pero que eran 100% relacionados al producto. Por ejemplo, si un objetivo era incrementar la facturación, los criterios podrían ser mejorar la conversión y mejorar el ticket promedio.
2) Asignar un puntaje a cada criterio en base a su importancia cómo objetivo
No todos los factores tenían igual importancia para el negocio, por lo que asigné un puntaje a cada uno de acuerdo a la prioridad que tenía para la compañía.
Para evitar tener que discernir entre valores muy cercanos, me forcé a usar la sucesión de Fibonacci, similar a cómo se usa en Poker Planning para estimar el “costo” de las historias. La idea explicada de forma muy rápida es: dado que estos valores son subjetivos la diferencia entre, por ejemplo, un valor de 10 y uno de 11 es dificil de establecer. Por eso, usando la sucesión de fibonacci las únicas posibilidades son establecer valores de 8 y 13 lo cuál hace que pensemos en saltos que realmente hagan una diferencia en valor o costo.
Al finalizar este ejercicio el resultado es similar a establecer un porcentaje de importancia a cada factor, pero difiere en la forma de construirlo, ya que en lugar de pensar en “repartir” 100 puntos, se arman los valores relativos primero y en base a eso surge el porcentaje.
Asi se veía la tabla:
3) Cuantificar los valores Alto, Medio y Bajo
Para evitar ser muy subjetivo a la hora de aplicar valores alto, medio o bajo, establecí las cantidades que debía alcanzar en un criterio para ser Alto, medio o bajo. En general estaba relacionado con la cantidad de usuarios que podía afectar, o el valor en el cuál estimaba que afectaría el criterio una vez implementado.
Así por ejemplo, si la idea o funcionalidad mejoraba la información que se mostraba a más de 8% de usuarios, tenía un valor de “Alto” para el criterio 3.2, y “Medio” si estaba entre 8% y 3% de usuarios.
Esto se podía determinar según la rentadora, tipo de auto, destino, etc. Es decir, dónde se vería la mejora nos daba parámetros que nos permitían saber cuantos usuarios pasarían por esa “pantalla” mejorada.
A su vez, establecí que un valor Alto daría el 100% de los puntos de ese criterio, uno medio el 70%, uno bajo el 30% (y obviamente una historia podría no afectar un criterio y recibir 0 puntos para esa categoria).
4) Priorizar
El último paso es evaluar cada solución contra la matriz, poniendo el valor que tiene esa solución en cada criterio (alto, medio o bajo).
Luego se suma la cantidad de puntos que obtuvo en cada categoría y tenemos el valor final. Dividiendo este valor por un “peso” que debería determinar el equipo de tecnología, podemos determinar la prioridad.
Si bien este acercamiento es mucho mejor que un “Juicio de expertos”, la principal desventaja es que la evaluación del puntaje para cada dimensión sigue siendo muy subjetivo. Lo más probable es que si 2 personas hacen este ejercicio, lleguen a resultados distintos. Si bien no es lo que recomendaría hoy, creo que es una buena forma de empezar, y aunque queden aspectos que dependan de opiniones, hacen que la evaluación sea mucho más “consciente” focalizándose en analizar en qué aspectos una solución ayuda al negocio y al usuario.
Update: ya está publicado el 3er artículo donde detallo las formas más complejas de priorizar y se completa la explicación de por qué experimentar es la mejor de todas las posibilidades.