Esta guía explica la metodología que usamos para construir la MindStack Suite. No es una metodología complicada — tiene pocas reglas, pero las reglas que tiene son estrictas. Tomémonos el tiempo de entenderlas bien al inicio para no tener fricción durante el desarrollo.

1. El problema que resuelve Shape Up

Cuando se construye software con un equipo pequeño (como nosotros: Douglas desarrollando, tú definiendo el producto), hay dos errores frecuentes:

Error 1: Construir sin validar Douglas construye features que parecen lógicas, pero cuando las ven usuarios reales resulta que no era lo que necesitaban. Tiempo y energía desperdiciados.

Error 2: Cambiar el scope mientras se construye Serlyn habla con un cliente, encuentra algo nuevo, y quiere agregar eso "al sprint". Douglas pierde foco, el ciclo se alarga, nada termina de verdad.

Shape Up evita los dos errores con una regla simple: las decisiones de qué construir se toman ANTES de construir, y no se cambian mientras se construye.

2. Cómo funciona el ciclo

Cada ciclo de desarrollo tiene 4 momentos:

Momento 1: Shaping (1-2 semanas) — Tu momento

Tú investigas, hablas con usuarios, y escribes un pitch: un documento de 5 secciones que describe el problema real y la solución aproximada.

Este es tu trabajo principal en el ciclo anterior al que se va a construir. Mientras Douglas construye el Ciclo 3, tú ya estás preparando el pitch del Ciclo 4.

Momento 2: Betting Table (1 día) — Los dos juntos

Douglas y tú se reúnen y deciden qué pitches se van a construir en el próximo ciclo.

Si un pitch no está completo → no se construye. No hay excepciones. Si un pitch no se elige → se descarta. No va a ninguna lista de "pendientes".

Momento 3: Building (4-6 semanas) — Momento de Douglas

Douglas construye. Tú no cambias el scope durante este período.

Si mientras Douglas construye encuentras algo nuevo que parece urgente, lo escribes como un pitch y lo presentas en el próximo Betting Table. Pero no interrumpes el ciclo actual.

Momento 4: Cooldown (2 semanas) — Tu validación

Douglas arregla bugs y hace experimentos técnicos.

Tú validas el ciclo que acaba de terminar: organizas sesiones con 2-4 usuarios, observas cómo usan lo construido, y documentas qué funcionó y qué no. Esa información alimenta tu siguiente pitch.

3. El Pitch — tu entregable principal

El pitch es el documento que preparas antes de cada Betting Table. Tiene exactamente 5 secciones:

Sección 1: Problema

El problema desde la perspectiva del usuario — no desde la tecnología.

Cómo saber si es un buen problema: - ¿Puedes citar textualmente a un cliente describiendo el dolor? - ¿Sabes con qué frecuencia ocurre (diario / semanal / mensual)? - ¿Sabes cómo lo están resolviendo hoy (aunque sea con Excel)?

Si no puedes responder estas tres preguntas con información real de usuarios → necesitas más conversaciones antes de escribir el pitch.

Sección 2: Appetite

El appetite no es una estimación de cuánto va a tardar. Es cuánto tiempo vale la pena invertir.

Esto es una decisión estratégica, no técnica. Tú y Douglas la toman juntos.

Siempre se presenta con dos opciones y sus tradeoffs: - "Con 4 semanas, podemos tener [X], pero no [Y]." - "Con 6 semanas, podemos tener [X + Y], pero el ciclo siguiente empieza 2 semanas después."

El cliente nunca sabe que tomó 4 semanas o 6 semanas. Lo que sabe es si el feature resuelve su problema.

Sección 3: Solución (rough sketch)

Una descripción de qué va a poder hacer el usuario. No un wireframe detallado, no una especificación técnica.

Ejemplo correcto: "El dueño del negocio sube un CSV. El sistema detecta automáticamente qué columnas son qué. Le muestra un preview de 5 filas para que confirme. Si hay errores, los marca en rojo fila por fila. Al confirmar, los productos aparecen en su inventario."

Douglas se encarga de cómo implementarlo. Tú describes qué hace el usuario.

Sección 4: No-gos

Tan importante como el scope es saber qué NO entra.

Sin no-gos, el scope se infla durante el building porque alguien siempre dice "¿y no podría también...?".

Mínimo 3. Ejemplos: - "No incluye integración con escáner de código de barras" - "No incluye edición de inventario desde móvil" - "No incluye histórico de cambios de precio"

Sección 5: Betting Rationale

¿Por qué este pitch, por qué ahora?

Si no hay una respuesta clara a "¿qué pasa si no construimos esto en este ciclo?", el pitch probablemente puede esperar.

4. La Validación — tu trabajo en el Cooldown

¿Qué validar?

El objetivo no es preguntarle al usuario si le gustó. El objetivo es observar si el feature resuelve el problema real que se describió en el pitch.

