Experimentation
Esta Collection convierte supuestos en un sistema de validación priorizada.
Assumption Mapping
Identificar y organizar los supuestos del venture.
Lista maestra de supuestos
Habilidad: Recopilar todos los supuestos críticos sobre los que descansa el modelo de negocio del startup.
¿Por qué importa esta habilidad?
Todo modelo de negocio es una serie de supuestos. Si los supuestos nunca se documentan, nunca se pueden validar. El primer paso de cualquier sistema de experimentación es tener la lista completa.
Qué se ve como un buen resultado
El equipo tiene una lista maestra de todos los supuestos del venture —sobre el cliente, el problema, la solución, el modelo y el impacto— organizada de forma que permite priorizarlos.
Errores comunes
- Confundir supuestos con hechos conocidos.
- Listar solo los supuestos que parecen más fáciles de validar.
- Hacer la lista una vez y no actualizarla.
- No distinguir entre supuestos del cliente y supuestos del modelo.
Preguntas que el startup debe responder
- ¿Qué tiene que ser verdad sobre el cliente para que el modelo funcione?
- ¿Qué tiene que ser verdad sobre el problema?
- ¿Qué tiene que ser verdad sobre la solución?
- ¿Qué tiene que ser verdad sobre el modelo de negocio y el impacto?
Artifact requerido
📄 Registro maestro de supuestos
Propósito: Documentar todos los supuestos del venture de forma organizada para facilitar la priorización y validación.
Card vinculada: Lista maestra de supuestos
Instrucciones de desarrollo
- Divide los supuestos en cuatro categorías: cliente, problema, solución, modelo.
- Lista al menos tres supuestos por categoría.
- Para cada supuesto, evalúa: ¿es hecho conocido o hipótesis? Si es hecho, retíralo de la lista.
- Marca cuáles ya tienen evidencia parcial y cuáles son pura hipótesis.
Estado esperado: Registro con 12 o más supuestos en cuatro categorías, clasificados como hecho o hipótesis.
Criterios de revisión del Artifact
- Al menos 12 supuestos en cuatro categorías.
- Cada supuesto es verificablemente una hipótesis, no un hecho.
- El estado de evidencia está marcado.
- El registro es conocido y accesible para todo el equipo.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El registro tiene 12 o más supuestos en cuatro categorías.
- El estado de evidencia está marcado para cada uno.
- El equipo usa el registro como base para priorizar la validación.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ninguna lista de supuestos. |
| En progreso | Hay supuestos informales no documentados. |
| Completo | El registro tiene 12 o más supuestos en cuatro categorías. |
| Revisado | El estado de evidencia está marcado. |
| Cumple estándar | El registro es la base del sistema de experimentación del venture. |
| Fuerte/Sobresaliente | Se actualiza con cada ciclo de aprendizaje y refleja el estado actual del modelo. |
Cards relacionadas / siguiente paso
- Supuestos de cliente y mercado
- Impacto e incertidumbre
- Supuestos a preguntas
Supuestos de cliente y mercado
Habilidad: Aislar los supuestos específicamente relacionados con el cliente y el mercado Beachhead para priorizarlos.
¿Por qué importa esta habilidad?
Los supuestos de cliente y mercado son los que más frecuentemente invalidan una startup. Son también los más fáciles de validar con discovery. Aislarlos permite trabajarlos de forma sistemática.
Qué se ve como un buen resultado
El equipo tiene una lista específica de los supuestos de cliente y mercado del Beachhead, con estado de validación y plan de acción para los más críticos.
Errores comunes
- Mezclar supuestos de cliente con supuestos de producto o modelo.
- No priorizar los supuestos de cliente por impacto en el modelo.
- Asumir que el discovery ya validó todos los supuestos de cliente.
- No actualizar la lista cuando el Beachhead cambia.
Preguntas que el startup debe responder
- ¿Qué supuestos tenemos sobre quién es el comprador ideal?
- ¿Qué supuestos tenemos sobre la frecuencia y urgencia del problema?
- ¿Qué supuestos tenemos sobre el tamaño del mercado?
- ¿Cuáles de estos supuestos son más críticos para la viabilidad?
Artifact requerido
📄 Lista de supuestos de cliente y mercado
Propósito: Aislar y documentar los supuestos de cliente y mercado con estado de validación y prioridad.
Card vinculada: Supuestos de cliente y mercado
Instrucciones de desarrollo
- Extrae del registro maestro todos los supuestos de las categorías "cliente" y "problema/mercado".
- Para cada supuesto, evalúa: ¿qué evidencia tenemos? ¿es suficiente para declararlo validado?
- Clasifica el nivel de validación: no validado, validación parcial, validado.
- Prioriza los no validados por impacto en el modelo.
Estado esperado: Lista con supuestos de cliente y mercado, nivel de validación y prioridad para los no validados.
Criterios de revisión del Artifact
- Todos los supuestos de cliente y mercado del registro están incluidos.
- El nivel de validación está clasificado para cada uno.
- Los no validados están priorizados por impacto.
- La lista está conectada con el plan de discovery.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La lista tiene todos los supuestos de cliente y mercado con nivel de validación.
- Los no validados están priorizados.
- La lista orienta el próximo ciclo de discovery.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ninguna lista específica de supuestos de cliente. |
| En progreso | Los supuestos de cliente están mezclados con otros sin priorización. |
| Completo | La lista tiene supuestos con nivel de validación básico. |
| Revisado | Los no validados están priorizados por impacto. |
| Cumple estándar | La lista guía el plan de discovery y se actualiza con cada ciclo. |
| Fuerte/Sobresaliente | Es la referencia central para conectar el discovery con el modelo de negocio. |
Cards relacionadas / siguiente paso
- Lista maestra de supuestos
- Impacto e incertidumbre
- Mom Test
Impacto e incertidumbre
Habilidad: Clasificar los supuestos del venture por su importancia para el modelo y por su nivel de incertidumbre.
¿Por qué importa esta habilidad?
No todos los supuestos merecen el mismo esfuerzo de validación. Los supuestos con alto impacto y alta incertidumbre son los que el equipo debe validar primero. Esta clasificación es el motor de la priorización de experimentos.
Qué se ve como un buen resultado
El equipo tiene una matriz impacto-incertidumbre con todos los supuestos del registro posicionados, y puede identificar el cuadrante prioritario para enfocar los experimentos.
Errores comunes
- Clasificar todos los supuestos como "alto impacto" sin criterio.
- Priorizar los supuestos fáciles de validar en lugar de los más críticos.
- Hacer la matriz una vez y no actualizarla.
- No usar la matriz para decidir qué experimento diseñar primero.
Preguntas que el startup debe responder
- ¿Cuáles supuestos invalidarían el modelo si resultan falsos?
- ¿Cuáles supuestos tenemos menos evidencia para respaldar?
- ¿Hay supuestos de alto impacto que son relativamente fáciles de validar?
- ¿Cuándo fue la última vez que actualizamos la posición de los supuestos?
Artifact requerido
📄 Matriz impacto-incertidumbre
Propósito: Posicionar todos los supuestos del registro en una matriz de dos ejes para priorizar la validación.
Card vinculada: Impacto e incertidumbre
Instrucciones de desarrollo
- Dibuja una matriz con impacto (bajo a alto) en el eje Y e incertidumbre (baja a alta) en el eje X.
- Posiciona cada supuesto del registro en la matriz.
- Identifica el cuadrante prioritario: alto impacto + alta incertidumbre.
- Lista los tres supuestos más prioritarios para diseñar experimentos.
Estado esperado: Matriz con todos los supuestos posicionados y cuadrante prioritario identificado.
Criterios de revisión del Artifact
- Todos los supuestos del registro están en la matriz.
- La posición tiene justificación para los más críticos.
- El cuadrante prioritario está identificado.
- Los tres supuestos más urgentes están listados.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La matriz tiene todos los supuestos posicionados.
- El cuadrante prioritario está identificado.
- El equipo usa la matriz para priorizar los próximos experimentos.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay clasificación de supuestos por impacto e incertidumbre. |
| En progreso | La clasificación es intuitiva y no documentada. |
| Completo | La matriz tiene los supuestos posicionados con criterio básico. |
| Revisado | El cuadrante prioritario está identificado y justificado. |
| Cumple estándar | La matriz guía el diseño de experimentos y se actualiza con el aprendizaje. |
| Fuerte/Sobresaliente | Es la herramienta central del sistema de experimentación del venture. |
Cards relacionadas / siguiente paso
- Lista maestra de supuestos
- Priorización de validación
- Registro de evidencia
Experiment Design
Diseñar pruebas útiles para validar supuestos prioritarios.
Priorización de validación
Habilidad: Decidir qué supuesto validar primero usando criterios de impacto, incertidumbre y coste de validación.
¿Por qué importa esta habilidad?
Validar los supuestos equivocados en el orden equivocado es costoso. La priorización de validación asegura que el equipo ataque primero los supuestos que más importan y que son verificables con los recursos disponibles.
Qué se ve como un buen resultado
El equipo tiene un ranking de supuestos a validar con criterios explícitos, y el próximo experimento ya está diseñado para el supuesto más prioritario.
Errores comunes
- Validar primero lo que es más fácil en lugar de lo más importante.
- No considerar el costo de validación en la priorización.
- Cambiar el supuesto a validar en cada semana sin completar ninguno.
- No documentar el razonamiento detrás del orden elegido.
Preguntas que el startup debe responder
- ¿Cuál es el supuesto que, si resulta falso, cambia todo?
- ¿Cuál supuesto podemos validar con menos recursos?
- ¿Hay un supuesto que bloquea a todos los demás?
- ¿Con qué supuesto deberíamos empezar esta semana?
Artifact requerido
📄 Ranking de supuestos prioritarios
Propósito: Documentar el orden de validación de supuestos con criterios explícitos y próximo experimento definido.
Card vinculada: Priorización de validación
Instrucciones de desarrollo
- Toma los supuestos del cuadrante prioritario de la matriz impacto-incertidumbre.
- Añade un tercer criterio: costo de validación (alto, medio, bajo).
- Ordena los supuestos: primero los de alto impacto + alta incertidumbre + bajo costo de validación.
- Define el próximo experimento para el supuesto número uno.
Estado esperado: Ranking con supuestos ordenados, criterios explícitos y próximo experimento definido.
Criterios de revisión del Artifact
- Los supuestos prioritarios están ordenados con tres criterios.
- El razonamiento del orden está documentado.
- El próximo experimento está definido para el supuesto número uno.
- El ranking está alineado con la matriz impacto-incertidumbre.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El ranking tiene los supuestos prioritarios ordenados con criterios.
- El próximo experimento está definido.
- El equipo sigue el ranking para organizar el trabajo de validación.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ningún ranking de validación. |
| En progreso | El ranking existe informalmente. |
| Completo | El ranking tiene supuestos ordenados con criterios básicos. |
| Revisado | El próximo experimento está definido y alineado con el ranking. |
| Cumple estándar | El ranking guía la planificación semanal del equipo. |
| Fuerte/Sobresaliente | Se actualiza con cada experimento completado y refleja el estado actual de la validación. |
Cards relacionadas / siguiente paso
- Impacto e incertidumbre
- Diseño de experimento
- Evidencia Loop
Diseño de experimento
Habilidad: Estructurar una prueba controlada para validar o refutar un supuesto específico.
¿Por qué importa esta habilidad?
Un experimento bien diseñado produce evidencia inequívoca. Un experimento mal diseñado produce ruido. La diferencia está en tener una hipótesis clara, un método apropiado y criterios de éxito definidos antes de empezar.
Qué se ve como un buen resultado
El equipo tiene una ficha de experimento completa que define: qué supuesto se prueba, qué se hará, qué resultado esperado confirma o refuta la hipótesis, y cuándo se evalúa.
Errores comunes
- Empezar el experimento antes de definir qué lo haría exitoso.
- Diseñar experimentos que no pueden falsificar la hipótesis.
- Cambiar el método del experimento a mitad de camino.
- No definir un tiempo límite para el experimento.
Preguntas que el startup debe responder
- ¿Cuál es el supuesto exacto que este experimento prueba?
- ¿Qué resultado confirmaría el supuesto y cuál lo refutaría?
- ¿Cuál es el método más rápido y barato para obtener evidencia?
- ¿En cuánto tiempo obtendremos resultados?
Artifact requerido
📄 Ficha de diseño de experimento
Propósito: Documentar el diseño de un experimento con hipótesis, método, criterios de éxito y tiempo límite.
Card vinculada: Diseño de experimento
Instrucciones de desarrollo
- Escribe el supuesto a validar en una frase clara.
- Define el método: ¿cómo se obtendrá la evidencia? (entrevista, prototipo, landing, piloto)
- Define los criterios de éxito: ¿qué resultado confirma? ¿qué resultado refuta?
- Define el tiempo límite y los recursos necesarios.
Estado esperado: Ficha con supuesto, método, criterios de éxito, tiempo límite y recursos.
Criterios de revisión del Artifact
- El supuesto está formulado como una hipótesis falsificable.
- El método puede producir evidencia inequívoca.
- Los criterios de éxito y fracaso están definidos antes de empezar.
- El tiempo límite y los recursos están definidos.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La ficha está completa antes de comenzar el experimento.
- Los criterios de éxito están definidos y son medibles.
- El equipo sigue la ficha para ejecutar el experimento.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay diseño de experimento documentado. |
| En progreso | El experimento existe pero sin criterios de éxito definidos. |
| Completo | La ficha tiene supuesto, método y criterios básicos. |
| Revisado | Todos los elementos están definidos antes de empezar. |
| Cumple estándar | La ficha produce evidencia que realmente prueba la hipótesis. |
| Fuerte/Sobresaliente | El diseño es reproducible y auditable como parte del repositorio de evidencia. |
Cards relacionadas / siguiente paso
- Priorización de validación
- Señales esperadas
- Registro de evidencia
Señales esperadas
Habilidad: Definir qué resultado confirmaría o refutaría una hipótesis antes de ejecutar el experimento.
¿Por qué importa esta habilidad?
Sin señales definidas antes del experimento, cualquier resultado puede interpretarse como confirmación. Las señales esperadas son el mecanismo que protege al equipo de la confirmación sesgada.
Qué se ve como un buen resultado
Para cada experimento diseñado, el equipo tiene documentado: qué resultado específico confirma la hipótesis, qué resultado específico la refuta y qué resultado es ambiguo.
Errores comunes
- Definir las señales de éxito después de ver los resultados.
- Usar métricas tan vagas que no permiten distinguir éxito de fracaso.
- No considerar el resultado ambiguo y qué hacer si ocurre.
- Cambiar las señales cuando el resultado no es el esperado.
Preguntas que el startup debe responder
- ¿Qué número o comportamiento específico confirmaría el supuesto?
- ¿Qué número o comportamiento específico lo refutaría?
- ¿Cuál es el resultado ambiguo y qué haríamos en ese caso?
- ¿Las señales son observables antes de que termine el experimento?
Artifact requerido
📄 Hoja de criterios de validación
Propósito: Documentar las señales de éxito, fracaso y ambigüedad para cada experimento antes de ejecutarlo.
Card vinculada: Señales esperadas
Instrucciones de desarrollo
- Para el experimento en curso, escribe: señal de confirmación = [resultado específico].
- Escribe: señal de refutación = [resultado específico diferente].
- Escribe: señal ambigua = [resultado intermedio] y define el siguiente paso si ocurre.
- Fija el momento de evaluación: ¿cuándo y cómo se medirán las señales?
Estado esperado: Hoja con las tres señales definidas y momento de evaluación establecido.
Criterios de revisión del Artifact
- Las tres señales (confirmación, refutación, ambigüedad) están definidas.
- Las señales son específicas y medibles.
- El momento de evaluación está definido.
- El siguiente paso para el resultado ambiguo está documentado.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La hoja de criterios está completa antes de comenzar el experimento.
- Las señales son específicas y no requieren interpretación subjetiva.
- El equipo usa la hoja para evaluar los resultados del experimento.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay señales definidas antes del experimento. |
| En progreso | Las señales existen pero son vagas. |
| Completo | La hoja tiene las tres señales definidas de forma básica. |
| Revisado | Las señales son específicas y medibles. |
| Cumple estándar | Las señales protegen al equipo de la confirmación sesgada. |
| Fuerte/Sobresaliente | La hoja es el insumo para el registro de evidencia y la decisión de pivotar/perseverar. |
Cards relacionadas / siguiente paso
- Diseño de experimento
- Registro de evidencia
- Decisión pivotar o perseverar
Evidence Loop
Convertir resultados en decisiones de aprendizaje.
Registro de evidencia
Habilidad: Documentar los resultados de cada experimento de validación de forma organizada y auditable.
¿Por qué importa esta habilidad?
Sin un registro de evidencia, el aprendizaje del equipo queda en memorias individuales. El registro convierte los experimentos en un activo acumulativo que informa las decisiones futuras.
Qué se ve como un buen resultado
El equipo tiene un repositorio donde cada experimento completado tiene documentados: el supuesto probado, el método, los resultados observados y la conclusión.
Errores comunes
- Hacer experimentos sin documentar los resultados.
- Documentar solo los experimentos exitosos e ignorar los fallidos.
- Guardar la evidencia en documentos dispersos sin estructura.
- No conectar los resultados con la actualización del modelo.
Preguntas que el startup debe responder
- ¿Dónde guardamos los resultados de los experimentos?
- ¿Los resultados negativos están documentados con el mismo rigor que los positivos?
- ¿Alguien del equipo puede revisar el historial de validaciones en 10 minutos?
- ¿Cuándo fue la última vez que actualizamos el modelo a partir de un resultado?
Artifact requerido
📄 Repositorio de evidencia
Propósito: Documentar todos los experimentos y sus resultados en un repositorio accesible y auditable.
Card vinculada: Registro de evidencia
Instrucciones de desarrollo
- Crea una entrada por experimento completado con: supuesto, método, fecha, resultados, conclusión.
- Clasifica la conclusión: confirmado, refutado, ambiguo.
- Conecta la conclusión con el impacto en el modelo: ¿qué cambió?
- Organiza el repositorio de forma que cualquier miembro del equipo pueda encontrar cualquier experimento.
Estado esperado: Repositorio con todos los experimentos documentados, clasificados y conectados al modelo.
Criterios de revisión del Artifact
- Cada experimento completado tiene una entrada.
- La clasificación (confirmado/refutado/ambiguo) está definida.
- El impacto en el modelo está documentado.
- El repositorio es accesible a todo el equipo.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El repositorio tiene todos los experimentos completados documentados.
- Las conclusiones están clasificadas y conectadas al modelo.
- El repositorio es la referencia central del aprendizaje del equipo.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay repositorio de evidencia. |
| En progreso | Los resultados están documentados en notas dispersas. |
| Completo | El repositorio tiene todos los experimentos con clasificación básica. |
| Revisado | El impacto en el modelo está documentado para cada experimento. |
| Cumple estándar | El repositorio es la base de las decisiones de pivotar/perseverar. |
| Fuerte/Sobresaliente | Se actualiza con cada experimento y es auditable por terceros. |
Cards relacionadas / siguiente paso
- Diseño de experimento
- Señales esperadas
- Decisión pivotar o perseverar
Decisión pivotar o perseverar
Habilidad: Interpretar la evidencia acumulada y tomar una decisión documentada sobre si continuar o cambiar de dirección.
¿Por qué importa esta habilidad?
La decisión de pivotar o perseverar es la más importante de un startup. Hacerla sin criterios claros lleva a pivotar demasiado pronto o a perseverar demasiado tiempo. La evidencia debe guiar la decisión, no el ego.
Qué se ve como un buen resultado
El equipo tiene un proceso documentado para evaluar la evidencia y tomar la decisión de pivotar o perseverar, con el razonamiento registrado para cada decisión importante.
Errores comunes
- Pivotar en respuesta a una sola conversación negativa.
- Perseverar a pesar de evidencia sistemática que refuta el modelo.
- Tomar la decisión sin involucrar a todo el equipo fundador.
- No documentar el razonamiento para poder aprender de él.
Preguntas que el startup debe responder
- ¿Qué porcentaje de los supuestos críticos han sido refutados?
- ¿La evidencia acumulada apunta hacia la misma dirección?
- ¿Hay una alternativa concreta al modelo actual?
- ¿El equipo está de acuerdo en la decisión?
Artifact requerido
📄 Log pivotar/perseverar
Propósito: Registrar las decisiones importantes de pivotar o perseverar con su razonamiento y evidencia.
Card vinculada: Decisión pivotar o perseverar
Instrucciones de desarrollo
- Convoca una sesión de revisión de evidencia con el equipo completo.
- Revisa el repositorio: ¿qué porcentaje de supuestos críticos están validados, refutados o ambiguos?
- Documenta la decisión: pivotar (y en qué dirección) o perseverar.
- Registra el razonamiento y la evidencia que guiaron la decisión.
Estado esperado: Log con cada decisión importante documentada, con evidencia y razonamiento.
Criterios de revisión del Artifact
- Cada decisión importante tiene una entrada en el log.
- La evidencia que guió la decisión está referenciada.
- El razonamiento está documentado de forma que el equipo puede revisarlo.
- El equipo completo participó en la decisión.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El log tiene las decisiones importantes documentadas con evidencia.
- El razonamiento de cada decisión está registrado.
- El equipo puede aprender de las decisiones anteriores.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ningún log de pivotar/perseverar. |
| En progreso | Las decisiones se toman pero no se documentan. |
| Completo | El log tiene las decisiones principales con razonamiento básico. |
| Revisado | La evidencia que guía cada decisión está referenciada. |
| Cumple estándar | El log es la memoria institucional de las decisiones más importantes del venture. |
| Fuerte/Sobresaliente | Se usa activamente para onboarding de nuevos miembros y comunicación con inversores. |
Cards relacionadas / siguiente paso
- Registro de evidencia
- Lista maestra de supuestos
- Norte del founder
Portada — Experimentation
🧪 Experimentation
Valida supuestos críticos a través de experimentos estructurados y decide pivotar o perseverar.