Si llevas más de seis meses en producto, ya habrás escuchado hablar de ICE. Impact, Confidence, Ease. Multiplica los tres, ordena de mayor a menor, y ya tienes tu backlog priorizado. Fácil, ¿verdad?
El problema es que la mayoría de los equipos usan ICE como si fuera una calculadora objetiva. No lo es. ICE es una herramienta para estructurar conversaciones, no para evitarlas.
Qué mide ICE (y qué no)
ICE fue popularizado por Sean Ellis en el contexto de growth hacking. Sus tres dimensiones son:
- Impact: ¿Cuánto va a mover la aguja si funciona?
- Confidence: ¿Qué tan seguros estamos de que va a funcionar?
- Ease: ¿Qué tan fácil es de implementar?
La fórmula es ICE = Impact × Confidence × Ease, con cada dimensión en escala del 1 al 10.
ICE no elimina la subjetividad. La hace explícita. Esa es su verdadera utilidad.
Cuando un PM dice "esto tiene Impact 9" y otro dice "yo lo veo como 5", esa conversación es el valor de ICE. No el número final.
Los errores más comunes
Error 1: Puntuar en el vacío
El ICE más inútil es el que se hace sin criterios claros. ¿Impact en qué? ¿En ingresos? ¿En retención? ¿En NPS? Si no defines la métrica objetivo antes de puntuar, cada persona está midiendo una cosa diferente.
Antes de empezar cualquier sesión de ICE, define:
Métrica principal del período: [ej. MAU, ingresos recurrentes, churn]
Escala de Impact:
1-3 → mejora marginal (<5% de variación en la métrica)
4-6 → mejora moderada (5-15%)
7-10 → mejora significativa (>15%)
Esto elimina la mitad de las discusiones.
Error 2: Ignorar las dependencias
ICE puntúa cada iniciativa de forma aislada. Pero en la práctica, algunas iniciativas son prerrequisitos de otras. Un score ICE de 120 no sirve de nada si la iniciativa necesita infraestructura que no existe.
La solución es añadir una columna de dependencias antes de ordenar. Cualquier iniciativa con dependencias no resueltas baja de prioridad automáticamente, independientemente del score.
Error 3: Usar ICE como argumento, no como herramienta
Este es el más peligroso. Cuando alguien llega a una reunión con un spreadsheet de ICE ya calculado y lo presenta como "la prioridad objetiva", ICE deja de ser útil.
El proceso debería ser colaborativo:
1. Listar las iniciativas candidatas (todo el equipo)
2. Definir criterios de puntuación (PM + stakeholders)
3. Puntuar individualmente (sin ver los scores de otros)
4. Compartir y discutir las diferencias > 3 puntos
5. Acordar scores finales y documentar el razonamiento
El paso 4 es donde ocurre la magia. Las diferencias grandes entre scores suelen revelar asunciones distintas sobre el negocio o el usuario.
Cuándo NO usar ICE
ICE funciona bien para comparar iniciativas dentro de un mismo horizonte temporal y con un mismo objetivo. Funciona mal cuando:
- Estás en modo exploración (no sabes qué construir, solo tienes hipótesis)
- Las iniciativas tienen magnitudes de esfuerzo radicalmente distintas
- El contexto estratégico está cambiando rápido
En esos casos, frameworks como RICE (que añade Reach como cuarta dimensión) o simplemente una matriz 2×2 de impacto vs. esfuerzo suelen ser más honestos.
La regla del 70%
Una heurística que uso bastante: si después de hacer ICE el equipo no está de acuerdo con el top 3 resultante en al menos un 70%, algo está mal en la definición de criterios, no en la priorización.
Cuando ICE contradice el instinto del equipo de forma sistemática, revisá los criterios antes de cuestionar el instinto.
Conclusión
ICE es una buena herramienta mal usada la mayoría del tiempo. Su valor no está en el número final sino en el proceso de llegar a él. Si tu equipo sale de una sesión de ICE con mayor claridad sobre las apuestas del período, cumplió su función.
Si solo salieron con un spreadsheet ordenado, probablemente te salteaste la parte importante.