Hay un momento en la semana de todo PM que se siente como una trampa.
El lunes entrevistas a un usuario. El martes llega un bug crítico. El miércoles te piden un reporte ejecutivo. El jueves ingeniería pregunta si ya validaste la historia. El viernes no entregaste nada. ¿Suena conocido?
Pasa porque operas en un solo carril. Discovery y Delivery compiten por tu atención, y como ambos son urgentes, terminas haciendo ambos mal.
El Product Operator ve dos pistas paralelas: una de descubrimiento (validar si tiene sentido) y una de entrega (construir). Cuando dominas la asincronía entre ellas, dejas de hacer malabares y empiezas a orquestar.
Vas a diseñar tu propio Dual-Track, un mapa de evolución de producto —de MVP a PMF, madurez y sunset— y una política de cooling off para no volver a codificar algo que nadie quiere.
Vamos.
2.1. El Problema de Fondo: La Falsa Dicotomía
El PM promedio opera bajo una presión constante: "entrega rápido". Esto lo lleva a un patrón destructivo:
- Recibe un requerimiento.
- Lo convierte en ticket.
- Lo pasa a desarrollo.
- Semanas después ven el resultado.
- El cliente dice "no es lo que pedí".
Eso no es agilidad. Eso es cascada disfrazada de sprints.
El Dual-Track Agile (propuesto por Marty Cagan en Inspired) separa dos flujos de trabajo paralelos:
- Validar hipótesis
- Entrevistar usuarios
- Prototipar
- Testear con clientes
- Construir y entregar
- Codificar
- Probar
- Desplegar
Discovery no es "hacer tickets". Discovery es reducir incertidumbre. Cada semana deberías poder decir: "esto que creíamos que era cierto, ya no lo creemos" o "esto que no sabíamos, ahora lo sabemos".
Delivery no es "escribir código". Delivery es convertir especificación en valor entregado. Si entregas código que nadie usa, no hiciste delivery, hiciste ruido.
2.2. Los 4 Grandes Marcos y Cuándo Usarlos
| Marco | Qué Resuelve | Cuándo Usarlo | Cuándo Evitarlo |
|---|---|---|---|
| Scrum | Coordinación de equipo pequeño en ciclos fijos | Equipo estable, producto en madurez, objetivos claros | Discovery temprano (muchos cambios), equipos grandes |
| Kanban | Flujo continuo, cuellos de botella visibles | Soportes, mantenimiento, equipos con prioridades cambiantes | Proyectos con fecha fija y alcance cerrado |
| Shape Up (Basecamp) | Ciclos de 6 semanas con enfriamiento | Producto en crecimiento, necesitas pausas estratégicas | Entornos regulatorios donde el enfriamiento no es viable |
| SAFe (Scaled Agile) | Coordinación de múltiples equipos grandes | Empresas de 100+ personas, múltiples dependencias | Equipos pequeños, startups (es overkill) |
2.3. El Mapa de Evolución: De MVP a Sunset
Un producto no debería operar igual en todas sus fases. El marco de gestión debe evolucionar con el producto.
Un e-commerce no opera igual en Black Friday que en marzo. En Black Friday (pico) ejecutas, no pruebas nada nuevo. En marzo (Discovery) pruebas landings, flujos de pago, categorías. El error es operar marzo como Black Friday —o peor, al revés.
2.4. La Política de Cooling Off
Shape Up introduce un concepto poderoso: después de cada ciclo de 6 semanas de construcción, viene un período de 2 semanas de "cooling off". Durante esas 2 semanas:
- No se escribe código nuevo.
- El equipo paga deuda técnica.
- El PM hace Discovery profundo para el próximo ciclo.
- Los stakeholders no pueden meter requerimientos nuevos.
El equipo necesita espacio para reflexionar. Los requerimientos "urgentes" de hoy no lo son tras 2 semanas de espera. Y el PM gana tiempo para entrevistar usuarios sin la presión de entregar tickets.
Cómo adaptarlo a tu industria:
- E-commerce: Cooling off después del Black Friday. No lances nada nuevo en enero.
- HealthTech: Cooling off después de una auditoría regulatoria. No toques el código mientras implementas los hallazgos.
- Agencia: Cooling off entre proyectos grandes. No aceptes un pitch nuevo mientras entregas el actual.
3.1. Construir el Mapa de Evolución en Miro
Objetivo: Un lienzo visual que te permita ubicar tu producto actual en su fase de vida y definir el marco de gestión adecuado.
Paso 1 — Crear el tablero en Miro
1. Ve a miro.com y crea un tablero nuevo.
2. Nómbralo: Mapa_Evolucion_[TuProducto].
3. Selecciona la plantilla "Timeline" o comienza en blanco.
Paso 2 — Dibujar las 4 fases Crea 4 columnas horizontales usando rectángulos:
┌─────────────────────────────────────────────────────────────┐
│ FASE 1: MVP │ FASE 2: PMF │ FASE 3: MADUREZ │ FASE 4: SUNSET │
│ 0-6 meses │ 6-18 meses │ 18-36+ meses │ 36+ meses │
│ ┌─────────────────┐ │ ┌──────────────┐ │ ┌──────────────┐ │ ┌────────────┐ │
│ │ Marco sugerido │ │ │ Marco │ │ │ Marco │ │ │ Marco │ │
│ │ Kanban / Shape Up│ │ │ Scrum / │ │ │ Scrum+Kanban │ │ │ Kanban │ │
│ │ Discovery: 80% │ │ │ Shape Up │ │ │ Discovery: │ │ │ Discovery │ │
│ │ │ │ │ Discovery: │ │ │ 30% │ │ │ mínimo │ │
│ └─────────────────┘ │ │ 50% │ │ └──────────────┘ │ └────────────┘ │
└─────────────────────────────────────────────────────────────┘
Paso 3 — Agregar tu producto actual Usa notas adhesivas (stickies): - Escribe tu producto o proyecto en una nota. - Pégala en la fase donde está hoy. - Si tienes múltiples proyectos, crea una nota por proyecto.
Paso 4 — Agregar señales de fase Cada fase tiene señales de entrada y salida. En Miro, crea una columna de "Señales" adjunta a cada fase:
MVP (señales de entrada): No sabemos si alguien quiere esto. MVP (señales de salida): Al menos 10 usuarios activos semanales o evidencia de pago.
PMF (señales de entrada): Tenemos usuarios que volverían si apagamos el producto. PMF (señales de salida): Retención >40% mes a mes.
Madurez (señales de entrada): El producto genera ingresos estables. Madurez (señales de salida): Ingresos planos o en declive por más de 3 meses.
Sunset (señales de entrada): Costo de mantener > ingreso que genera. Sunset (señales de salida): Cero usuarios en el producto legacy.
Paso 5 — Agregar tu marco actual Al lado de tu nota de producto, agrega una nota con el marco que usas hoy (Scrum, Kanban, Shape Up, etc.). Pregúntate: ¿Este marco corresponde con la fase donde estoy?
3.2. Diseñar tu Política de Cooling Off
En la misma pizarra de Miro, crea una sección aparte llamada Política de Cooling Off.
Paso 1 — Define la duración de tu ciclo - Shape Up usa 6 semanas de construcción + 2 de cooling off. - Para tu industria, ajusta: - E-commerce: 4 semanas construcción + 1 semana cooling (el retail no espera 2 semanas). - HealthTech: 8 semanas construcción + 3 semanas cooling (el ciclo regulatorio es más lento). - Agencia: 3 semanas construcción + 1 semana cooling (proyectos cortos).
Paso 2 — Define las reglas del cooling off Usa notas adhesivas para escribir:
DURANTE EL COOLING OFF:
- ❌ No se escribe código nuevo
- ✅ El equipo paga deuda técnica
- ✅ El PM hace entrevistas de Discovery
- ❌ El cliente no puede pedir cambios
- ✅ Se prueban bugs pendientes
- ✅ Se actualiza documentación
Paso 3 — Define el acuerdo con stakeholders Agrega una nota que diga:
"ACUERDO: Durante las semanas de cooling off, no aceptaremos
requerimientos nuevos. Si algo es realmente urgente, el sponsor
debe aprobarlo por escrito. El cooling off no es tiempo muerto.
Es tiempo de preparación para el próximo ciclo."
3.3. Simulación de Cambio de Fase
Escenario: Tu e-commerce acaba de lanzar una nueva categoría de producto. Tiene 5 compradores semanales. Tu jefe exige sprints de 2 semanas con entregas puntuales.
Ejercicio: 1. Ubica esta categoría en tu mapa de evolución. (Respuesta: MVP — 5 compradores no es PMF.) 2. ¿El marco solicitado (Scrum con entregas cada 2 semanas) es el adecuado? (No: en MVP necesitas flexibilidad para pivotar, no compromisos de entrega.) 3. Diseña un plan de 6 semanas para esta categoría usando el ciclo Shape Up: - Semana 1-4: Experimentos de Discovery + desarrollo ligero. - Semana 5-6: Cooling off, análisis de resultados, decisión de continuar o pivotar.
4. Cómo Usar Esto para Mejorar tus Procesos Reales
4.1. Diagnóstico de 5 Minutos: ¿Estás en el Marco Correcto?
- Responde estas preguntas para tu proyecto actual:
- ¿Cuánto tiempo llevas en este producto? Menos de 6 meses → MVP (Scrum con entregas fijas te cobra coordinación cuando deberías explorar). Entre 6 y 18 → buscando PMF: balancea Discovery y Delivery. Más de 18 → Madurez: operar como startup desperdicia recursos.
- ¿Qué porcentaje de tu semana gastas en Discovery? <20% → construyes cosas que nadie pidió. 20-40% → balance saludable. >60% → exploras pero no entregas: ¿tiene sentido?
- ¿Cuándo fue la última semana sin presión de entrega? Nunca → necesitas cooling off: tu productividad es ilusoria. Hace menos de un mes → vas bien. No recuerdas → agenda uno la próxima semana.
4.2. Cómo Implementar el Dual-Track en tu Equipo
No intentes implementar todo de golpe. El Dual-Track es un cambio cultural, no un proceso nuevo: un paso por semana durante cuatro semanas.
Semana 1 — Separa el backlog en dos carriles. Crea dos columnas en tu herramienta actual (Jira, Trello, Asana):
Discovery: historias en validación (sin estimar, sin asignar a desarrollo).Delivery: historias listas para construir (validadas, estimadas, con DoD).
Nada pasa a Delivery sin antes pasar por Discovery.
Semana 2 — Bloquea tiempo de Discovery: El PM debe bloquear 2 medias jornadas a la semana exclusivamente para Discovery. Sin reuniones. Sin Jira. Solo entrevistas, prototipos, pruebas con usuarios.
Semana 3 — Introduce el cooling off: Después de un ciclo de entrega, toma 1 semana sin nuevo desarrollo. Úsala para: - Depurar el backlog (cierra tickets que no se validaron). - Entrevistar 3 usuarios. - Planear el próximo ciclo.
Semana 4 — Evalúa y ajusta: Mide: ¿El equipo entregó más o menos? ¿La moral mejoró? ¿Los stakeholders entendieron el cooling off? Ajusta la duración de los ciclos según el feedback.
4.3. Entregable del Módulo
Pestaña 1 — Mapa de Evolución:
- Las 4 fases con sus señales de entrada y salida.
- Tu producto/proyecto actual ubicado en la fase correcta.
- El marco de gestión actual.
- Una nota que responda: "¿El marco que uso hoy corresponde con la fase donde estoy?"
Pestaña 2 — Política de Cooling Off:
- Duración de tu ciclo de construcción + cooling off.
- Reglas escritas (qué se hace y qué no durante el cooling off).
- Acuerdo escrito con stakeholders (aunque sea simulado).
Pestaña 3 — Simulación de Cambio de Fase:
- Toma un producto o proyecto que conozcas.
- Simula que pasa a la siguiente fase (ej. de MVP a PMF).
- ¿Qué cambia en el marco? ¿En la métrica? ¿En el rol del PM? Escríbelo en notas adhesivas.
Formato de entrega: link a tu tablero con permisos de comentario. No necesitas datos reales de tu empresa; puedes simular un proyecto hipotético (el kit trae miro-mapa-evolucion.md y politica-cooling-off-template.md).
- Error: aplicar procesos de fase Madurez a un producto en MVP. Corrección: ajusta el proceso a la fase: en MVP la velocidad de aprendizaje vale más que la previsibilidad.
- Error: saltarse el Cooling-Off después de una feature fallida. Corrección: sin el periodo de enfriamiento documentado, el mismo error vuelve con otro nombre en el siguiente quarter.
- Error: mantener un producto en Sunset por apego ("ya invertimos mucho"). Corrección: eso es falacia de costo hundido: aplica los criterios de salida que definiste antes de empezar.
- Error: tratar discovery y delivery como fases secuenciales. Corrección: son carriles paralelos sincronizados: mientras un track entrega, el otro aprende.
- Error: declarar PMF con opiniones del equipo. Corrección: el PMF se mide con retención y recomendación de usuarios reales, no con entusiasmo interno.
| Criterio | No Aprobado (0) | Aprobado (1) | Sobresaliente (2) |
|---|---|---|---|
| 1. Ubicaste correctamente tu producto en su fase de vida | El producto no está ubicado en ninguna fase o la fase no corresponde con las señales descritas | El producto está en una fase pero no hay señales claras que justifiquen por qué está ahí y no en otra | El producto está en la fase correcta, justificado con señales específicas, y hay una nota sobre si el marco actual es adecuado o no |
| 2. Diseñaste una política de cooling off aplicable | No hay política de cooling off o es genérica sin duración ni reglas | Hay política con duración y reglas pero no incluye el acuerdo con stakeholders | Hay política con duración, reglas claras, acuerdo con stakeholders, y una nota sobre por qué esa duración funciona para tu industria |
| 3. Identificaste un ajuste concreto a tu proceso actual | No hay diagnóstico ni plan de ajuste | Identificaste si tu marco actual corresponde a tu fase pero no propones un cambio específico | Identificaste la desconexión entre tu marco actual y tu fase de producto, y escribiste el cambio concreto (marco, métrica, o política) que implementarás esta semana |
Aprobación: 2 de 3 criterios en "Aprobado" o superior.
Para avanzar al Módulo 3: Tu política de cooling off debe tener una duración específica y al menos 3 reglas claras. Si no puedes explicarle a tu jefe en 30 segundos por qué el cooling off no es "tiempo muerto" sino "tiempo de preparación", vuelve a ajustarla.
- Discovery y Delivery son dos pistas paralelas que se sincronizan, no una línea recta.
- Cada marco (Scrum, Kanban, Shape Up, SAFe) resuelve un problema distinto: elige por contexto, no por moda.
- El marco de gestión debe evolucionar con la fase del producto (MVP → PMF → Madurez → Sunset).
- El cooling off protege el tiempo de Discovery y frena la falsa urgencia de los stakeholders.
Kit: Ciclo Dual-Track
| Archivo | Descripción |
|---|---|
| ⬇ miro-mapa-evolucion.md | Layout ASCII + link al board público de Miro: mapa MVP → PMF → Madurez → Sunset |
| ⬇ politica-cooling-off-template.md | Documento Markdown con estructura de política de cooling off |