Priorización del Roadmap: RICE vs Kano vs Opportunity Solution Tree

He visto a un equipo calificarse con RICE hasta terminar con un año entero de funcionalidades sin impacto. Quince elementos, todos cuidadosamente ordenados, todos lanzados según el cronograma. La activación no se movió. La retención no se movió. Los ingresos por cuenta se mantuvieron estáticos. El CEO finalmente hizo la pregunta que todo PM teme: «¿Qué aprendimos realmente?» Nadie tuvo una buena respuesta, porque el marco de trabajo nunca había sido sobre aprender. Había sido sobre defender el orden de una lista.

Eso es lo que ocurre con los marcos de priorización. La mayoría de los PM usa RICE porque Intercom lo publicó en un blog en 2017 y se propagó como un virus por todas las organizaciones de producto con una suscripción a Notion. Parece riguroso. Produce un número. Las partes interesadas asienten cuando ven la hoja de cálculo. Pero el marco de trabajo no es la respuesta al problema de su roadmap. El marco de trabajo es una palanca para forzar la conversación que su equipo está evitando. Elija el que fuerce la conversación correcta y lanzará mejores productos. Elija el incorrecto y lanzará mucho.

Hablemos entonces de los tres que tendrá que defender en la práctica, en qué es bueno cada uno, dónde falla cada uno y cuándo combinarlos.

La Matemática de RICE, con Números Reales

RICE significa Reach (alcance), Impact (impacto), Confidence (confianza), Effort (esfuerzo). La fórmula es sencilla:

Puntuación = (Reach × Impact × Confidence) / Effort

• Reach: cuántos usuarios se ven afectados en un período determinado. Normalmente mensual. Sea honesto sobre qué significa «se ven afectados».
• Impact: cuánto mueve su métrica objetivo por usuario afectado. La escala original de Intercom usa 3 / 2 / 1 / 0,5 / 0,25 para masivo / alto / medio / bajo / mínimo. Es gruesa a propósito.
• Confidence: un porcentaje. 100% significa que tiene datos. 80% significa que tiene evidencia. 50% significa que está suponiendo.
• Effort: personas-mes combinadas entre producto, diseño e ingeniería.

Un ejemplo real. Imagine un SaaS B2B con 4.000 cuentas activas mensuales y está evaluando tres candidatos del roadmap para el próximo trimestre:

La importación masiva gana por un margen amplio. Y honestamente, con esta puntuación, debería. Tiene alta confianza, alcance razonable y poco esfuerzo. RICE está haciendo exactamente lo que fue diseñado para hacer: sacar a la superficie la apuesta obvia de bajo costo y alto efecto.

Cuándo RICE funciona de verdad:

• Productos maduros con KPIs claros. Usted sabe cómo se ve la activación, la retención y la conversión. Puede predecir el impacto dentro de un rango razonable.
• Equipos grandes lanzando en paralelo. Cuando cinco squads necesitan coordinar la secuencia, una rúbrica de puntuación compartida es más rápida que diez reuniones.
• Defender compromisos ante un ejecutivo con mentalidad financiera. Un CFO puede leer una tabla RICE. No puede leer un mapa de recorrido del cliente.

Dónde RICE falla:

• Productos en etapa temprana. El Reach es una suposición porque aún no conoce a su audiencia real. El Impact es un deseo porque no sabe cómo se ve el éxito.
• Apuestas en etapa de descubrimiento. RICE penaliza la incertidumbre mediante el multiplicador de Confidence, lo que significa que cualquier cosa genuinamente nueva queda aplastada por cualquier cosa incremental. Su roadmap se llena de funcionalidades de importación masiva y nunca incluye la apuesta que podría cambiar la trayectoria.
• Apuestas estratégicas. «¿Deberíamos expandirnos al mercado mediano?» no cabe en una tabla RICE. No lo intente.

La crítica honesta: RICE optimiza lo que puede medir, no lo que importa. Úselo donde la medición es fácil, ignórelo donde no lo es.

