La mayoría de equipos «hacen growth» así: alguien tiene una idea → se hace un test → a veces gana, a veces pierde → nadie documenta nada → se repite el ciclo. Eso no es experimentación, es ruleta.
Hace 18 meses mi equipo lanzaba 1 test cada 3 semanas. Hoy lanzamos 2 tests/semana de forma sostenida, con documentación automática, priorización matemática y cero reuniones de «¿qué test hacemos ahora?».
En este post te doy el sistema completo (no la teoría): el tablero, los rituales, las plantillas de priorización ICE adaptadas, el checklist de lanzamiento, el template de aprendizaje y la reunión semanal de 15 minutos que lo sostiene todo. Todo copiable a Vikunja/Notion/ClickUp/Linear en 10 minutos.
Te llevas: 1 tablero maestro (3 listas) + 1 plantilla de tarea única + 1 checklist DoR + 1 learning log template + 1 ritual semanal de 15 min + 3 trampas donde caí yo para que no caigas tú.
El problema real: Velocidad ≠ Prisa
La mayoría de equipos confunden hacer tests rápido con tener un sistema de experimentación. La diferencia es brutal:
- Velocidad = tests que avanzan, se documentan, generan aprendizaje compuesto y alimentan el siguiente.
- Prisa = tests que se lanzan sin hipótesis clara, mueren en «analizando», nadie aprende nada, y el siguiente test repite los mismos errores.
Mi punto de quiebre llegó en diciembre 2023: 3 tests en cola, 2 sin documentar, el equipo frustrado, yo de bottleneck absoluto revisando todo. El tablero era un cementerio de buenas intenciones.
Lo que NO funciona (probado en carne propia):
- Copiar el «Growth Process» de Airbnb/Booking sin adaptar contexto, equipo, stack ni presupuesto.
- Herramienta única (solo Jira, solo Notion, solo Excel) forzando el proceso a la tool.
- Priorización por «gut feeling del founder» → el test del jefe siempre gana, el del junior nunca se lanza.
Mi hipótesis de trabajo era simple: un sistema mínimo viable de experimentación necesita 4 piezas. Si falta una, el sistema se rompe:
- Entrada estructurada → ideas con formato obligatorio, no «se me ocurrió»
- Priorización sin debates → matemática (ICE/RICE), no política
- Ejecución con guardrails → checklist obligatorio antes de lanzar
- Aprendizaje obligatorio → learning log para cerrar el test, sin excepción
Tu marco: 3 Listas en Vikunja (y nada más)
No necesitas custom fields complejos, fórmulas ni automatizaciones. Necesitas disciplina + plantilla + límite WIP 2.
Las 3 listas
| Lista | Propósito | Límite WIP | Qué contiene |
|---|---|---|---|
| Backlog | Ideas crudas + scoring manual | ∞ | 1 tarea por experimento/hack/prompt con plantilla completa |
| Esta Semana | Tests en ejecución activa | 2 máximo | Solo 2 tareas activas. Owner + fecha + checklist DoR completo |
| Hecho & Aprendido | Archive + learning log | ∞ | Tareas cerradas con learning log relleno + decisión + próximo paso |
Eso es todo. Tres columnas. El poder está en lo que metes en cada tarea y el ritual semanal que las mueve.
Formato de tarea única (copia/pega en descripción)
## Hipótesis Creemos que [cambio específico] causará [Δ% en métrica] en [métrica primaria] porque [razón: psicología/mecánica/técnica]. ## Métricas - Primaria: [ej. Conversion Rate Checkout → Purchase] - Guardarraíl: [ej. Bounce Rate, Revenue Per Visitor, Support Tickets] ## Evidencia [Link a heatmap / grabación / data / entrevista / benchmark] ## Scoring (1-5) - Esfuerzo: [1=config only ... 5=dev+design+legal] - Confianza: [1=corazonada ... 5=data fuerte + precedentes] - Impacto: [1=marginal ... 5=game changer] - ICE: [calculas tú: Esfuerzo × Confianza × Impacto, máx 125] ## Tags #adquisición #activación #retención #ingresos #referral #technical #brand #legal #reversible ## Owner @tu_usuario ## Checklist DoR (Definition of Ready) - [ ] Hipótesis completa + evidencia - [ ] ICE ≥ 70 - [ ] Si #technical → dev confirmado - [ ] Diseño/QA ok - [ ] Métricas GA4 listas - [ ] Fecha fin + rollback - [ ] Learning log preparado (borrador WP) ## Learning Log (al cerrar) **Resultado:** [Ganador / Perdedor / Inconcluso / Parcial] **Métrica primaria:** [Control → Variante / p-value / lift] **Aprendizaje (1 frase):** [ej. "Los usuarios móviles responden a X pero desktop no → segmentar por device"] **Decisión:** [Implementar / Iterar / Descartar / Escalar] **Próximo paso:** [Test follow-up / Cambio permanente / Documentar para no repetir] **Link post WP:** [URL si publicas el learning log]
Principios rectores (inquebrantables)
- WIP Limit = 2 tests/semana (no más, no menos — fuerza foco real)
- Priorización matemática, no política (ICE + etiquetas de riesgo como contrapeso)
- Documentación = parte del test, no extra (checklist obliga a rellenar learning log para cerrar)
- Reunión semanal de 15 min, standing, async-first (solo desbloqueos en vivo)
Caso real: De 1.3 a 8.2 tests/mes en 6 meses
Contexto (Oct 2023 – Mar 2024)
- Equipo: 3 growth marketers + 1 dev part-time + 1 designer 0.5
- Stack: Notion (backlog/wiki), GA4/Mixpanel, VWO, Slack
- Restricción: 0 budget para herramientas enterprise, dev time = cuello de botella
Implementación semana a semana
Semana 1: Formulario de entrada estandarizado
Creé la plantilla de tarea (la de arriba) en Vikunja. Campo clave: Evidencia obligatoria. Sin link a heatmap/data/entrevista → la tarea no sale de Backlog. Esto mató las «corazonadas sin base» de raíz.
Semana 2: ICE scoring manual + etiquetas de riesgo
Fórmula: ICE = Esfuerzo × Confianza × Impacto (cada uno 1-5, máx 125). Añadí Risk Tag obligatorio:
technical(necesita dev)brand(toca copy/visual sensible)legal(compliance)reversible(fácil rollback)none
Regla de oro: Máx 1 test technical por semana. Protege dev time y fuerza creatividad sin código.
Semana 3: Checklist DoR (Definition of Ready)
Nada entra a «Esta Semana» sin marcar los 8 checks. El checklist vive en la descripción de la tarea, no en documento aparte. Si falta uno → no se lanza.
Semana 4: Ritual semanal (Lunes 9:00-9:15)
- Async (Slack/Vikunja, viernes-jueves): Owners actualizan estado → Growth Lead revisa scores → Top 3 propuestos
- Sync (15 min, lunes, standing): Solo 3 preguntas → ¿Qué test arranca? ¿Qué test cierra? ¿Qué bloquea?
Output: columna «Esta Semana» poblada, owners confirmados, bloqueadores escalados. Cero brainstorming, cero «qué opinas».
Resultados duros (Mar 2024 – Sep 2024, 6 meses)
| Métrica | Antes (Oct-Mar) | Después (Mar-Sep) | Delta |
|---|---|---|---|
| Tests lanzados/mes | 1.3 | 8.2 | +530% |
| Tests con learning log completo | 30% | 95% | +65pp |
| Tiempo idea → lanzamiento | 21 días | 6 días | -71% |
Tests technical completados | 2 | 14 | 7× |
| eNPS equipo (\»satisfecho con proceso\») | -12 | +38 | +50pp |
Qué NO funcionó (lecciones duras)
- Intentar RICE puro → Reach es ficción en B2B early stage. Volví a ICE + etiquetas.