La pregunta más importante: ¿El usuario completó el flujo sin ayuda?

Si necesitó explicaciones para usar algo, hay un problema de UX que hay que documentar. Si lo completó solo, la solución comunica bien.

Cómo estructurar las sesiones

Primero: observación (20-30 min) Le pides al usuario que intente usar el feature. No le das instrucciones. No intervienes a menos que se quede completamente atascado. Anotas todo lo que hace.

Después: 4 preguntas (15-20 min) 1. "¿Resolvió esto el problema que tenías?" (respuesta abierta) 2. "¿Hay algo que esperabas que hiciera y no hizo?" 3. "¿Qué parte usarías más seguido? ¿Cuál crees que nunca usarías?" 4. "Si pudieras cambiar UNA sola cosa, ¿qué sería?"

Cuántas sesiones: 3-4 es suficiente. Después de la cuarta, los patrones se repiten.

¿Qué haces con los findings?

Documentas en el template de validación y se lo compartes a Douglas antes de que empiece el próximo ciclo. Tu resumen tiene dos partes: - Lo que funcionó bien (no cambiar) - Lo que causó fricción (candidato al próximo pitch)

5. Qué NO hacer

Durante el building, no cambiar el scope

Si encuentras algo nuevo urgente durante el ciclo de building → lo escribes como pitch para el próximo Betting Table. No lo agregas al ciclo actual.

La única excepción: si lo que encontraste hace imposible terminar el ciclo como se definió. En ese caso, se escala al Betting Table de emergencia. Pero esto debería ser raro.

No guardar pitches "para después"

Los pitches no apostados en el Betting Table se descartan. No van a ningún backlog.

Si el problema sigue siendo real en el próximo Betting Table, lo presentas de nuevo con más información. Si ya no parece tan importante, era señal de que no era tan urgente.

No hacer preguntas en sesiones de validación que invitan a pedir features

❌ "¿Qué features te gustaría que tuviéramos?" ✅ "¿Resolvió esto el problema que tenías?"

❌ "¿Usarías esto en el futuro?" ✅ "¿Lo usaste esta semana para algo real?"

6. Tu calendario — Año 1

PARALELO: Mientras Douglas construye, tú preparas el siguiente pitch.

Semana 4-9    → Douglas construye MindStack MVP Ciclo 1
Semana 6-9    → TÚ: preparas pitch de MindStack Ciclo 2 (PLG)

Semana 10-11  → Cooldown MindStack 1
                TÚ: validación con 3 usuarios del ciclo terminado
                TÚ: finalizar pitch ciclo 2

Semana 12-15  → Douglas construye MindStack Ciclo 2 (PLG)
Semana 8-13   → Douglas construye StockMind Ciclo 1 (paralelo)
Semana 11-13  → TÚ: preparas pitch de StockMind Ciclo 2

Semana 14-15  → Cooldown StockMind 1
Semana 16-17  → Cooldown MindStack 2
                TÚ: doble validación (ciclos de ambos módulos)

El patrón que te conviene mantener: siempre tener 1 pitch ready antes de que Douglas termine su ciclo actual. Así nunca hay pausa entre ciclos por falta de pitch.

7. Señales de que el sistema está funcionando

✅ Douglas empieza cada ciclo con el pitch listo y no hace preguntas de scope durante el building.

✅ Tú tienes conversaciones con usuarios reales cada 2-3 semanas (no solo al validar ciclos terminados).

✅ Los Betting Tables duran menos de 2 horas porque los pitches están bien preparados.

✅ Cuando termina un ciclo, puedes decir con claridad si resolvió el problema del pitch o no.

Señales de alerta

⚠️ Si Douglas te pregunta durante el building "¿qué quieres que haga exactamente?" → el pitch no estaba suficientemente claro. Reforzar la sección 3 (rough sketch) en los próximos pitches.

⚠️ Si en el Betting Table ningún pitch está listo → Serlyn necesita más conversaciones con usuarios. El shaping toma tiempo real.

⚠️ Si el cooldown se usa para planificar features en vez de validar → el sistema está siendo saltado. Priorizar validación siempre.

8. Plantillas de trabajo

Tienes dos plantillas disponibles como PDF y como archivo editable:

Cómo usarlas: imprimí el PDF como referencia visual, y duplicá el archivo .md para completar cada ciclo. Nombrar el archivo duplicado con el ciclo y módulo: - pitch-[nombre-corto]-ciclo-[N].md → guardar en mindstack/wiki/pitches/ - validation-ciclo-[N]-[modulo].md → guardar en mindstack/wiki/validations/

9. Glosario rápido

Guía preparada por Cheryx Group — Mayo 2026. Basada en Shape Up (Basecamp, 2019) adaptado al contexto MindStack Suite.

Para preguntas sobre la metodología: revisar mindstack/wiki/24-shape-up-metodologia.md o consultar con Douglas.