El Modelo Kano, con una Pregunta de Encuesta que Funciona de Verdad

El modelo Kano es más antiguo y más peculiar que RICE. Noriaki Kano lo construyó en la década de 1980 para explicar por qué algunos atributos encantan a los clientes y otros apenas los notan. Hay cinco categorías, pero solo necesita tres para la priorización:

• Básico (imprescindible): los clientes no lo notan cuando está, pero se enojan cuando falta. Autenticación en dos pasos. Exportar a CSV. Búsqueda decente. Construir estas cosas no hace que lo amen. Omitirlas hace que se vayan.
• Rendimiento (cuanto más, mejor): satisfacción lineal. Cargas de página más rápidas, más integraciones, mejor tiempo de actividad. Vale la pena invertir en ellas de forma proporcional al costo.
• Emoción (diferenciadores): los clientes no lo esperan, no pueden pedirlo, pero lo aman cuando lo reciben. Lo que hace que el demo cierre. Los hilos de Slack, los atajos de teclado de Linear, los cursores multijugador de Figma cuando se lanzaron.

Las otras dos categorías (Indiferente e Inverso) son donde se eliminan funcionalidades. Indiferente significa que a nadie le importa. Inverso significa que a algunas personas les molesta activamente (piense en sugerencias de IA agresivas en una herramienta de productividad tranquila).

Esta es la plantilla de pregunta de encuesta que realmente utilizo, dos preguntas por funcionalidad:

1. ¿Cómo se sentiría si el producto tuviera esta funcionalidad?
2. ¿Cómo se sentiría si el producto no tuviera esta funcionalidad?

Ambas respondidas en una escala de 5 puntos: Me gusta / Lo espero / Soy neutral / Puedo tolerarlo / No me gusta.

La tabla cruzada le dice la categoría. «Me gusta / No me gusta que falte» = Rendimiento. «Soy neutral / No me gusta que falte» = Básico. «Me gusta / Soy neutral si falta» = Emoción. Ejecute esto con 50-100 clientes por segmento y tendrá una señal que vale la pena defender.

Cuándo Kano gana:

• Decisiones de paridad de funcionalidades. «El Competidor X acaba de lanzar Y. ¿Lo necesitamos?» Kano le dice si Y es Básico (sí, lánzalo ahora), Rendimiento (sí, pero según el cronograma) o Emoción (solo si diferencia).
• Recorte de alcance. Cuando ingeniería le dice que la especificación es de seis semanas y usted tiene cuatro, Kano le dice qué eliminar. Elimine Emoción primero si los Básicos no están hechos.
• Decisiones de «¿deberíamos construir esto siquiera?» Si una funcionalidad puntúa como Indiferente, los datos le dicen que no siga adelante.

La trampa: Kano necesita datos reales de clientes, no la intuición de un PM. He visto roadmaps completos justificados por un análisis Kano que consistía en tres personas en una sala de reuniones discutiendo en qué columna poner la eliminación masiva. Eso no es Kano. Es un PM dándole apariencia de método a opiniones.

Opportunity Solution Tree, Cuándo Gana

Teresa Torres construyó el Opportunity Solution Tree (OST) para equipos que practican el descubrimiento continuo. La estructura:

                  Resultado
                     |
       -----------------------------
       |             |             |
  Oportunidad  Oportunidad  Oportunidad
       |             |             |
   ---------     ---------     ---------
   |       |     |       |     |       |
 Solución Solución Solución ... Solución
   |
Experimento

Comienza con un Resultado (un resultado de negocio medible, como «aumentar la conversión de prueba a pago en un 15%»). Mapea Oportunidades (puntos de dolor del cliente, necesidades no satisfechas, momentos de fricción) recopiladas de entrevistas semanales con clientes. Bajo cada oportunidad genera múltiples Soluciones. Bajo cada solución prometedora, diseña un Experimento para validar antes de construir.

