En el módulo 5 armamos el roadmap: la secuencia de apuestas que lleva de un piloto a un producto que opera solo. Pero un roadmap honesto tiene un problema que ningún diagrama de Gantt resuelve: siempre hay más candidatos que capacidad. La lista de cosas que “valdría la pena hacer” crece más rápido que el equipo, el presupuesto y el calendario juntos. El roadmap muestra el orden; no dice cómo se decidió ese orden ni, sobre todo, qué se quedó afuera. Priorizar es la maquinaria que llena el roadmap — y es donde se juega, semana a semana, si el producto avanza hacia algo o se dispersa en veinte medias iniciativas. Este módulo es sobre esa maquinaria: los frameworks para puntuar, el eje que la IA agrega y que las fórmulas no ven, y la disciplina — más incómoda de lo que parece — de matar buenas ideas.

La tesis del módulo

Priorizar no es ordenar una lista de buenas ideas: es tener el coraje de matar las que no caben. Toda idea que sobrevive el primer filtro es defendible; por eso ordenar es fácil y decir que no es difícil. Y en IA hay un eje que el software clásico no tiene — la incertidumbre de si la cosa siquiera va a funcionar — que ninguna fórmula captura sola. Quien prioriza IA con la misma planilla que priorizaba features de CRUD termina financiando lo seguro y matando justo la apuesta que valía la pena aprender.

Por qué priorizar es un problema, no una planilla

La intuición ingenua dice que priorizar es hacer una lista y ponerla en orden de valor. Si fuera eso, no haría falta un módulo: bastaría con preguntarle a cada stakeholder qué quiere y sumar. El problema real es más duro por tres razones que se combinan.

El valor no es lo único que importa. Una idea de valor altísimo pero que tarda un año y consume al equipo entero puede ser peor decisión que tres mejoras modestas que salen este mes. Priorizar es siempre valor contra algo — esfuerzo, riesgo, tiempo.
Los que piden no pagan el costo. Cada área quiere su feature y ninguna ve la fila completa. La suma de peticiones locales razonables es un roadmap imposible.
El costo de oportunidad es invisible. Lo vimos en el módulo 2: decir sí a A es decir no a todo lo que ese equipo habría hecho en ese tiempo. Ese “no” no aparece en ninguna reunión, y por eso se subestima siempre.

Un framework de priorización (método estructurado para puntuar y ordenar iniciativas con criterios explícitos) no adivina la respuesta correcta. Hace algo más modesto y más útil: obliga a que las razones sean explícitas, comparables y discutibles. Su valor no es el número que escupe, es que convierte “yo creo que esto es importante” en “esto puntúa así por estas razones, discutámoslas”.

Los frameworks, uno por uno

Valor vs esfuerzo — la matriz 2×2

El más simple y el que nunca sobra. Se estima cada iniciativa en dos ejes — cuánto valor entrega y cuánto cuesta hacerla — y se ubica en una matriz de cuatro cuadrantes.

   ALTO   ┌─────────────┬─────────────┐
          │             │             │
   valor  │ QUICK WINS  │  APUESTAS   │
          │ hacer ya    │  planear    │
          │             │  bien       │
          ├─────────────┼─────────────┤
          │             │             │
          │  RELLENOS   │   EVITAR    │
          │ si sobra    │  decir NO   │
   BAJO   │ tiempo      │             │
          └─────────────┴─────────────┘
            BAJO           ALTO
                  esfuerzo

  incertidumbre IA: empuja ítems hacia
  la derecha (más esfuerzo esperado) y
  baja su valor esperado (puede fallar)

Quick wins (alto valor, bajo esfuerzo): se hacen ya, sin discusión.
Apuestas grandes (alto valor, alto esfuerzo): valen la pena pero hay que planearlas — no caben muchas a la vez.
Rellenos (bajo valor, bajo esfuerzo): se hacen si sobra tiempo, nunca desplazando lo de arriba.
Evitar (bajo valor, alto esfuerzo): el cuadrante del “no”. Sorprende cuántas peticiones caen acá.

Su límite: dos ejes y estimación a ojo. No distingue entre una feature que toca a todos los usuarios y una que toca a diez; no modela la confianza en la estimación. Es un mapa de servilleta, excelente para una primera pasada y pobre para decisiones caras.

