Product: ¿Cómo priorizar?
En este artículo te explico 4 frameworks que puedes utilizar para priorizar features en próximos lanzamientos
El tiempo es un recurso escaso y no renovable, por eso es muy importante usarlo sabiamente.
Como Product Manager, Gerente o fundador de startups siempre vas a tener que priorizar y tomar decisiones sobre qué se avanza primero, qué se coloca en backlog (o pendiente), qué se deja de hacer porque no es prioridad e incluso qué se puede delegar a otros equipos. Y para hacerlo correctamente, es recomendable hacerlo con una estructura.
Además, la priorización es parte fundamental del skillset que todo Product Manager debe desarrollar, porque no solo se debe tener en cuenta deadlines y proyectos, si no también feedback de usuarios, mejoras continuas, feedback y “sugerencias” de los stakeholders y más.
En este artículo cuento 4 de los frameworks más conocidos y recomendados por expertos:
Matriz Eisenhower
Se compone principalmente por dos preguntas
¿Es urgente?
¿Es importante?
Y la solución, gráficamente, se ve así:
¿Cómo aplicarla en Producto?
Depende mucho de a qué le des más importancia; por ejemplo, si priorizas el feedback de los usuarios de un nuevo feature que se acaba de lanzar, y todo el equipo está enterado, es probable que se deba priorizar las mejoras tanto en diseño como en tecnología en ese específico feature primero. En cambio, si le das más peso a lanzar A/B Test para entender otras funcionalidades, tocará dejar para un siguiente sprint (schedule) las mejoras en un feature específico. Dependerá mucho del contexto en el que se encuentre el producto y el equipo.
R(ICE)
Siempre he sido una persona de números, por lo que esta metodología es una de las que más me gusta. Ayuda a ponerle un valor nominal a cada iniciativa en base al potencial que el equipo ve. Se compone directamente por Reach (Alcance), Impact (Impacto en el negocio) y Confidence (confianza en que se logren los resultados), e indirectamente por Effort (esfuerzo).
Reach: A cuántos usuarios potenciales vas a impactar con este nuevo feature o iniciativa. Este punto es importante analizarlo con data cuantitativa e información de mercado.
Impact: Si bien Reach indica a cuántas personas vamos a impactar, el impacto es una métrica enfocada que busca dimensionar “en cuánto” las afectamos. Se recomienda manejar valores estandarizados. Intercom recomienda lo siguiente:
3 = Impacto masivo
2 = Impacto alto
1 = Impacto medio
0.5 = Impacto bajo
0.25 = Impacto mínimo
Confidence: Esta métrica es la más subjetiva de la ecuación, pues busca dimensionar el nivel de confianza que siente el equipo (y en especial tu como PM) respecto al feature o iniciativa. Normalmente es un valor porcentual entre 0% y 100%.
Effort: Esta métrica dimensiona el esfuerzo (en tiempo y recursos) que toma la implementación del feature o iniciativa. Es importante que en el análisis participe todo el equipo (desarrollo y diseño). Se recomienda que sean valores estandarizados, por ejemplo: entre 1 y 10; para esta estandarización se pueden usar los story points por sprint.
MoSCoW Method
Esta metodología la conocí el año pasado y es muy interesante sobre todo para contarle a los diferentes Stakeholders cuál ha sido el proceso de priorización y que sepan en qué está trabajando el equipo y por qué. MoSCoW hace referencia a Must, Should, Could y Won’t have.
Must have: Son los features o iniciativas claves para el inicio del negocio. Sería fatal lanzar el producto sin estos features. Según Productschool pueden ser por temas legales, de seguridad o por requerimientos de negocio.
“Features that you absolutely should not launch without”
Should have: Son los features que si se van a priorizar, pero no son críticos en este momento.
“Things that would be better to include, but you’re not destined for disaster without them”.
Could have: Son los features que se van a priorizar cuando se tengan los recursos en el momento oportuno.
“Things would be nice to include if you have the resources, but aren’t necessary for success”
Won’t have: Son los features que se consideraron en la priorización, pero no están entrando en desarrollo (por ahora).
“When we say ‘Won’t have’ we don’t mean ‘this requirement is trash and it will NEVER be included’, we just mean ‘not this time”.
Kano Model
Probablemente uno de los frameworks de priorización más customer centric que existen. Busca priorizar los features en base a las necesidades no satisfechas de los usuarios y a la satisfacción que podría generar. Si bien es un framework que puede conllevar muchos supuestos, es importante hacerlo luego de un exhaustivo proceso de research y entrevistas con usuarios. Conociendo bien al usuario este framework cobra mayor relevancia.
¿Suena complicado? a primera vista lo parece, pero gráficamente se puede entender mejor:
Delighters: The features that customers will perceive as going ‘above and beyond’ their expectations. These are the things that will differentiate you from your competition.
Performance features: Customers respond well to high investments in performance features.
Basic features: The minimum expected by customers to solve their problems. Without these, the product is basically useless to them.
¿Cómo entenderlo?
En el eje X se puede ver qué tan satisfecha está la necesidad del usuario, considerando las herramientas, servicios o productos con lo que el usuario ya cuenta actualmente en el mercado y/o en la competencia. Por ejemplo, si estamos desarrollando un restaurante virtual, un “must have” probablemente sea tener la carta de productos de manera visible; por otro lado, en el eje Y se dimensiona la satisfacción del usuario, por ejemplo, el feature de tener la carta no necesariamente va a producir un factor wow o diferencial en el usuario, por lo que se encontraría en el centro, aproximadamente.
La idea principal de esta metodología es poder enfocarse en los features o iniciativas que realmente generan satisfacción en los usuarios resolviendo necesidades que hoy no están resueltas ya que esto genera un factor diferencial en tu producto o servicio.
¿Qué metodología usar?
Nada está escrito en piedra y tampoco son frameworks excluyentes entre sí; es decir, se puede trabajar la mezcla de algunos. Te dejo dos recomendaciones personales:
Si eres una persona más numérica, te recomiendo usar RICE, ya que te dará cuantitativamente el orden de los features; y lo puedes complementar con MoSCoW para dar visibilidad a tus stakeholders.
Si estás más orientado al diseño e investigación, Kano puede ser un gran aliado; y podrías complementarlo con RICE para ciertos features que cuenten con data cuantitativa para tener una referencia.
Si este artículo te ayuda, compártelo con amigos y colegas.
Si aún no estás suscrito y ves valor en el contenido, me ayuda mucho que lo puedas hacer:
Buen resumen! Para tenerlo como guardado como bookmark.
Hola Diego, interesante resumen. Respecto al modelo RICE, no sé si lo has usasdo, pero tengo una duda por si puedes ayudarme :) ¿cómo haces el scoring cuando tienes un feature que tiene impacto en los usuarios pero también en la empresa ya que reduce tareas manuales?