Lo brillante es que impone una jerarquía. No puede priorizar una solución contra otra solución. Solo puede priorizar oportunidades y luego elegir la mejor solución para la oportunidad seleccionada.

Cuándo OST gana:

• Equipos de descubrimiento continuo. Equipos que realizan puntos de contacto semanales con clientes y hacen pruebas de prototipo. El árbol se actualiza a medida que el descubrimiento revela nuevas oportunidades.
• Organizaciones orientadas a resultados. Donde el liderazgo establece metas como resultados, no como listas de funcionalidades. OST traduce los resultados en un proceso de descubrimiento y construcción.
• Evitar el modo fábrica de funcionalidades. El movimiento definitivo de OST es hacer visible cuándo una solución no sube en la jerarquía hasta una oportunidad que sube hasta el resultado. Si no se conecta, no lo construya.

Dónde OST falla:

• Organizaciones donde «descubrimiento» significa una entrevista de usuario por trimestre. OST es un sistema operativo de descubrimiento continuo. Sin la cadencia de descubrimiento, el árbol es decorativo. Lo llenará con oportunidades que asumió en lugar de oportunidades que encontró.
• Equipos sin acceso a investigación. Si su PM tiene que luchar para obtener cinco llamadas con clientes al mes, OST es aspiracional, no operativo.
• Trimestres de ejecución pura. A veces tiene que lanzar lo que está bloqueando una renovación. OST no le ayudará a secuenciar ocho funcionalidades conocidas.

«Ahora, Próximo, Después» y Por Qué es RICE Disfrazado

La mayoría de los roadmaps «ahora / próximo / después» son clasificaciones RICE con los números ocultos. El PM puntuó todo, lo más alto de la lista fue al Ahora, el medio al Próximo y lo inferior al Después. El formato pretende ser flexible, pero la priorización es idéntica a una hoja de cálculo ordenada.

El formato tiene sentido real cuando cada segmento tiene un estándar epistémico diferente:

• Ahora: alta confianza, delimitado, comprometido. Esto se lanzará. El equipo es dueño del resultado.
• Próximo: confianza media, problema validado, solución aún en descubrimiento. Cree que esto importa. No ha probado que la solución funcione.
• Después: oportunidades, no soluciones. Cosas que ha escuchado de los clientes que aún no han ganado un espacio.

Si su segmento «Después» tiene nombres de funcionalidades con estimaciones de esfuerzo, está haciendo RICE disfrazado. Si su segmento «Después» tiene problemas de clientes con preguntas abiertas, lo está haciendo bien.

Confianza, la Variable que Nadie Puntúa Honestamente

Cada PM que he conocido infla la confianza en su funcionalidad favorita. La persona que construyó la columna de confianza del marco esperando que fuera una herramienta de calibración la ve convertirse en una columna de impresiones subjetivas.

La solución: una rúbrica de confianza vinculada a evidencia, no a sensaciones.

Nada por debajo del 60% debería estar en su columna Ahora bajo ningún marco de trabajo. Nada por debajo del 40% debería ser una Oportunidad en su OST, no una funcionalidad en su roadmap. Si no puede llegar al 60% de confianza en algo que ha estado en el roadmap durante dos trimestres, elimínelo. El costo de dejarlo ahí es la apariencia de progreso sin el progreso real.

Por Qué las Partes Interesadas Detestan RICE

Esta es la conversación de diagnóstico que tengo con cada equipo que dice «RICE no nos está funcionando». Casi nunca es el marco de trabajo. Es la capa de traducción.

Ventas detesta RICE porque las solicitudes de clientes puntúan bajo en Reach. Ventas le trae la solicitud que bloquea el trato del prospecto que paga $80K. El Reach para ese cliente es uno. La puntuación RICE es fraccionaria. Ventas lee esto como «al PM no le importan los ingresos». La traducción: saque los bloqueos de tratos de RICE por completo. Mantenga un canal separado de «bloqueos de tratos» dimensionado según su impacto en la tasa de ganancia. Dígale a ventas que ese canal existe.