RICE — cuando el “impacto” necesita desglosarse

RICE lo creó Sean McBride en el equipo de producto de Intercom para comparar ideas muy distintas sin que ganara la voz más fuerte. Descompone el valor en tres factores y los divide por el esfuerzo:

RICE = (Reach × Impact × Confidence) / Effort

Reach (alcance): a cuánta gente afecta en un período (p. ej. usuarios por trimestre). Un número real, no una escala.
Impact (impacto por persona): escala fija — 3 = masivo, 2 = alto, 1 = medio, 0.5 = bajo, 0.25 = mínimo.
Confidence (confianza en tus estimaciones): porcentaje — 100% sólido, 80% razonable, 50% especulativo.
Effort (esfuerzo): en persona-semanas o persona-mes. Es el único que va abajo: divide.

El número no tiene unidad interpretable; sirve solo para comparar ítems entre sí. Un RICE de 90 no significa nada aislado; significa “va antes que el de 45”.

Su límite: da una falsa sensación de objetividad. Reach e Impact suelen ser inventados con cara de dato, y multiplicar cuatro estimaciones blandas no las endurece. La Confidence es el fusible que evita el autoengaño — y, como veremos, es donde vive la IA.

ICE — la versión rápida

ICE lo popularizó Sean Ellis en la comunidad de growth para rankear experimentos sin semanas de análisis. Tres factores, todos en escala 0–10, multiplicados:

ICE = Impact × Confidence × Ease

Impact (impacto hacia la meta), Confidence (confianza en que funcione), Ease (facilidad: qué tan barato es hacerlo — es el esfuerzo invertido, sube en vez de dividir).

Ejemplo: impacto 7, confianza 5, facilidad 4 → 140. Más alto, más prioritario.

Su límite: todo cabe en escalas subjetivas 0–10, incluida la Ease, que oculta que “fácil” para un ingeniero es “carísimo” para otro. Es más rápido que RICE y más manipulable. Bueno para muchos experimentos pequeños de bajo costo (su origen); peligroso para decisiones grandes.

Kano — cuando la pregunta es la satisfacción, no el ranking

El modelo de Noriaki Kano no ordena una lista: clasifica features por cómo afectan la satisfacción del usuario. Tres categorías útiles:

Básicos (must-be): se dan por sentado. Estar no suma; faltar hunde. En un asistente de IA, que no invente datos peligrosos es un básico — nadie lo aplaude, pero su ausencia mata el producto.
Lineales (performance): a más, mejor. La satisfacción sube proporcional a cuánto entregas. Latencia de respuesta, exactitud del modelo: cada punto de mejora se nota.
Deleite (delighters/atractivos): nadie los pide, pero encantan. Su ausencia no molesta; su presencia sorprende. Ojo: el deleite se erosiona — lo que hoy deleita mañana es básico (la batería que duraba un día pasó de lujo a expectativa).

Su límite: Kano no te dice qué hacer primero ni cuánto cuesta; te dice qué tipo de feature es cada cosa. Es un complemento, no un reemplazo: te salva de pulir un deleite mientras un básico está roto, pero no ordena tu trimestre.

El eje que la IA agrega: incertidumbre y valor de la información

Aquí es donde el software clásico y la IA se separan. En un CRUD, cuando estimas el esfuerzo de una feature, la incógnita es cuántas semanas — pero sabes que se puede hacer. En IA hay una pregunta anterior: ¿se puede hacer siquiera? ¿El modelo alcanza la exactitud que el caso necesita? ¿Los datos dan? ¿La latencia es tolerable? Esa incertidumbre no es esfuerzo — es riesgo técnico (la probabilidad de que la iniciativa no funcione por límites del modelo o los datos, no por falta de trabajo), y las fórmulas no tienen casilla para ella.

Las fórmulas sí tienen un lugar donde se esconde: la Confidence de RICE (o de ICE). Cuando priorizas una iniciativa de IA con confianza 40%, no estás diciendo “no sé si acertaré la estimación de esfuerzo”; estás diciendo “no sé si esto funciona”. La IA vive en la C.

