Plantilla de Roadmap de Experimentación (gratis)
Plantilla de roadmap de experimentación lista para copiar: columnas, score PIE e ICE, y la verificación de muestra que casi todo backlog olvida.
📚 Este artículo es parte de la guía Cómo Construir una Cultura de Experimentación (2026).
Un roadmap de experimentación es la cola priorizada y fechada de los tests que el equipo va a hacer, con hipótesis, métrica primaria, muestra necesaria y duración estimada en cada línea. No es un backlog de ideas: un backlog acumula, un roadmap compromete. Este artículo entrega la plantilla lista para copiar, explica cómo puntuar cada ítem con PIE o ICE, y cubre la columna que casi ningún framework de priorización incluye y que decide si el ítem es ejecutable de verdad: la viabilidad estadística. Tiene priorizador y calculadora en vivo, y un ejemplo trabajado en el que el ítem de mayor potencial del backlog cae del cuarto al último lugar de la cola cuando la duración entra en la cuenta. Este es uno de los artículos de la guía de cómo construir una cultura de experimentación.
Qué es un roadmap de experimentación (y qué no es)
La confusión más cara en esta área es tratar backlog y roadmap como sinónimos. Son dos artefactos con funciones distintas:
- Backlog de ideas: todo lo que apareció (pedido de stakeholder, hallazgo de sesión grabada, corazonada del equipo de ventas). No tiene orden, no tiene compromiso, y crecer es normal.
- Roadmap de experimentación: la porción del backlog que ya fue puntuada, dimensionada y ordenada. Cada ítem tiene hipótesis escrita, métrica primaria definida, muestra calculada y una ventana de ejecución. Aquí, crecer sin límite es síntoma de problema.
La diferencia práctica aparece en la reunión de planificación. Con backlog, la conversación es “qué creemos que funciona”. Con roadmap, es “el próximo ítem de la cola entra el lunes y corre 3 semanas”. La primera conversación se repite todos los meses, la segunda termina en cinco minutos.
La plantilla de roadmap de experimentación: las columnas que importan
Copia la tabla de abajo a tu planilla o base de conocimiento. Cada columna existe para responder una pregunta que suele aparecer en medio de la ejecución, cuando ya es tarde:
| Columna | Qué completar | Por qué existe |
|---|---|---|
| ID | Código corto y único (EXP-014) | Referenciar el test en panel, commit y reporte sin ambigüedad |
| Página o flujo | Dónde ocurre el cambio | Agrupar ítems que compiten por el mismo tráfico (dos tests en la misma página se estorban) |
| Hipótesis | Porque observé X, creo que Y va a causar Z, medido por W | Evita el test sin previsión, que no enseña nada cuando da empate |
| Métrica primaria | Una sola, elegida antes de correr | Impide el cambio de métrica después de ver el resultado |
| Guardrails | Métricas que no pueden empeorar | Protege ingresos, churn y reclamos mientras la primaria mejora |
| Tasa base actual | La conversión de hoy en esa métrica | Entra directo en el cálculo de muestra |
| MDE objetivo | Efecto mínimo que vale detectar | Define el tamaño del test; sin él no existe plazo |
| Muestra por variación | Salida de la calculadora | Vuelve la viabilidad un número, no una opinión |
| Duración estimada | Muestra total dividida por el tráfico diario | Transforma la cola en calendario |
| Score (PIE o ICE) | Promedio de las tres notas | Ordena la cola con criterio explícito |
| Estado | Idea, priorizado, corriendo, concluido, archivado | Muestra el trabajo en curso y limita el WIP |
| Resultado y decisión | Ganador, empate o perdedor, y qué se hizo | Se convierte en el repositorio de aprendizaje del equipo |
Dos columnas suelen generar discusión y vale la pena defender las dos. Guardrails existe porque casi todo experimento logra mejorar una métrica aislada a costa de otra: un popup más agresivo aumenta la captura de correo y empeora los reclamos. Resultado y decisión existe porque un roadmap sin memoria se vuelve una cinta transportadora que repite tests ya hechos apenas la rotación del equipo borra lo que se aprendió con ellos.
Cómo puntuar: PIE e ICE
Los dos frameworks más usados puntúan cada ítem de 1 a 10 en tres dimensiones y, en la formulación original de cada uno, sacan el promedio simple de las tres notas:
| Framework | Dimensiones | Origen | Cuándo encaja mejor |
|---|---|---|---|
| ICE | Impacto, Confianza, Facilidad | Atribuido a Sean Ellis, en el contexto de growth | Equipos que priorizan iniciativas variadas, no solo CRO de página |
| PIE | Potencial, Importancia, Facilidad | Creado por Chris Goward, en WiderFunnel, para proyectos de CRO | Equipos de CRO que necesitan considerar cuánto tráfico pasa por cada página |
Un aviso antes de elegir: circulan por ahí dos cuentas distintas para los mismos frameworks, una que saca el promedio de las tres notas y otra que multiplica las tres. El promedio es la formulación descrita en las fuentes originales de cada uno, es la que usa este artículo y es la que calcula el priorizador de abajo. Si adoptas la versión que multiplica, la escala cambia (de 1 a 1.000 en lugar de 1 a 10) y el orden final puede cambiar con ella, así que elige una cuenta y mantenla en el roadmap entero.
La diferencia real está en la segunda letra. En el ICE, Confianza pregunta “¿cuál es la chance de que esta hipótesis esté correcta?”, o sea, cuánta evidencia sostiene la hipótesis (Growth Method, ICE Framework). En el PIE, Importancia pregunta cuánto vale el tráfico de esa página. El propio Chris Goward define las páginas más importantes como las de mayor volumen y de tráfico más caro de comprar (Goward, Practical Ecommerce). Un rediseño brillante de una página que recibe 200 visitas por mes tiene Potencial alto e Importancia baja, y es justamente ese tipo de ítem el que el PIE empuja hacia abajo en la cola y el ICE no.
Ninguno de los dos es preciso, y es importante decirlo en voz alta: son notas subjetivas que sirven para volver explícito el desacuerdo, no para producir un número verdadero. Kohavi y Thomke, en la Harvard Business Review, sostienen justamente que ni siquiera los especialistas del área aciertan con regularidad qué cambios van a ganar, y que por eso vale testear ideas que la priorización por opinión descartaría. La ganancia real del score, entonces, no es el orden final: es la conversación que fuerza cuando dos personas dan 3 y 9 a la misma dimensión del mismo ítem.
Puntúa tu backlog ahora, eligiendo el framework en el selector, y exporta el ranking:
| # | Experimento | Potencial | Importancia | Facilidad | Score | Quitar experimento |
|---|---|---|---|---|---|---|
| - | - | |||||
| - | - | |||||
| - | - |
Nada de esto sale de tu navegador: la lista no se envía a ningún lado y el CSV se genera localmente. El score es el promedio de las tres notas, y la regla sirve para comparar ideas entre sí, no para adivinar cuál va a ganar el test.
La columna que falta en casi todo framework: viabilidad estadística
PIE e ICE responden “¿esto vale la pena?”. Ninguno de los dos responde “¿esto es ejecutable?”. Y esa segunda pregunta reprueba muchos ítems bien puntuados.
Un test solo termina cuando acumula muestra suficiente para detectar el efecto que buscas. Esa muestra depende de la tasa base, del efecto mínimo detectable (MDE) y del rigor estadístico elegido. Con la muestra en mano y el tráfico de la página, la duración se vuelve una división simple. La guía de cómo hacer un test A/B paso a paso cubre el cálculo en detalle; aquí interesa su efecto sobre la cola.
Mira tres ítems plausibles de un mismo backlog, todos con 18.000 visitantes por semana en el flujo testeado:
| Ítem | Tasa base | MDE objetivo | Muestra por variación | Duración |
|---|---|---|---|---|
| Nuevo layout de la página de producto | 3,2% | +12% relativo | 34.885 | 28 días |
| Mismo layout, ambición mayor | 3,2% | +20% relativo | 13.015 | 11 días |
| Nuevo flujo de registro (conversión en compra) | 1,1% | +15% relativo | 67.375 | 53 días |
Muestra por variación por aproximación normal de dos proporciones (95% de confianza, 80% de poder, bilateral); duración para 2 variaciones y 18.000 visitantes por semana.
El tercer ítem es el ejemplo del problema: casi dos meses de ejecución ocupando el flujo entero. Puede incluso ser el ítem de mayor potencial del backlog, y aun así aprobarlo significa gastar todo el trimestre en un único test. La salida no es ignorar la estadística, es reformular el ítem: buscar un efecto mayor (lo que cambia la naturaleza del cambio propuesto), mover la métrica primaria un nivel más arriba en el embudo (medir inicio de registro en lugar de compra), o aplicar el cambio en un flujo con más tráfico.
Calcula la muestra y la duración de cada línea de tu roadmap:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Ejemplo trabajado: la cola cambia cuando entra la duración
Un equipo de ecommerce puntuó seis ítems con PIE. Ordenados solo por el score, la cola saldría así (nota promedio de Potencial, Importancia y Facilidad):
| Ítem | P | I | F | Score PIE | Duración estimada |
|---|---|---|---|---|---|
| Nuevo flujo de registro | 9 | 8 | 4 | 7,0 | 53 días |
| Prueba social en la página de producto | 7 | 8 | 8 | 7,7 | 11 días |
| Envío gratis destacado en el carrito | 8 | 7 | 7 | 7,3 | 14 días |
| Rediseño de la página de categoría | 8 | 6 | 3 | 5,7 | 28 días |
| Nuevo texto del botón de checkout | 4 | 9 | 10 | 7,7 | 9 días |
| Video en la home | 6 | 4 | 5 | 5,0 | 35 días |
Por el score puro, el orden sería: prueba social y texto del botón empatados en 7,7, después envío gratis (7,3), después el nuevo flujo de registro (7,0). Ahora entra la columna de duración y la cola de ejecución real cambia de forma:
- Trimestre por el score, sin mirar duración: prueba social (11 días), texto del botón (9 días), envío gratis (14 días), registro (53 días). Total: 87 días, y el trimestre termina con 4 tests concluidos, de los cuales el último ocupó más de la mitad del calendario.
- Trimestre por score dividido por la duración: texto del botón (9 días), prueba social (11), envío gratis (14), rediseño de categoría (28). Total: 62 días, cuatro tests concluidos, y todavía sobran cerca de 4 semanas de calendario para un quinto test o para una repetición de confirmación.
El ítem de mayor potencial (registro) no fue descartado, fue postergado y reformulado: con la métrica primaria cambiada de compra a inicio de registro, la tasa base sube, la muestra cae y vuelve a la cola del trimestre siguiente con duración viable. Esa es la decisión que la columna de duración hace posible y que el score solo esconde.
Cadencia: cuántos ítems y con qué frecuencia revisar
Un roadmap útil es del tamaño de la capacidad real del equipo, y esa capacidad está limitada por el tráfico antes de estarlo por las personas. Si tu flujo banca dos tests por mes, una cola de 40 ítems priorizados no es planificación, es ficción: cuando llegue el ítem 20, el contexto que justificó su nota habrá cambiado. El artículo cuántos tests A/B deberías hacer por mes muestra cómo calcular esa capacidad a partir del tráfico, y es ella la que debe definir el tamaño de la cola.
Una cadencia que funciona bien en la práctica:
- Revisión mensual: reordena la cola con lo que enseñaron los tests concluidos, retira ítems que perdieron contexto y trae ítems nuevos del backlog crudo.
- Revisión a cada test concluido: un resultado cambia la confianza estimada de los ítems vecinos. Si la hipótesis de prueba social perdió en la página de producto, el ítem equivalente en la página de categoría merece una nota menor antes de entrar en la cola.
- Límite de trabajo en curso: un test a la vez en cada pantalla o flujo. Los programas grandes hacen decenas de experimentos simultáneos sin problema, porque tocan partes distintas del producto; la salvedad vale para dos tests que mueven los mismos elementos. En ese caso eliges entre hacer los dos en exclusión mutua, y ahí cada uno recibe la mitad del tráfico y tarda el doble, o dejar que el mismo visitante caiga en los dos, y ahí los dos cambios pueden sumarse de un modo que ninguna de las lecturas aisladas prevé (el ejemplo clásico es que cada test empuje el botón de compra un poco hacia abajo, y el visitante que recibió los dos nunca vea el botón). Kohavi, Tang y Xu tratan el diseño de programas con muchos experimentos concurrentes en Trustworthy Online Controlled Experiments.
Errores comunes en un roadmap de experimentación
| Error | Señal de alerta | Corrección |
|---|---|---|
| Cola mucho mayor que la capacidad | 40 ítems priorizados, 2 tests por mes | Dimensiona la cola por la capacidad de tráfico, deja el resto en el backlog crudo |
| Ítem sin hipótesis escrita | “Testear el botón rojo” | Escribe dato, cambio, efecto esperado y métrica antes de puntuar |
| Ignorar la duración al priorizar | Un ítem de 8 semanas entró como “quick win” | Agrega la columna de duración y ordena por score dividido por duración |
| Score inflado por quien lo propuso | Todo ítem del equipo de producto tiene Potencial 9 | Puntúa en dupla o en comité, y registra la divergencia |
| Sin guardrail definido | La conversión subió, nadie verificó reembolsos ni churn | Define 1 o 2 guardrails por ítem antes de correr |
| Roadmap sin columna de resultado | Nadie recuerda por qué se archivó el ítem | Registra resultado y decisión en cada línea concluida |
| Dos tests en el mismo flujo | Dos cambios simultáneos en el checkout | Un test por flujo, siempre |
Hazlo automático en Donnu
Un roadmap de experimentación solo se sostiene cuando cada línea suya tiene números reales detrás: muestra calculada, duración estimada y un veredicto honesto al final. Esa es exactamente la parte que Donnu automatiza: tú defines la hipótesis y la métrica primaria, Donnu dimensiona el test contra tu tráfico real, te avisa cuánto tiempo va a llevar antes de que apruebes la línea, y devuelve el resultado con el intervalo de confianza en lugar de un sello verde. El roadmap deja de ser una planilla de intenciones y se vuelve una cola con plazo confiable.
Empieza una prueba gratis de 14 días y dimensiona el próximo ítem de tu cola antes de aprobarlo. Para el resto del proceso, mira cómo construir una cultura de experimentación y cómo escribir una hipótesis de test A/B.
Referencias
- Growth Method. PIE Framework: prioritise marketing tests by Potential, Importance and Ease. Describe el framework creado por Chris Goward en WiderFunnel. growthmethod.com/pie-framework.
- Growth Method. ICE Framework: the original prioritisation framework for marketers. Describe el framework creado por Sean Ellis. growthmethod.com/ice-framework.
- Kohavi, R. y Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.
- Kohavi, R. ExP Platform: accelerating innovation through trustworthy experimentation. Material de referencia sobre programas de experimentación a escala. exp-platform.com.
Lee también:
Preguntas frecuentes
- ¿Qué es un roadmap de experimentación?
- Es la cola priorizada de los experimentos que el equipo va a hacer, con hipótesis, métrica primaria, tamaño de muestra estimado, duración y estado de cada ítem. A diferencia de un backlog de ideas, el roadmap ya respondió la pregunta "¿esto cabe en nuestro tráfico y en cuánto tiempo?", así que cada línea suya es un test que puede entrar en ejecución sin una nueva discusión.
- ¿Cuál es la diferencia entre PIE e ICE para priorizar experimentos?
- Los dos puntúan cada idea de 1 a 10 en tres dimensiones y, en la formulación original, sacan el promedio de las tres notas (parte de las implementaciones que circulan por ahí multiplica en lugar de promediar, lo que cambia la escala y puede cambiar el orden final). El ICE (Impacto, Confianza, Facilidad) se atribuye a Sean Ellis, en el contexto de growth, y sirve para cualquier tipo de iniciativa de crecimiento. El PIE (Potencial, Importancia, Facilidad), creado por Chris Goward en WiderFunnel para proyectos de optimización de conversión, cambia Confianza por Importancia, que mide cuánto tráfico e ingresos pasan por la página en cuestión. En la práctica, el PIE evita que el roadmap invierta en mejoras prometedoras en una página que casi nadie visita.
- ¿Qué olvida casi todo roadmap de experimentación?
- La viabilidad estadística. Un ítem puede tener score alto en cualquier framework y aun así ser imposible de ejecutar, porque el tráfico de la página no cierra la muestra necesaria dentro de un plazo aceptable. Antes de aprobar un ítem, calcula la muestra por variación y la duración estimada; si da más de 6 a 8 semanas, el ítem necesita reformularse (efecto mayor, métrica más arriba en el embudo o página con más tráfico), no solo agendarse.
- ¿Cuántos ítems debería tener un roadmap de experimentación?
- Los suficientes para cubrir de dos a tres meses de capacidad real de ejecución, no más. Un roadmap con 60 ideas y capacidad de 2 tests por mes es una lista de deseos que envejece: las prioridades cambian antes de que la cola avance. Dimensiona la cola por la capacidad que tu tráfico banca y mantén el resto como backlog crudo, sin fecha.
- ¿Con qué frecuencia revisar el roadmap?
- Una revisión mensual suele ser suficiente para reordenar la cola con lo que enseñaron los tests concluidos, más una revisión rápida siempre que termina un test. Los resultados cambian la confianza y el potencial estimados de los ítems vecinos, así que reordenar después de cada conclusión evita que el equipo ejecute una cola que ya quedó obsoleta.