CS detesta RICE porque las apuestas de retención puntúan bajo en Impact. Las funcionalidades de retención rara vez muestran movimiento de métrica a corto plazo. Previenen el abandono que ocurriría seis meses después. El Impact en RICE es prospectivo, pero la mayoría de los PM lo puntúan como movimiento trimestre a trimestre. La traducción: separe las apuestas de retención y puntúe el Impact como movimiento anualizado de la tasa de abandono, no de la activación trimestral.

Ingeniería detesta RICE porque el Effort es su suposición, no la de ellos. Los PM estiman el esfuerzo basándose en funcionalidades pasadas similares. Ingeniería sabe que el código tiene tres problemas ocultos. La traducción: nunca publique una puntuación RICE con su propio número de esfuerzo. Use rangos (1-2 PM-meses, 3-5 PM-meses, 6 o más) y deje que ingeniería los ajuste después de un breve análisis de alcance. El PM es dueño del Reach, Impact y Confidence. Ingeniería es dueña del Effort.

El patrón: RICE da un número, pero las cuatro variables provienen de cuatro partes interesadas diferentes. Cuando publica una puntuación única y no muestra su trabajo, cada parte interesada lee la variable que le importa y discrepa con ella. Muestre las variables. Discuta el Reach con marketing, el Impact con el equipo de datos, la Confidence con investigación y el Effort con ingeniería. La puntuación es el resultado de esas cuatro conversaciones, no un sustituto de ellas.

Cuándo Combinar los Tres

Este es el conjunto que realmente ejecuto:

1. Use OST para encontrar la oportunidad correcta. Mapee resultados a oportunidades de clientes mediante el descubrimiento continuo. Elija la oportunidad que tiene la evidencia más sólida y el mayor impacto potencial en el resultado. Omita esta capa si ya conoce el problema a fondo (funcionalidades maduras, dominio bien comprendido). No la omita si su equipo está lanzando funcionalidades que nadie pidió.

2. Use Kano para clasificar la solución. Una vez que ha elegido una oportunidad y tiene dos o tres soluciones candidatas, ejecute Kano en los candidatos con datos reales de clientes. Omita esta capa si la solución es obviamente Básica (autenticación, exportación, accesibilidad). No la omita si está eligiendo entre «hacer que una funcionalidad existente sea más rápida» y «agregar un momento de emoción» y no puede determinar cuál valorarán realmente los clientes.

3. Use RICE para secuenciar la construcción. Una vez que ha elegido qué oportunidades y soluciones construir, RICE las secuencia a lo largo del trimestre. Esfuerzo, dependencias, capacidad. RICE es una herramienta de secuenciación, no de descubrimiento. Ahí es donde justifica su lugar.

El conjunto completo es excesivo para la mayoría de los equipos la mayor parte del tiempo. Un equipo que lanza mejoras incrementales a un CRM maduro no necesita OST cada trimestre, necesita RICE en un backlog limpio. Una startup pre-encaje producto-mercado no necesita RICE, necesita OST y la voluntad de descartar la mitad del roadmap. Adapte la profundidad del marco de trabajo a la situación epistémica real. Forzar OST en un equipo sin acceso a investigación es teatro. Forzar RICE en un equipo que no conoce sus KPIs es precisión sin exactitud.

El marco de trabajo no es la respuesta. Elija el que fuerce la conversación que su equipo está evitando. Si su equipo evita el contacto con clientes, ejecute OST. Si su equipo evita recortar el alcance, ejecute Kano. Si su equipo evita las decisiones de secuenciación, ejecute RICE. Y si su equipo evita los tres, el problema no es el marco de trabajo. El problema es que nadie quiere tomar una decisión real, y ninguna hoja de cálculo va a solucionar eso.

Aprenda Más

• JD de Product Manager (complemento)
• Hábitos de Descubrimiento Continuo para PM
• Cómo Escribir PRDs que los Ingenieros Realmente Lean
• Planificación Trimestral con Ingeniería y Diseño