Y eso cambia una regla del juego. En software clásico casi nunca priorizas algo de bajo valor. En IA a veces sí conviene, cuando ese algo reduce una incógnita enorme. Es el valor de la información (el beneficio de reducir incertidumbre antes de comprometer recursos grandes): una tarea barata cuyo producto no es una feature, sino saber si la apuesta grande es viable. Es exactamente el spike del módulo 3: un experimento acotado y desechable que responde “¿funciona?” antes de que firmes seis meses de equipo.

Ojo: un spike puntúa fatal en RICE — Reach casi cero (no lo usa nadie), Impact bajo (no entrega valor al usuario). Si priorizas ciegamente por el número, matas justo el experimento que te habría ahorrado un trimestre perdido. La regla: los ítems cuyo producto es conocimiento se puntúan por cuánta incertidumbre disuelven, no por su Reach.

Priorización de portafolio: no todo en una apuesta

Priorizar ítem por ítem no basta; hay que mirar la mezcla. Un portafolio sano combina horizontes de riesgo, usando la lógica de los tres horizontes:

Horizonte 1 — mejoras seguras al producto que ya opera. Riesgo bajo, retorno cierto pero acotado. Mantienen el negocio vivo.
Horizonte 2 — apuestas de riesgo medio: features de IA con viabilidad probada pero adopción incierta.
Horizonte 3 — apuestas de alto riesgo / alto retorno: capacidades nuevas donde ni siquiera sabes si el modelo llega.

El error de un extremo: todo en H3, un roadmap de puras apuestas heroicas que quema al equipo y no entrega nada estable. El error del otro: todo en H1, mejoritas incrementales seguras mientras un competidor construye la capacidad que te deja obsoleto. La priorización de portafolio reserva capacidad para cada horizonte a propósito — un porcentaje explícito, no lo que sobre.

El “no” como decisión de producto

Todo lo anterior converge en una sola disciplina incómoda: decidir qué no hacer. El costo de oportunidad del módulo 2 vuelve acá con fuerza operativa: cada sí es un no a todo lo demás, y ese no hay que hacerlo explícito o se lo comen las buenas intenciones.

Por eso una lista de “no lo haremos” es tan valiosa como el roadmap. No es un basurero: es un artefacto de gobierno. Documenta qué se descartó y por qué, para que en tres meses nadie reabra la misma discusión y para que el “no” tenga un dueño y una fecha en vez de morir en un silencio que todos interpretan distinto. Un roadmap sin su lista de “no” es una carta de deseos; con ella, es una decisión.

Los sesgos que corrompen la priorización

Ningún framework sobrevive a la política de la sala si no nombras las trampas:

HiPPO (Highest Paid Person’s Opinion — la opinión del que más gana): la iniciativa que sube no es la de mejor RICE, es la que pidió el ejecutivo más importante. El framework existe justamente para darle a los datos una silla frente a la jerarquía.
Sunk cost (costo hundido): “ya invertimos cuatro meses, no podemos parar ahora”. Lo gastado no vuelve; la única pregunta válida es si vale la pena lo que falta, no lo que ya se fue.
Shiny object (objeto brillante): perseguir lo último que salió en IA — el modelo nuevo, la técnica de moda — porque es emocionante, no porque resuelva un problema del usuario. En IA este sesgo es epidémico.
Feature factory (fábrica de features): medir el éxito por cantidad de cosas entregadas en vez de por impacto. Un equipo ocupadísimo entregando features que nadie usa se siente productivo y no lo es.

Artefacto: una hoja de priorización RICE trabajada

Cinco candidatos reales de un asistente de IA, puntuados y ordenados. Las cifras son ilustrativas, elegidas para mostrar cómo el orden final desafía la intuición.

Iniciativa	Reach (usuarios/trim)	Impact	Confidence	Effort (pers-sem)	RICE	Orden
Cache de respuestas frecuentes	8.000	1	90%	3	2.400	1
Resumen automático de tickets	5.000	2	80%	8	1.000	2
Agente autónomo multi-paso (H3)	6.000	3	30%	20	270	4
Traducción en 5 idiomas nuevos	2.000	1	90%	6	300	3
Spike: ¿el modelo alcanza 95%?	50	0.5	50%	2	6	(aparte)

Cómo leer la tabla:

