¿Cómo priorizar?

¡Bienvenido al boletín diario de expertos en negocios! Cada día, nuestros expertos te brindarán consejos y estrategias para mejorar su negocio y alcanzar el éxito. No te pierdas ninguna actualización importante y mantente al día con artículos relevantes del mundo empresarial, ¡suscríbete hoy!

Como fundador (tanto como Product Manager) de una startup siempre vas a tener que priorizar y tomar decisiones sobre qué se avanza, qué se deja de hacer o incluso qué se puede delegar. Y para hacerlo correctamente, es recomendable hacerlo con una estructura.

En orden de poder generar rutinas y mecanismos que nos ayuden a hacerlo mejor, en este artículo cuento 4 de los frameworks más conocidos y recomendados por expertos. 

1. Matriz Eisenhower:

Se compone principalmente por dos preguntas

• ¿Es urgente?
• ¿Es importante?

Y la solución, gráficamente, se ve así:

Depende mucho de qué le des peso tú; por ejemplo, si priorizamos 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 delegar directamente al equipo de diseño para armar las mejoras y pasar directo al siguiente ciclo de desarrollo (o sprint). En cambio, si es una “sugerencia” de un gerente, tu trabajo es entender si lo que propone sumará valor al usuario o no para luego ejecutarse, en ese caso tienes que hacerlo primero.

2. 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).

1. 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.
2. 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:
   1. 3 = Impacto masivo
   2. 2 = Impacto alto
   3. 1 = Impacto medio
   4. 0.5 = Impacto bajo
   5. 0.25 = Impacto mínimo
3. 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 tú 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 del esfuerzo 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 (Le dedicaré otro artículo a lo que significa esto)

3. 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.

1. Must have: Son los features o iniciativas claves para el inicio del negocio. Que sería fatal lanzar el producto sin estos features. Según Productschool pueden ser por temas legales, de seguridad o por requerimientos de negocio.

“the features that you absolutely should not launch without”

2. Should have: Son los features que sí 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”.

3. 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”

4. 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”.

4. 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. Solo conociendo bien al usuario este framework cobra relevancia.

¿Suena complicado? A primera vista lo parece, pero gráficamente se puede entender mejor:

• Delighters: Las características que los clientes percibirán como algo que va «más allá» de sus expectativas. Estas son las cosas que le diferenciarán de su competencia.
• Performance features: Los clientes responden bien a las altas inversiones en prestaciones.
• Basic features: Lo mínimo que esperan los clientes para resolver sus problemas. Sin ellos, el producto es básicamente inútil para ellos.

¿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 visible; por otro lado, en el eje Y se dimensiona la satisfacción del usuario, por ejemplo, el feature de poder ver 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.

Artículo elaborado por: Diego Flores