Priorizar experimentos de crecimiento: ICE vs PIE vs PXL (con ejemplos)
Tienes 47 ideas de experimentos en un spreadsheet. Tu jefe quiere resultados para ayer. Tu equipo tiene capacidad para ejecutar máximo 3 tests este mes. Y tú estás ahí, mirando la pantalla, tratando de decidir por dónde empezar.
Si esto te suena familiar, no estás solo.
El problema no es la falta de ideas. El problema es que elegir mal cuesta caro. Cada experimento fallido no solo quema presupuesto, quema algo más valioso: tiempo. Y mientras tú estás testeando si el botón debería ser azul o verde, tu competencia está descubriendo un canal de adquisición que duplica su crecimiento.
La intuición no escala. Puede que tu "olfato" haya funcionado cuando lanzaste tu primer producto, pero cuando tienes un backlog de 50+ ideas y un equipo esperando dirección, necesitas algo más que corazonadas.
Ahí es donde entran los frameworks de priorización.
En este artículo vamos a diseccionar los tres más usados en growth y CRO: ICE, PIE y PXL. No te voy a vender ninguno como "el mejor" porque no existe tal cosa. Lo que sí existe es el framework correcto para tu contexto, tu equipo y tu nivel de madurez.
Al final, vas a saber exactamente cuándo usar cada uno, cómo aplicarlos paso a paso, y —quizás más importante— cuándo ignorarlos por completo.
Qué es la priorización de experimentos (y por qué debería importarte)
Antes de meternos en frameworks, aclaremos algo: priorizar no es elegir qué hacer. Es elegir qué NO hacer.
Suena obvio, pero la mayoría de equipos lo entiende al revés. Piensan que priorizar es encontrar "la idea ganadora" entre un montón de opciones. No. Priorizar es reconocer que tienes recursos limitados y que cada "sí" a una idea es un "no" implícito a todas las demás.
El ciclo de experimentación típico se ve así:
- Ideación: Generas hipótesis basadas en datos, insights de usuarios, benchmarks, etc.
- Priorización: Decides cuáles ejecutar primero (aquí es donde la mayoría falla)
- Ejecución: Diseñas, implementas y lanzas el experimento
- Análisis: Mides resultados y extraes conclusiones
- Aprendizaje: Documentas lo aprendido y alimentas el próximo ciclo
El cuello de botella casi siempre está en el paso 2. No porque sea difícil, sino porque la mayoría de equipos no tiene un sistema para hacerlo. Terminan priorizando por:
- Quién grita más fuerte en la reunión
- Lo que el CEO vio en un podcast
- Lo que "siempre hemos hecho"
- Lo que es más fácil de implementar (sin considerar impacto)
El resultado: meses de trabajo en optimizaciones que mueven la aguja un 0.3%, mientras ideas de alto impacto se pudren en el backlog.
Un estudio de WiderFunnel (la agencia que creó el framework PIE) encontró que equipos con priorización sistemática llegan a resultados ganadores 50% más rápido que los que trabajan ad-hoc. No porque sus ideas sean mejores, sino porque desperdician menos tiempo en ideas mediocres.
El objetivo real de un framework de priorización no es encontrar "la idea perfecta". Es maximizar la velocidad de aprendizaje. Cuanto más rápido valides o invalides hipótesis, más rápido descubres qué funciona en tu contexto específico.
Ahora sí, vamos a los frameworks.
Framework ICE: el clásico de growth hacking
Origen e historia
ICE fue creado por Sean Ellis, el tipo que acuñó el término "growth hacking" y fue Head of Growth en Dropbox y Eventbrite antes de que esas empresas fueran lo que son hoy. Después fundó GrowthHackers.com, donde el framework se popularizó.
El contexto es importante: ICE nació en startups de Silicon Valley donde la velocidad era más importante que la precisión. No tenían tiempo para análisis elaborados. Necesitaban un método que les permitiera priorizar en 5 minutos y salir a ejecutar.
Ellis lo llama un "minimum viable prioritization framework" — priorización mínima viable. La idea es que puedes obtener el 80% del valor con el 20% del esfuerzo. No es perfecto, pero es suficientemente bueno para tomar decisiones rápidas.
Los 3 componentes de ICE
I - Impact (Impacto)
La pregunta: Si este experimento funciona, ¿qué tan grande será el efecto en nuestra métrica clave?
No estamos hablando de "sería cool si..." sino de impacto cuantificable. ¿Estamos hablando de un +2% en conversión o de un +50%? ¿Afecta a 100 usuarios o a 100,000?
Escala típica:
- 1-3: Impacto marginal (nice to have)
- 4-6: Impacto moderado (mejora notable)
- 7-9: Impacto alto (game changer para esa métrica)
- 10: Impacto masivo (cambia el negocio)
C - Confidence (Confianza)
La pregunta: ¿Qué evidencia tenemos de que esto va a funcionar?
Aquí es donde entra la honestidad brutal. ¿Tienes datos de usuarios que respaldan esta hipótesis? ¿Has visto algo similar funcionar en otro contexto? ¿O es pura especulación?
Escala típica:
- 1-3: Corazonada, intuición, "se siente bien"
- 4-6: Evidencia indirecta (benchmarks, casos de competidores)
- 7-9: Evidencia directa (datos de analytics, feedback de usuarios)
- 10: Certeza casi total (has visto exactamente esto funcionar antes)
E - Ease (Facilidad)
La pregunta: ¿Qué tan fácil es implementar este experimento?
Considera tiempo de desarrollo, recursos necesarios, dependencias de otros equipos, y complejidad técnica. Un test que toma 2 horas de setup no es lo mismo que uno que requiere 2 sprints de desarrollo.
Escala típica:
- 1-3: Complejo (semanas de trabajo, múltiples equipos)
- 4-6: Moderado (días de trabajo, pocas dependencias)
- 7-9: Fácil (horas de trabajo, puedes hacerlo solo)
- 10: Trivial (cambio de copy, toggle de feature flag)
Cómo calcular el score ICE
La fórmula es simple:
ICE Score = Impact × Confidence × Ease
Multiplicas los tres valores. El rango teórico va de 1 (1×1×1) a 1000 (10×10×10), aunque en la práctica la mayoría de ideas caen entre 50 y 300.
Veamos un ejemplo con 5 experimentos hipotéticos para un SaaS B2B:
| Experimento | Impact | Confidence | Ease | ICE Score |
|---|---|---|---|---|
| Rediseñar página de pricing | 8 | 5 | 4 | 160 |
| Añadir chat en vivo | 6 | 7 | 8 | 336 |
| Cambiar CTA de "Registrarse" a "Empezar gratis" | 4 | 8 | 10 | 320 |
| Crear demo interactiva del producto | 9 | 6 | 3 | 162 |
| A/B test de subject lines en onboarding emails | 5 | 7 | 9 | 315 |
Según ICE, deberías priorizar: Chat en vivo (336) → CTA (320) → Emails (315) → Demo (162) → Pricing (160).
¿Significa que la demo interactiva es mala idea? No. Significa que dado el esfuerzo requerido y la evidencia disponible, hay opciones con mejor relación esfuerzo-resultado ahora mismo.
Cuándo usar ICE
ICE brilla en estos contextos:
- Startups early-stage donde no tienes histórico de experimentos ni datos robustos
- Equipos pequeños (1-5 personas) que necesitan moverse rápido
- Sesiones de brainstorming donde quieres filtrar rápidamente 30 ideas a 5
- Decisiones bajo incertidumbre cuando entras a un mercado nuevo o lanzas un producto
- Backlogs desordenados que necesitan una primera pasada de limpieza
Las limitaciones de ICE (hay que ser honestos)
ICE tiene problemas reales que debes conocer:
1. Es altamente subjetivo
Ponle el mismo experimento a 5 personas de tu equipo y vas a obtener 5 scores diferentes. ¿El impacto es 6 u 8? Depende de quién lo evalúe y qué tan optimista se sienta ese día.
2. La multiplicación puede distorsionar
Un experimento con scores 10-2-10 (Impact alto, Confidence baja, Ease alta) obtiene 200 puntos. Uno con 7-7-7 obtiene 343. ¿Es realmente mejor el segundo? La matemática dice que sí, pero la realidad es más matizada.
3. No distingue entre tipos de experimentos
Trata igual un cambio de copy (reversible en 5 minutos) que un rediseño de arquitectura (consecuencias a largo plazo). A veces necesitas esa distinción.
4. Puede generar falsa precisión
Un score de 287 vs 283 no significa nada en la práctica. Son esencialmente iguales. Pero el cerebro humano quiere ver al 287 como "mejor".
Con estas limitaciones en mente, veamos el siguiente framework.
Framework PIE: el favorito de CRO
Origen e historia
Chris Goward creó PIE mientras dirigía WiderFunnel, una de las agencias de CRO más reconocidas del mundo. El contexto era diferente al de ICE: agencias trabajando con clientes enterprise que tenían sitios web con millones de visitantes y decenas de páginas que podrían optimizarse.
La pregunta que PIE intenta responder es: "Tengo 50 páginas en mi sitio. ¿Cuál debería testear primero?"
Nota la diferencia con ICE. ICE pregunta "¿qué experimento hago?". PIE pregunta "¿dónde experimento?"
Los 3 componentes de PIE
P - Potential (Potencial)
La pregunta: ¿Cuánto margen de mejora tiene esta página o experiencia?
Una página con tasa de conversión del 0.5% cuando el benchmark de la industria es 3% tiene mucho potencial. Una página que ya convierte al 4% tiene menos margen (aunque no cero).
Para evaluar potencial, considera:
- Tasa de conversión actual vs benchmark
- Feedback negativo de usuarios sobre esa página
- Problemas de usabilidad evidentes
- Datos de heatmaps y grabaciones de sesión
I - Importance (Importancia)
La pregunta: ¿Qué tan valioso es el tráfico de esta página?
Aquí entra el volumen y la calidad. Una página con 500,000 visitas mensuales es más importante que una con 5,000 (asumiendo conversión similar). Pero una página de checkout con 5,000 visitas de usuarios con intención de compra puede ser más importante que una página de blog con 500,000 visitas de curiosos.
Para evaluar importancia:
- Volumen de tráfico
- Posición en el funnel (más abajo = generalmente más importante)
- Costo de adquisición de ese tráfico (tráfico pagado mayor que tráfico orgánico en urgencia)
- Revenue per visitor de esa página
E - Ease (Facilidad)
La pregunta: ¿Qué tan fácil es ejecutar un test en esta página?
Similar a ICE, pero con matices de CRO:
- Complejidad técnica de la página
- Dependencias con otros sistemas
- Restricciones políticas (¿el CEO tiene opiniones fuertes sobre esta página?)
- Recursos disponibles para implementar cambios
Cómo calcular el score PIE
Aquí viene una diferencia importante con ICE:
PIE Score = (Potential + Importance + Ease) / 3
PIE promedia en lugar de multiplicar. Esto tiene implicaciones:
- El rango es más acotado (1-10 en lugar de 1-1000)
- Un factor muy bajo no "destruye" el score como en ICE
- Favorece opciones balanceadas sobre opciones con picos extremos
Ejemplo aplicado a un ecommerce:
| Página | Potential | Importance | Ease | PIE Score |
|---|---|---|---|---|
| Homepage | 6 | 9 | 7 | 7.3 |
| Página de categoría | 7 | 8 | 6 | 7.0 |
| Página de producto | 8 | 9 | 5 | 7.3 |
| Carrito | 9 | 7 | 4 | 6.7 |
| Checkout | 9 | 10 | 3 | 7.3 |
Interesante: Homepage, Página de producto y Checkout empatan con 7.3. En estos casos, el criterio de desempate suele ser Importance (priorizar páginas más abajo en el funnel) o Ease (si hay empate, hacer primero lo más fácil para generar momentum).
Cuándo usar PIE
PIE es ideal cuando:
- Tienes un programa de CRO establecido y necesitas decidir dónde enfocar recursos
- Trabajas con sitios grandes (ecommerce, marketplaces, SaaS con múltiples productos)
- Tienes datos de analytics claros sobre tráfico, conversiones por página, etc.
- Necesitas justificar decisiones ante stakeholders — PIE es más "vendible" que intuición
- Tu equipo incluye no-técnicos — el promedio es más intuitivo que la multiplicación
La diferencia clave entre PIE e ICE
Vale la pena detenerse aquí porque mucha gente confunde estos frameworks:
- PIE evalúa DÓNDE testear (qué página, qué parte del funnel)
- ICE evalúa QUÉ testear (qué experimento específico ejecutar)
No son mutuamente excluyentes. Puedes usar PIE para decidir "vamos a enfocarnos en la página de producto" y luego usar ICE para priorizar "¿qué experimento hacemos primero en la página de producto?"
La otra diferencia es matemática: la multiplicación de ICE castiga severamente los scores bajos. Un experimento con Ease=2 está básicamente condenado en ICE, sin importar qué tan alto sea Impact. En PIE, ese mismo Ease=2 solo baja el promedio, no lo destruye.
Limitaciones de PIE
1. "Potencial" es difícil de estimar sin experiencia
¿Cómo sabes cuánto margen de mejora tiene una página si nunca has testeado en ella? Requiere intuición o benchmarks externos.
2. Asume que tienes datos de tráfico
Si no tienes analytics configurados o tu tráfico es muy bajo, "Importance" se vuelve un guess.
3. El promedio puede esconder problemas
Una página con scores 9-9-1 (alto potencial, alta importancia, imposible de testear) obtiene 6.3. Parece razonable, pero ese 1 en Ease es un red flag que el promedio suaviza.
Ahora veamos el framework que intentó resolver estas limitaciones.
Framework PXL: el más riguroso
Origen e historia
Peep Laja y el equipo de CXL (ConversionXL) crearon PXL después de años de frustración con ICE y PIE. Su argumento: "Estos frameworks son demasiado subjetivos. ¿Qué significa realmente un Impact de 7 vs 8? Cada persona lo interpreta diferente."
PXL intenta resolver esto con preguntas binarias y específicas. En lugar de pedir "califica el impacto del 1 al 10", pregunta cosas como "¿Este cambio está above the fold? Sí o no."
El resultado es un framework más complejo pero menos ambiguo.
Los factores de PXL (10 preguntas)
PXL usa aproximadamente 10 criterios agrupados en categorías. Los puntos varían según la importancia del criterio:
Grupo 1: Visibilidad del cambio
- ¿El cambio está above the fold? (2 puntos si sí)
- ¿El cambio es noticeable en los primeros 5 segundos? (2 puntos si sí)
La lógica: cambios que nadie ve no pueden impactar conversiones. Un botón escondido al final de una página de 3000 palabras va a tener menos impacto que uno prominente en el hero.
Grupo 2: Fundamento en datos
- ¿Está basado en datos de analytics? (1 punto)
- ¿Está basado en datos de user testing? (1 punto)
- ¿Está basado en eye-tracking o mouse tracking? (1 punto)
- ¿Está basado en datos cualitativos (encuestas, entrevistas)? (1 punto)
La lógica: hipótesis respaldadas por múltiples fuentes de datos tienen más probabilidad de ganar. Una idea que surgió de analytics + entrevistas + heatmaps es más robusta que "se me ocurrió en la ducha".
Grupo 3: Impacto potencial
- ¿Es una página de alto tráfico? (1 punto)
- ¿Aborda un insight del customer journey? (1 punto)
Grupo 4: Recursos
- ¿Qué tan fácil es implementar? (escala 1-3, donde 3 es muy fácil)
Cómo calcular el score PXL
Sumas los puntos de cada criterio. El máximo teórico es alrededor de 13-15 puntos (dependiendo de cómo configures la escala de facilidad).
Ejemplo con 5 hipótesis para un SaaS:
| Hipótesis | Above fold | 5 seg | Analytics | User test | Heatmap | Cualitativo | Alto tráfico | Journey | Ease | Total |
|---|---|---|---|---|---|---|---|---|---|---|
| Nuevo headline en homepage | 2 | 2 | 1 | 1 | 0 | 1 | 1 | 1 | 3 | 12 |
| Rediseño de tabla de pricing | 2 | 2 | 1 | 0 | 1 | 0 | 1 | 1 | 2 | 10 |
| Agregar testimonios al checkout | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 3 | 7 |
| Simplificar formulario de registro | 2 | 2 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 11 |
| Cambiar color del CTA | 2 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 3 | 8 |
Orden según PXL: Headline (12) → Formulario (11) → Pricing (10) → CTA (8) → Testimonios (7)
Observa cómo PXL penaliza el cambio de color del CTA (score 8). No porque sea mala idea, sino porque no tiene fundamento en datos. Es el típico test que "todos quieren hacer" pero que rara vez mueve la aguja significativamente.
Cuándo usar PXL
PXL es ideal cuando:
- Tienes un programa de CRO maduro con proceso de research establecido
- Ya generas hipótesis basadas en datos (no solo brainstorming)
- Tu equipo tiene capacidad de research — heatmaps, entrevistas, etc.
- Necesitas reducir subjetividad entre miembros del equipo
- Quieres documentar el razonamiento detrás de cada priorización
Personalización de PXL
Una característica importante: PXL fue diseñado para ser personalizado. Las 10 preguntas originales son un punto de partida, no una verdad absoluta.
Puedes agregar criterios relevantes para tu negocio:
- ¿Afecta a usuarios de alto LTV? (+2 puntos)
- ¿Es reversible fácilmente? (+1 punto)
- ¿Tenemos baseline claro para medir? (+1 punto)
O quitar criterios que no aplican:
- Si no haces eye-tracking, elimina ese criterio
- Si todas tus páginas son de alto tráfico, ese criterio no discrimina
Limitaciones de PXL
1. Complejidad = fricción
Evaluar 10 criterios para cada hipótesis toma tiempo. Si tienes 50 ideas en el backlog, son 500 evaluaciones. Algunos equipos abandonan el proceso por fatiga.
2. Requiere infraestructura de research
Si no tienes heatmaps, no haces user testing, y tu analytics está mal configurado, la mitad de los criterios quedan en cero. El framework asume que ya tienes un stack de research funcionando.
3. Puede generar parálisis por análisis
Equipos nuevos a veces se obsesionan con "hacer PXL correctamente" en lugar de simplemente ejecutar tests. El framework perfecto que no usas es peor que el framework imperfecto que sí usas.
4. Las preguntas binarias pueden sobre-simplificar
"¿Está above the fold?" Bueno, está parcialmente visible. ¿Cuenta? La realidad es más gris de lo que las preguntas sí/no permiten.
Comparativa: ICE vs PIE vs PXL
Tabla resumen
| Criterio | ICE | PIE | PXL |
|---|---|---|---|
| Creador | Sean Ellis (GrowthHackers) | Chris Goward (WiderFunnel) | Peep Laja (CXL) |
| Año aprox. | ~2010 | ~2012 | ~2015 |
| Contexto original | Startups de growth | Agencias de CRO | CRO basado en research |
| Complejidad | Baja (3 factores) | Baja (3 factores) | Alta (10+ factores) |
| Tiempo por evaluación | 1-2 minutos | 2-3 minutos | 10-15 minutos |
| Subjetividad | Alta | Alta | Media-Baja |
| Fórmula | Multiplicación | Promedio | Suma ponderada |
| Requiere datos previos | No | Parcialmente | Sí |
| Mejor para | Qué experimento hacer | Dónde experimentar | Qué experimento hacer (con rigor) |
| Ideal para equipos | Pequeños, ágiles | Medianos, con analytics | Maduros, con research |
Matriz de decisión: cuál usar según tu contexto
Usa ICE si:
- Eres una startup early-stage sin histórico de experimentos
- Tu equipo tiene menos de 5 personas
- Necesitas priorizar 30+ ideas en una sesión de 2 horas
- No tienes analytics robustos ni proceso de research
- Valoras velocidad sobre precisión
Usa PIE si:
- Trabajas en CRO para un sitio con múltiples páginas de alto tráfico
- Tienes Google Analytics (o similar) bien configurado
- Necesitas decidir DÓNDE enfocar recursos antes de decidir QUÉ testear
- Trabajas con stakeholders que necesitan justificación estructurada
- Tu equipo incluye personas no técnicas
Usa PXL si:
- Tienes un programa de CRO establecido hace 6+ meses
- Ya generas hipótesis basadas en múltiples fuentes de datos
- Quieres reducir la variabilidad entre evaluadores
- Puedes invertir 10-15 minutos por hipótesis
- Tu equipo tiene la disciplina para mantener el proceso
Mi recomendación
Si me preguntas qué framework usar, mi respuesta es: el que tu equipo realmente vaya a usar.
Suena como respuesta de político, pero es la verdad. Un ICE usado consistentemente supera a un PXL abandonado después de 3 semanas porque era "demasiado trabajo".
Dicho esto, hay una progresión natural:
- Empieza con ICE — Baja barrera de entrada, te obliga a pensar en Impact/Confidence/Ease
- Evoluciona a PIE cuando tengas datos de analytics claros y quieras enfocar por página/área
- Gradúa a PXL cuando tu proceso de research esté maduro y quieras reducir subjetividad
También puedes combinarlos: PIE para decidir "vamos a enfocarnos en checkout este quarter" y luego ICE o PXL para priorizar los experimentos específicos dentro de checkout.
Cómo implementar un framework en tu equipo
Elegir un framework es el 20%. Implementarlo consistentemente es el 80%. Aquí hay un proceso que funciona:
Paso 1: Elige uno y comprométete
El peor error es estar saltando entre frameworks cada mes. "Este mes usamos ICE, el próximo PIE, después probamos RICE..."
Elige uno. Dale mínimo 3 meses antes de evaluar si funciona. La consistencia genera aprendizaje; el cambio constante genera confusión.
Paso 2: Calibra el scoring con tu equipo
Antes de usar el framework en producción, haz una sesión de calibración:
- Elige 5 experimentos pasados (idealmente con resultados conocidos)
- Cada miembro del equipo los puntúa independientemente
- Comparen resultados en grupo
- Discutan las diferencias: "¿Por qué tú pusiste Impact 8 y yo puse 5?"
- Definan criterios compartidos: "Para nosotros, Impact 8+ significa que afecta revenue directamente"
Este proceso alinea la interpretación del framework y reduce la variabilidad entre personas.
Paso 3: Documenta tus aprendizajes
Después de cada experimento completado, revisa:
- ¿El score predijo correctamente el resultado?
- ¿Subestimamos o sobreestimamos algún factor?
- ¿Hay patrones en los errores de predicción?
Esta retroalimentación mejora tu calibración con el tiempo. Después de 20-30 experimentos, vas a ser mucho mejor prediciendo Impact y Confidence que cuando empezaste.
Paso 4: Revisa el backlog regularmente
Los scores no son permanentes. Un experimento que era Ease=3 hace 6 meses puede ser Ease=8 hoy si tu equipo de desarrollo implementó mejores herramientas.
Programa una revisión mensual o trimestral del backlog:
- Elimina ideas obsoletas
- Re-evalúa scores de ideas que llevan tiempo en el backlog
- Incorpora nuevos datos que hayan surgido
Errores comunes (y cómo evitarlos)
Error 1: Sobre-optimizar el scoring en vez de ejecutar
He visto equipos pasar 3 horas debatiendo si un experimento es Impact 7 u 8. Mientras tanto, no han ejecutado un solo test en el mes.
El framework es una herramienta de decisión, no un fin en sí mismo. Si el debate dura más de 5 minutos, voten y sigan adelante.
Error 2: No revisar scores después de tener resultados
El experimento terminó. ¿Ganó o perdió? Bien, pero ¿aprendiste algo sobre tu capacidad de priorizar?
Si consistentemente subestimas Impact de cierto tipo de experimentos, eso es información valiosa. Ajusta tu calibración.
Error 3: Usar el framework para justificar decisiones ya tomadas
"El jefe quiere testear esto, así que vamos a ponerle scores altos para que salga primero."
Si vas a hacer esto, mejor no uses framework. La priorización forzada destruye la confianza del equipo en el proceso.
Error 4: Ignorar ideas de bajo score que podrían ser "big swings"
No todo lo que vale la pena testear va a tener score alto. A veces necesitas experimentos arriesgados con bajo Confidence pero alto Impact potencial.
Una buena práctica: reserva 20% de tu capacidad para "big swings" que no necesariamente pasan el filtro del framework. La diversificación también aplica en experimentación.
Error 5: No documentar el razonamiento detrás del score
Un número sin contexto es inútil 3 meses después. ¿Por qué le pusimos Confidence 7? ¿Qué datos respaldaban esa evaluación?
Agrega una columna de "notas" a tu spreadsheet. Tu yo del futuro te lo agradecerá.
Herramientas y plantillas
No necesitas software sofisticado. Un Google Sheet bien estructurado funciona perfectamente para la mayoría de equipos.
Estructura básica para cualquier framework:
- Columna A: ID del experimento
- Columna B: Nombre/descripción de la hipótesis
- Columnas C-E (o más): Factores del framework elegido
- Columna F: Score calculado (fórmula automática)
- Columna G: Estado (backlog, en progreso, completado)
- Columna H: Resultado (ganó/perdió/inconcluso)
- Columna I: Notas y aprendizajes
Herramientas que pueden ayudar:
- Notion o Airtable: Si prefieres bases de datos relacionales sobre spreadsheets
- Asana o Monday: Si quieres integrar priorización con gestión de proyectos
- Herramientas de A/B testing: Optimizely, VWO, y Google Optimize (RIP) tienen funcionalidades de priorización integradas
Pero honestamente, he visto programas de CRO de millones de dólares gestionados en Google Sheets. La herramienta importa menos que el proceso.
Conclusión: el meta-aprendizaje
Después de leer 5,000 palabras sobre frameworks de priorización, quiero que te quedes con esto:
Ningún framework es perfecto. ICE es subjetivo. PIE asume datos que quizás no tienes. PXL es complejo. Todos tienen limitaciones porque todos intentan simplificar algo inherentemente complejo: predecir el futuro.
El valor está en el proceso, no en el número. Un score de 287 no significa nada por sí solo. Lo que importa es la conversación que generó: "¿Por qué crees que el impacto es alto? ¿Qué datos tenemos? ¿Qué no sabemos?"
La priorización te obliga a pensar antes de actuar. Y eso, en un mundo donde todos quieren "moverse rápido y romper cosas", es valioso. Pensar 30 minutos antes de ejecutar puede ahorrarte semanas de trabajo en la dirección equivocada.
La consistencia supera a la perfección. Un framework mediocre usado consistentemente durante 12 meses genera más aprendizaje que el framework perfecto abandonado después de 3 semanas.
Entonces, ¿qué framework vas a usar?
Mi sugerencia: si nunca has usado uno, empieza con ICE esta semana. Prioriza tus próximos 10 experimentos. Ejecútalos. Revisa qué tan bien predijeron los scores. Ajusta. Repite.
En 3 meses vas a saber más sobre priorización de lo que cualquier artículo puede enseñarte. Incluyendo este.
