***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 1. Divide los supuestos en cuatro categorías: cliente, problema, solución, modelo. 2. Lista al menos tres supuestos por categoría. 3. Para cada supuesto, evalúa: ¿es hecho conocido o hipótesis? Si es hecho, retíralo de la lista. 4. 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

***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 1. Extrae del registro maestro todos los supuestos de las categorías "cliente" y "problema/mercado". 2. Para cada supuesto, evalúa: ¿qué evidencia tenemos? ¿es suficiente para declararlo validado? 3. Clasifica el nivel de validación: no validado, validación parcial, validado. 4. 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

***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 1. Dibuja una matriz con impacto (bajo a alto) en el eje Y e incertidumbre (baja a alta) en el eje X. 2. Posiciona cada supuesto del registro en la matriz. 3. Identifica el cuadrante prioritario: alto impacto + alta incertidumbre. 4. 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

***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 1. Toma los supuestos del cuadrante prioritario de la matriz impacto-incertidumbre. 2. Añade un tercer criterio: costo de validación (alto, medio, bajo). 3. Ordena los supuestos: primero los de alto impacto + alta incertidumbre + bajo costo de validación. 4. 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

***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 1. Escribe el supuesto a validar en una frase clara. 2. Define el método: ¿cómo se obtendrá la evidencia? (entrevista, prototipo, landing, piloto) 3. Define los criterios de éxito: ¿qué resultado confirma? ¿qué resultado refuta? 4. 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

***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 1. Para el experimento en curso, escribe: señal de confirmación = \[resultado específico\]. 2. Escribe: señal de refutación = \[resultado específico diferente\]. 3. Escribe: señal ambigua = \[resultado intermedio\] y define el siguiente paso si ocurre. 4. 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

***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 1. Crea una entrada por experimento completado con: supuesto, método, fecha, resultados, conclusión. 2. Clasifica la conclusión: confirmado, refutado, ambiguo. 3. Conecta la conclusión con el impacto en el modelo: ¿qué cambió? 4. 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

***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 1. Convoca una sesión de revisión de evidencia con el equipo completo. 2. Revisa el repositorio: ¿qué porcentaje de supuestos críticos están validados, refutados o ambiguos? 3. Documenta la decisión: pivotar (y en qué dirección) o perseverar. 4. 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