¿Cómo priorizar?

4 Frameworks que todos deberían conocer

30 septiembre 2022
Diego Flores
Growth y Startups

Aqui va el cuerpo

¡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”

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

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

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

Compartir a través

Evento de prueba 1

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Más de la misma categoría

Paulo nos cuenta cuáles son las cuatro etapas de la creatividad y cómo la aplicó para la creación de Kambista.
28/03/2023
En Hablemos de Negocios elaboramos un análisis de Smartfit ¿cuánta gente va al día? ¿Cuánto ganan por usuario? ¿En cuánto timepo recuperarán su inversión?
24/03/2023
Te brindamos la mayor información posible para poder levantar un Pet Shop. Te dejamos los motivos por los que nos parece un buen momento para hacer un negocio como este, datos de mercado y qué necesitas para montarlo.
22/03/2023
Cuatro jóvenes emprendedoras crearon Sin Envolturas, una plataforma que busca facilitar la experiencia de planificar, celebrar y regalar eventos importantes. A pesar de la pandemia, han diversificado sus fuentes de ingresos y han crecido cuatro veces lo que generaban antes.
28/02/2023

Hablemos de negocios
tiene más para darte

Comunidad

Meetup’s menusales

Recursos

Telegram privado

Conferencias

Marketplace