El cache gana pese a un Impact de solo 1: su Reach enorme y su Effort mínimo lo catapultan. La lección de RICE en una fila: lo aburrido y masivo le gana a lo vistoso y caro.
El agente autónomo es la idea más excitante (Impact 3, Reach 6.000) y cae al cuarto lugar — la Confidence de 30% (riesgo técnico: no sabemos si funciona) y el Effort de 20 lo hunden. RICE castiga la apuesta incierta, y eso es exactamente el peligro del punto siguiente.
El spike puntúa 6, ridículo. Pero no compite en esta lista: su trabajo es subir la Confidence del agente de 30% a un número honesto. Se saca del ranking y se prioriza por valor de información. Si el spike sube la confianza a 70%, el agente re-puntúa a 630 y salta al segundo lugar. Ese es el eje de la IA operando: un ítem de RICE 6 desbloquea uno de RICE 630.

Tabla comparativa: cuándo usar cada framework

Framework	Fórmula / salida	Fortaleza	Su límite	Úsalo cuando
Valor vs esfuerzo	Matriz 2×2, cualitativa	Rapidísimo, visual	Solo 2 ejes, ignora alcance y confianza	Primera pasada, pocos ítems, decisiones baratas
RICE	(R × I × C) ÷ E	Desglosa valor, tiene confianza explícita	Falsa objetividad; R e I suelen inventarse	Comparar iniciativas dispares y caras
ICE	I × C × E (0–10)	El más rápido de puntuar	Todo subjetivo; manipulable	Muchos experimentos pequeños de bajo costo
Kano	Clasifica: básico / lineal / deleite	Distingue tipos de valor y satisfacción	No ordena ni mide costo	Decidir qué tipo de feature construir

Regla práctica: Kano para saber qué tipo de cosa es, RICE o valor/esfuerzo para ordenar cuánto pesa, y siempre la Confidence como el lugar donde metes el riesgo de la IA. Ningún framework es la respuesta; son lentes que se combinan.

Errores comunes

Priorizar IA con la planilla del software clásico. Sin el eje de incertidumbre, financias siempre lo seguro y matas la apuesta que valía aprender. El riesgo técnico vive en la Confidence; si la pones en 100% por comodidad, la fórmula miente.
Tratar el número de RICE como verdad. Es una ayuda para discutir, no un oráculo. Multiplicar cuatro estimaciones blandas no las vuelve un dato. El valor está en explicitar las razones, no en el ranking automático.
Matar los spikes por su puntaje bajo. Un experimento de conocimiento puntúa fatal en Reach e Impact por diseño. Se prioriza por cuánta incertidumbre disuelve, no por su RICE. Sácalo del ranking normal.
No tener lista de “no lo haremos”. Sin ella, cada descarte se reabre cada trimestre y ningún “no” tiene dueño. La lista de rechazos es gobierno de producto, no un basurero.
Poner todo el portafolio en un horizonte. Todo en apuestas H3 quema al equipo sin entregar; todo en mejoras H1 te deja obsoleto. La mezcla se reserva a propósito, con porcentajes, no con lo que sobra.
Dejar ganar al HiPPO. Si la prioridad la fija el cargo y no el criterio, el framework es teatro. Su única función real es darle a los datos una silla frente a la jerarquía.
Confundir ocupación con progreso (feature factory). Entregar mucho no es avanzar. Se mide por impacto en las métricas del producto, no por cantidad de features cerradas.

La frase para llevarse

“Ordenar buenas ideas es fácil y no sirve de nada: todas son buenas. El trabajo es decir que no a las que no caben, y en IA, apostar por la que quizás ni funcione — porque esa es la única que te enseña algo.”

Qué viene

Módulo 7: métricas y KPI. Priorizamos suponiendo que sabemos medir el “Impact” y el valor — pero ¿con qué número? En IA el KPI es traicionero: la exactitud del modelo no es el KPI del negocio, y optimizar la métrica equivocada te lleva rapidísimo al lugar incorrecto. Vamos a construir el árbol que conecta la métrica técnica del modelo con el resultado de negocio, y a distinguir las métricas que informan de las que solo decoran un dashboard.

Producto de IA — Módulo 6: priorización — decidir qué NO hacer