Para qué sirve: Durante el cooldown, validar con usuarios el ciclo que Douglas acaba de terminar. El objetivo es saber si el feature resuelve el problema real, qué fricción tiene, y qué debería entrar en el próximo pitch.

Cuándo usarlo: En las 2 semanas de cooldown, después de que termina el ciclo N.

Regla: las preguntas marcadas ⚠️ requieren observación directa o conversación con usuarios reales — no hay forma de responderlas sin hablar con personas.

Instrucciones

1. Duplicar este template al inicio de cada cooldown
2. Nombrar: validation-ciclo-[N]-[modulo].md
3. Guardar en mindstack/wiki/validations/
4. Compartir findings con Douglas antes de que empiece el ciclo N+1

Identificación

PARTE 1 — Observación de uso ⚠️

Observar al usuario usando el feature sin instrucciones. No intervenir a menos que se queden completamente atascados. Anotar todo lo que hacen, no solo lo que dicen.

1.1 ¿El usuario completó el flujo principal sin ayuda?

Usuario 1: [Sí / No / Con ayuda parcial]
Descripción de dónde necesitó ayuda:

Usuario 2: [Sí / No / Con ayuda parcial]
Descripción:

Usuario 3 (si aplica):

1.2 ¿En qué paso específico se detuvieron o mostraron confusión?

Anotar el momento exacto: qué pantalla, qué botón, qué texto los confundió.

Punto de fricción 1:
Punto de fricción 2:
Punto de fricción 3:

1.3 ¿Qué hicieron que NO esperabas que hicieran?

Comportamiento inesperado — bueno o malo.

Comportamiento inesperado:

PARTE 2 — Preguntas post-uso ⚠️

Hacer estas 4 preguntas después de que el usuario haya intentado usar el feature. No antes — queremos observación natural primero, reflexión después.

P1 — "¿Resolvió esto el problema que tenías?" (respuesta abierta, sin dar opciones)

Usuario 1:
Usuario 2:
Usuario 3:

P2 — "¿Hay algo que esperabas que hiciera y no hizo?"

Usuario 1:
Usuario 2:

P3 — "¿Qué parte usarías con más frecuencia? ¿Cuál crees que nunca usarías?"

Usarían más:
Usarían menos o nunca:

P4 — "Si pudieras cambiar UNA sola cosa, ¿qué sería?"

Usuario 1:
Usuario 2:

PARTE 3 — Validación del pitch original

Comparar lo construido vs lo prometido en el pitch.

3.1 Pegar aquí el "Problema" del pitch original:

[Pegar la sección 1 del pitch correspondiente]

3.2 ¿El feature construido resuelve ese problema exacto?

[ ] Sí, exactamente como se describió
[ ] Parcialmente — qué falta:
[ ] No — qué se construyó distinto:

3.3 ¿Se construyó algo que estaba en los no-gos del pitch?

[ ] No — todo dentro de scope
[ ] Sí — qué se coló:
  ¿Fue correcto incluirlo? [ ] Sí [ ] No

PARTE 4 — Input para el próximo pitch ⚠️

El output más valioso de la validación. Los siguientes pitches deben venir de estas observaciones.

4.1 ¿Qué problema quedó sin resolver y justifica el próximo ciclo?

No es una lista de features. Es la lectura del problema más importante que quedó abierto.

Problema más importante no resuelto:
¿Justifica un pitch para el próximo betting table? [Sí / No]

4.2 ¿Algún no-go del pitch original debería convertirse en el próximo pitch?

No-go que ahora sí vale la pena apostar:
Razón del cambio de opinión:

4.3 ¿Qué parte del feature construido no usaron?

Feature construido pero no usado:
¿Recomendarías eliminarlo en una refactorización? [Sí / No]

PARTE 5 — Síntesis para Douglas

Resumen ejecutivo que Serlyn comparte con Douglas al inicio del ciclo N+1. Máximo 1 página.

## Findings de validación — Ciclo [N]

### Lo que funcionó bien
-
-

### Fricción principal (top 3)
1.
2.
3.

### Comportamientos inesperados
-

### Recomendación para próximo pitch
[1-2 oraciones describiendo el próximo problema a resolver]

### ¿Hay algo que debería arreglar Douglas en el cooldown actual?
[ ] Sí: (bug real, no feature nueva)
[ ] No

Guía de sesiones

Lo que NO preguntar

• ❌ "¿Te gustó?" → la respuesta siempre es sí
• ❌ "¿Cuáles features querrías?" → piden cosas que no usarían
• ❌ "¿Usarías esto en el futuro?" → comportamiento futuro declarado es poco confiable

Template versión 1.0 — Mayo 2026. Basado en Shape Up (Basecamp, 2019) adaptado a MindStack Suite.