--- type: PLAN asset_id: PLAN-EL-WORX-Posta-Bloque5-MiniLab-v01 version: v01 status: Draft owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-24 fecha_ultima_actualizacion: 2026-05-24 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank sub-subbank: PB-WORX-Worx proposito: Diseño completo del Bloque 5 "Mini-Lab de Co-construcción" para la presentación Posta T-3. El bloque más nuevo y de mayor riesgo. Convierte la sesión de presentación a workshop participativo donde Posta produce — en vivo, con Jay como copiloto — un artefacto real sobre un caso propio. Es el bloque que dispara el cierre del acuerdo de piloto. documento_padre: PLAN-EL-WORX-Posta-Outline-v01 documento_precedente: PLAN-EL-WORX-Posta-Bloque4-DemoViva-v01 documento_subsecuente: (pendiente) PLAN-EL-WORX-Posta-Bloque6-LaboratorioEntregable-v01 duracion_target: 40 minutos posicion: Post-Bloque 4 (Demo Viva) · Pre-Bloque 6 (Laboratorio entregable) · Pre-Bloque 7 (Acuerdo de Piloto) tags: [posta, presentacion, bloque5, mini-lab, co-construccion, workshop, alto-riesgo] --- # Bloque 5 — Mini-Lab de Co-construcción > **Duración:** 40 minutos > **Posición:** Pivote central de la sesión — después de la demo, antes del cierre comercial > **Objetivo táctico:** Que Posta produzca, en vivo, con Jay como copiloto, un artefacto real sobre un caso propio. **Que dejen de mirar y empiecen a hacer.** > **Objetivo estratégico:** Disparar el *"piloto accidental"* a su forma más concentrada — la sala no recibe una demo, vive una sesión de trabajo del nuevo modelo. Cuando salgan, sabrán qué se siente operar así. --- ## ⚡ Por qué este es el bloque más importante Los Bloques 1-4 son **convicción**. El Bloque 5 es **evidencia visceral**. Una persona puede salir de una buena presentación pensando *"interesante, lo voy a meditar"* — y nunca llamar. Pero alguien que en 40 minutos **produjo algo real con un sistema nuevo**, no olvida la experiencia. Cuando le presenten el acuerdo de piloto en el Bloque 7, ya no estará evaluando una idea — estará confirmando una experiencia que ya tuvo. Esto es **el punto donde el acuerdo se cierra mentalmente** — el Bloque 7 solo lo formaliza. --- ## El estado mental de la audiencia al entrar al bloque Vienen de: - **Bloque 4 (Demo):** Vieron el sistema responder a preguntas reales. La pregunta del momento 4.5 funcionó (o se manejó honestamente). Generamos la minuta en vivo al cierre. - **Energía acumulada:** ~70 min de sentados. Atención dispersa empieza a ser un riesgo. Lo que están pensando: - *"OK, se ve bien. ¿Pero funcionaría para mí?"* - *"¿Esto realmente sirve para mi problema concreto?"* - *"¿Sería capaz yo de usarlo, o necesito a Victor sentado al lado?"* El Bloque 5 responde las tres preguntas de un solo golpe — **trabajándolo en vivo sobre un caso de ellos**. --- ## El cambio de modalidad — apertura crítica El Bloque 5 abre con un **cambio físico de modalidad** que debe ser visible: - Si es presencial: Victor cambia de posición — se acerca a la mesa, no al podio. - Si es remoto: Victor cambia el tono — más conversacional, más invitatorio. - En ambos casos: **Victor cierra los slides anteriores**. La pantalla muestra solamente la interfaz de trabajo (Cowork con Jay activo). Este cambio físico/visual es la señal de que **algo distinto está pasando**. Sin ese cambio, la audiencia sigue en modo "escuchar presentación" cuando deberían estar en modo "co-construir". --- ## Arco narrativo — 6 movimientos en 40 minutos ``` 5.1 → Invitación y cambio de modalidad (3 min) 5.2 → Selección del caso a trabajar (5 min) 5.3 → Diagnóstico inicial con Jay — frame del problema (8 min) 5.4 → Co-construcción del artefacto principal (15 min) 5.5 → El momento de la transformación — múltiples entregables (5 min) 5.6 → Reflexión guiada + puente al Bloque 6 (4 min) ``` Total: 40 min (con buffer de 30 seg). --- ## 5.1 — Invitación y cambio de modalidad (3 min) ### Objetivo Establecer las nuevas reglas de juego. Mover a la audiencia de modo recepción a modo producción. ### Script sugerido > *"Aquí cambia la sesión. Hasta aquí yo les hablé. Los siguientes 40 minutos no son míos — son nuestros.* > > *Vamos a hacer algo que muy raramente se hace en una sesión como esta. Vamos a trabajar juntos, en vivo, sobre un caso real de ustedes. No una hipótesis, no un ejemplo, no un ejercicio. **Un asunto real que tienen abierto en este momento**.* > > *Tres reglas para esto:* > > *Uno — esto NO es una demo más. Yo no voy a ser quien produzca el resultado. Voy a coordinar. Ustedes lo van a producir, con Jay como copiloto.* > > *Dos — lo que generemos en estos 40 minutos es suyo. Se lo llevan, lo usan, lo extienden, lo desechan. No es material de venta. Es producto real de la sesión.* > > *Tres — no hay forma de equivocarse aquí. Lo único que va a pasar es que vamos a ir descubriendo, juntos, cómo se ve un caso operativo de ustedes cuando se trabaja con este modelo. Si en algún momento sienten que vamos por mal camino, lo decimos y ajustamos.* > > *Y antes de elegir el caso, una pieza chica de metodología que va a hacer todo más fluido..."* ### Designación de roles in situ > *"Necesitamos tres roles en este Mini-Lab. Voy a pedir tres voluntarios — pueden cambiar de rol después si quieren, pero arrancamos con tres personas asignadas:* > > ***Owner del caso*** *— quien decide. La persona que dice 'sí esto refleja la realidad' o 'no, esto está mal'. Idealmente, alguien que vive el caso en su día a día.* > > ***Note-taker*** *— alguien que va capturando lo que se va decidiendo. No es escribir minuta — solo señalar 'esto se cerró', 'esto quedó abierto'.* > > ***Devil's advocate*** *— alguien que tiene permiso explícito de cuestionar. Cuando algo suena bonito pero no aterriza, su trabajo es decirlo. Esto NO es ser difícil — es proteger la calidad del output.* > > *¿Quién toma cada rol?"* ### Por qué los roles importan - **Sin Owner:** las decisiones flotan. Todo el mundo "está de acuerdo" pero nadie es dueño. - **Sin Note-taker:** se pierde lo construido. La sesión se diluye al cerrar. - **Sin Devil's advocate:** la cortesía mata la utilidad. Si Victor es el único que cuestiona, queda como vendedor. ### Lectura corporal Si nadie se ofrece para Owner, hay un problema. Significa que el equipo no se siente con autoridad para tomarse en serio el ejercicio. **Manejo:** Victor sugiere a la Directora de TI directamente. Si declina, sugiere a la persona técnica más senior visible. ### Visual sugerido Sin slide. Pantalla limpia (Cowork abierto con Jay). ### Transición a 5.2 *"Bien — gracias [Owner], [Note-taker], [Devil's advocate]. Ahora elijamos el caso..."* --- ## 5.2 — Selección del caso (5 min) ### Objetivo Bajar a tierra. Convertir lo abstracto en un problema específico que el equipo realmente vive. ### Estrategia: Guided Choice NO pedirles "elijan un caso" en frío — eso genera parálisis o casos demasiado vagos. Tampoco imponer uno. **Presentar 3 arquetipos** basados en los patrones del espejo, e invitarlos a elegir o proponer. ### Script sugerido > *"En lugar de pedirles que propongan un caso en frío, les voy a aventar tres tipos de cosas que típicamente vemos en equipos como el de ustedes. Eligen uno — o me dicen 'no, lo que está duro de verdad es esto otro'. Las dos respuestas son buenas.* > > ***Tipo 1 — Un proyecto en limbo:*** *un proyecto que se inició hace meses, en algún momento la dirección estratégica cambió, y hoy nadie sabe muy bien si sigue, se reorienta o se cierra. Sigue consumiendo recursos pero produciendo poco.* > > ***Tipo 2 — Una junta recurrente que cuesta y no produce:*** *una reunión semanal o quincenal que ocupa tiempo de todos, donde se conversa pero no se cierran decisiones, y de la que sale poca documentación útil.* > > ***Tipo 3 — Un proceso documentado que nadie sigue:*** *un SOP, una política, un procedimiento que existe escrito en algún lado pero en la práctica cada quien lo hace a su manera. Conocimiento que vive en personas, no en el sistema.* > > *¿Cuál de estos resuena más con algo que tienen abierto hoy? ¿O hay un cuarto tipo de problema que les preocupa más?"* ### Por qué estos 3 arquetipos Cada uno corresponde directamente a uno de los patrones del Bloque 1: - **Tipo 1** ←→ Patrón 3 (proyectos en limbo) - **Tipo 2** ←→ Patrón 4 (fricción inter-área se baja como demanda a TI) - **Tipo 3** ←→ Patrón 5 (ejecutar sin norte estratégico claro) Esto crea coherencia narrativa: lo que vimos en el espejo, lo trabajamos ahora. ### Manejo si proponen un cuarto tipo Bienvenirlo. Es señal de engagement alto. Solo validar rápidamente: > *"Perfecto. ¿Es algo concreto — un asunto específico, no una categoría general? Por ejemplo, no 'la coordinación con Comercial' sino 'la coordinación específica del lanzamiento de X'."* Si la propuesta sigue siendo muy abstracta, ayudar a aterrizarla: > *"Démosle un nombre concreto. ¿Hay un proyecto específico que está vivo de eso? Trabajemos sobre ese."* ### Manejo si se quedan en blanco Pivot al Tipo 2 (junta recurrente) — es el más universal y el más fácil de aterrizar. ### Decisión rápida — antes de pasar a 5.3 > *"Ok, vamos con [caso elegido]. [Owner], en una frase: ¿cuál es el outcome ideal que sacaríamos de esos 30 minutos? No la solución perfecta — solo el primer paso concreto que valdría la pena dar."* Esta pregunta calibra expectativas y le da al equipo control sobre el alcance. ### Transición a 5.3 *"Bien — caso definido, outcome calibrado. Ahora vamos con Jay a diagnosticarlo..."* --- ## 5.3 — Diagnóstico inicial con Jay (8 min) ### Objetivo Mostrar cómo el sistema **estructura el pensamiento sobre un caso real**. No es resolver — es enmarcar. ### Choreografía #### Paso 1 — Victor dicta el primer prompt (1 min) > *"Jay, estamos en una sesión con el equipo de [contexto neutral]. Tenemos un caso real que queremos diagnosticar:* > > ***[Owner dice en voz alta una descripción de 60 segundos del caso]*** > > *Quiero que primero me hagas las 5 preguntas más importantes que necesitarías para entender el caso a fondo, antes de proponer cualquier acción."* #### Paso 2 — Jay devuelve 5 preguntas estructuradas (1 min) Esto demuestra que el sistema no salta a la solución — interroga primero. Jay debe devolver preguntas del tipo: - ¿Quién es el dueño formal hoy? - ¿Qué decisión estratégica cambió el contexto? - ¿Qué recursos están comprometidos actualmente? - ¿Qué pasaría si simplemente se cerrara hoy? - ¿Quiénes son los stakeholders afectados? #### Paso 3 — La sala responde las preguntas en voz alta (4 min) **Victor cede el espacio.** El Owner responde, otros completan, Victor solo modera. > *"[Owner], la primera pregunta. ¿Quién es el dueño formal hoy?"* Mientras responden, **Victor le va dictando a Jay las respuestas**: > *"Jay, captura: el dueño formal hoy es X. Y el contexto que cambió fue Y..."* Esto es el momento más importante del bloque hasta aquí: **el equipo está produciendo el contenido, el sistema está estructurando**. Victor solo es el conducto. #### Paso 4 — Jay devuelve un diagnóstico estructurado (2 min) > *"Jay, con lo que acabamos de capturar, dame un diagnóstico estructurado: estado actual, dependencias principales, riesgos visibles, y la pregunta más importante que hay que responder antes de cualquier acción."* Jay devuelve algo así: - **Estado:** [síntesis] - **Dependencias críticas:** [lista] - **Riesgos visibles:** [lista] - **Pregunta de cabeza:** [una sola] #### Paso 5 — Reacción de la sala (calibración) > *"¿Esto refleja la realidad? ¿Qué le falta? ¿Qué está mal?"* **Si el Owner ajusta:** perfecto, capturarlo. **Si dice "está bien":** ojo — puede ser cortesía. Devil's advocate, ¿algo que cuestionar? ### Mensaje implícito del segmento *"El sistema no resuelve por ustedes. Estructura cómo ustedes piensan, pregunta lo que ustedes no se preguntaron, y captura lo que ustedes saben. Multiplica su criterio — no lo reemplaza."* ### Transición a 5.4 *"Bien — tenemos diagnóstico. Ahora lo convertimos en un artefacto de trabajo..."* --- ## 5.4 — Co-construcción del artefacto principal (15 min) — el corazón del bloque ### Objetivo Producir, en vivo, un XDoc estructurado del caso. Esto es **lo que se llevan** al final de la sesión. ### Importante — el lenguaje a usar NO decir "XDoc" — decir **"unidad estructurada de trabajo"** o simplemente **"documento operativo del caso"**. La forma sí se muestra, el nombre interno no. ### Choreografía — paso a paso #### Paso 1 — Iniciar el artefacto (1 min) > *"Jay, abre un nuevo documento operativo para este caso. Llámalo [Owner sugiere nombre]. Yo te voy a dictar los componentes en bloques."* #### Paso 2 — Cabecera (2 min) Victor pregunta a la sala, no a Jay: - *"¿Quién es el Owner — la persona que decide?"* → captura - *"¿Quién es el Sponsor — la autoridad que respalda?"* → captura - *"¿Quién va a tener el balón en las próximas 2 semanas?"* → captura (este es el "Runner") - *"¿Qué tipo de asunto es — proyecto, decisión, iniciativa, cuenta?"* → captura Mientras la sala discute, Victor le dicta a Jay para que la cabecera aparezca llenándose en pantalla. #### Paso 3 — Las secciones, una por una (10 min) **Contexto (2 min)** > *"Jay, en la sección de Contexto, captura: el propósito de este asunto es [...], el resultado esperado es [...], los stakeholders involucrados son [...]."* La sala dicta, Victor coordina, Jay estructura. **Estado actual (2 min)** > *"Jay, en Estado: salud actual [verde/amarillo/rojo], hito activo, última decisión registrada que recuerden, y las dependencias críticas."* **Aquí aparece la pieza más impactante:** las dependencias. Victor explica brevemente: > *"Las dependencias son lo que ustedes esperan de otros para avanzar — un INPUT material, una APROBACIÓN, otro DOC, una DECISIÓN. Cuando las nombramos explícitamente, dejan de esconderse y se vuelven visibles."* Listar las dependencias del caso con su tipo y estado. **Protocolo (1.5 min)** > *"¿Hay un SOP escrito que aplique a este caso? Si sí, lo referenciamos. Si en la práctica el equipo opera distinto del SOP, eso también lo declaramos."* Esto introduce el concepto de "drift declarado" sin nombrarlo — convirtiendo la operación real en visible. **Acciones siguientes (2 min)** > *"Jay, en NEXT: capturemos las acciones concretas. Cada una con responsable, fecha y contexto."* La sala propone, Owner asigna, Victor dicta. Mínimo 3, máximo 7 NEXTs. **Conversación pendiente (1.5 min)** > *"Si hay un debate que queda abierto — algo que no es acción pero que vale la pena tener registrado para retomar — lo ponemos aquí."* Esto introduce el concepto de DISCUSSION sin nombrarlo. **Cierre del artefacto principal (1 min)** > *"Y para terminar — todavía no cerramos el caso, solo este primer ciclo de diagnóstico — capturemos qué aprendimos en estos 15 minutos."* Genera la primera entrada de Changelog/Cierre. ### Momentos esperados durante 5.4 **Momento "aha" típico 1 — cuando se enumeran las dependencias** *"Wait, eso son cuatro dependencias activas... no me había dado cuenta de que estaban todas ahí."* **Manejo:** *"Exacto. Cuando se nombran, se vuelven visibles. Antes vivían en cabezas o en correos. Ahora viven en el documento, y todos las ven."* **Momento "aha" típico 2 — cuando Devil's advocate cuestiona un NEXT** *"¿Quién dijo que eso lo iba a hacer X? ¿Está enterado?"* **Manejo:** *"Pregunta perfecta. Por eso aparece en NEXT con nombre y deadline — para que no haya zona gris."* **Momento "aha" típico 3 — cuando la Owner dice "esto no lo tenía tan claro hasta ahora"** **Manejo:** Victor NO comenta. Solo asentir. El silencio que sigue es el momento que vende el piloto. ### Visual / Choreografía de pantalla - Cowork mostrando el documento llenándose en tiempo real - Cada sección que aparece, queda visible - Al final del 5.4, el documento se ve **completo, estructurado, vivo** ### Transición a 5.5 *"Bien. Tenemos un documento operativo completo del caso. Pero esto era solo la pieza base. Ahora les voy a mostrar lo que se puede hacer con esa pieza..."* --- ## 5.5 — El momento de la transformación (5 min) ### Objetivo Demostrar **leverage multiplicativo**. El documento que acaban de construir no es un fin — es la materia prima de muchos otros entregables que normalmente requerirían reuniones separadas. ### Choreografía #### Generación rápida en cascada Victor le pide a Jay, en sucesión rápida: **Prompt 1 — Status para stakeholders (1.5 min)** > *"Jay, con base en el documento operativo que acabamos de construir, genera un status ejecutivo de una página para los stakeholders del caso. Tono claro, sin jerga, con los riesgos visibles."* Jay devuelve el status. Victor lee en voz alta el primer párrafo. La sala lo lee. **Prompt 2 — Email de follow-up (1.5 min)** > *"Ahora dame un email para [persona responsable de la decisión pendiente] explicándole el contexto y pidiendo la decisión específica que necesitamos."* Jay devuelve el email. **El Owner reacciona** ("le mandaría exactamente eso"). **Prompt 3 — Minuta de esta sesión (1 min)** > *"Y por último — genera la minuta de los últimos 30 minutos de trabajo nuestro. Lo que decidimos, lo que dejamos abierto, los siguientes pasos."* Jay devuelve la minuta. **La gente reacciona.** Esta es la pieza que hace tangible el ahorro de tiempo. #### El comentario que ancla todo > *"Lo que acaban de ver les hubiera tomado, en su modelo de trabajo actual, probablemente tres reuniones separadas. Una para diagnosticar, otra para alinear, otra para producir comunicación externa. Y al final habrían tenido que reescribir todo en algún lugar para que no se perdiera.* > > *Aquí lo hicieron en 30 minutos, los tres documentos están listos, el conocimiento queda capturado, y se va a actualizar solo conforme avancen.* > > *Esto NO es magia. Es lo que pasa cuando documentar deja de ser chamba paralela y se vuelve producto de operar."* ### Transición a 5.6 *"Antes de cerrar este segmento, quiero pausar y escucharlos..."* --- ## 5.6 — Reflexión guiada + puente al Bloque 6 (4 min) ### Objetivo Capturar reacciones, dejar que la sala procese, y construir el puente al cierre comercial. ### Las 3 preguntas guiadas Victor pregunta abiertamente — sin orden, sin presión: #### Pregunta 1 — La pregunta abierta > *"¿Qué les pareció? Sin filtros. Lo que vieron, lo que les llamó la atención, lo que les preocupa."* **Escuchar. NO comentar todavía.** Dejar que respondan. Si una respuesta es crítica, no defenderse — agradecer y capturar. #### Pregunta 2 — La pregunta personal > *"[Owner], en particular — ¿cómo fue para ti vivir esto sobre un caso real tuyo?"* Esta pregunta es clave. La respuesta del Owner es **el testimonio interno** que más peso tiene para el resto del equipo. #### Pregunta 3 — La proyección > *"Si pudieran imaginarse operando así no 30 minutos sino 30 días seguidos sobre los proyectos que tienen abiertos hoy — ¿qué cambia?"* Esta pregunta abre la puerta al Bloque 6 / Bloque 7. **No exige respuesta detallada — solo abre el espacio**. ### El cierre del bloque > *"Lo que acaban de vivir es lo que nosotros llamamos un Laboratorio. No es metáfora. Es exactamente esto, repetido en sus proyectos reales, durante semanas, con el equipo entero adentro.* > > *Ahora les voy a contar concretamente cómo se ve eso instalado en su organización..."* ### Visual sugerido Al cerrar el bloque, la pantalla muestra los **tres entregables generados** lado a lado: - El documento operativo (XDoc) - El status ejecutivo - La minuta de la sesión Es la **evidencia física** del trabajo de 40 minutos. Esto se queda visible mientras se transiciona al Bloque 6. ### Transición al Bloque 6 *"Esto es un Laboratorio. Voy a explicarles cómo se instala en su contexto..."* --- ## 🛠️ Pre-flight Checklist específico del Bloque 5 Adicional al checklist del Bloque 4: ### Material físico (si presencial) - [ ] Hojas en blanco + plumones disponibles por si alguien quiere apuntar manualmente - [ ] Mesa accesible para que todos vean la pantalla cómodamente - [ ] Backup whiteboard con la estructura del XDoc dibujada (en caso de falla técnica) ### Setup técnico - [ ] Cowork operativo + Jay respondiendo en <5 seg - [ ] Un XDoc en blanco preparado pero NO pre-llenado - [ ] Ejemplo de XDoc completo accesible por si necesitamos referenciar la forma - [ ] Generador rápido de documentos derivados (status, email, minuta) probado ### Preparación de casos arquetipo - [ ] Tres descripciones cortas (1-2 líneas) listas para presentar los 3 arquetipos en 5.2 - [ ] Para cada arquetipo, conocer las 3-5 preguntas que Jay debería hacer - [ ] Pre-cargar contexto en Jay sobre los 3 arquetipos para que pueda responder rápido ### Ensayo - [ ] Ensayo completo del Bloque 5 con alguien del equipo simulando ser Owner - [ ] Cronometrar — 40 min es estricto, fácilmente se va a 60 sin disciplina - [ ] Practicar transiciones entre 5.3, 5.4 y 5.5 (las pausas son donde se pierde) - [ ] Tener una "señal de tiempo" — Victor mira reloj cada 5 min sin que se note --- ## 🚨 Planes de contingencia específicos ### Si nadie quiere ser Owner (silencio de 15 seg) **Plan A:** Victor sugiere directamente a la Directora de TI: *"[Nombre], ¿te animas? Sé que tienes varios proyectos vivos."* **Plan B:** Si declina, Victor escoge un caso hipotético basado en lo conversado en abril: *"Déjenme aventar uno yo, basado en lo que recordamos de la conversación de abril. Lo trabajamos como si fuera de ustedes y al final me dicen qué tan cerca o lejos quedó de su realidad."* ### Si el caso elegido es demasiado complejo **Síntoma:** después de 5 min en 5.3, todavía no se puede enmarcar el problema. **Manejo:** Victor pivot: *"Este caso es más profundo de lo que entra en 30 minutos. Lo que vamos a hacer es tomar UN componente — el más urgente — y trabajarlo. Quédense con la idea de que el resto se trabajaría igual."* ### Si Jay falla técnicamente en medio del bloque **Plan A:** Switch a generación manual en whiteboard físico, narrando el proceso: *"Vamos a continuar manualmente — Jay está procesando algo. Pero quiero que vean que la estructura misma es lo que produce el valor, no la velocidad."* **Plan B:** Si la falla persiste, declarar y seguir conceptualmente: *"Por hoy nos quedamos con la estructura. Después de la sesión les mando los tres entregables generados completos."* ### Si la sala se cierra ("no veo cómo aplica a nosotros") **Manejo:** NO insistir. Re-frame: *"Esta es una hipótesis. Probablemente no aplica a todo — eso es esperable. Lo que les estoy proponiendo es que prueben sobre uno o dos casos específicos durante el piloto, sin compromiso de extenderlo si no funciona."* ### Si Devil's advocate se vuelve hostil **Manejo:** Agradecer la objeción explícitamente, capturarla, y seguir: *"Excelente punto. [Note-taker], anótalo. Es exactamente el tipo de cuestionamiento que necesitamos para que esto funcione."* NO intentar refutar en vivo. Mover al cierre. ### Si se acaban los 40 min y solo llegamos a 5.4 **Manejo:** Saltar 5.5, hacer 5.6 abreviado (2 min). Comprometernos a mandar los entregables generados después. **NO** tratar de comprimir 5.4 — la calidad del documento producido es lo más importante. --- ## 🎯 Reglas de oro del bloque 1. **NUNCA Victor produce el contenido — solo coordina.** Si Victor empieza a dictarle a Jay sin consultar a la sala, ya perdimos el bloque. 2. **SIEMPRE dejar silencio después de cada pregunta.** Las pausas son productivas. Si Victor llena el silencio, la sala no entra. 3. **NUNCA usar jerga interna sin traducción.** "Owner", "Sponsor", "Runner", "Dependencias", "NEXT" — todos se pueden decir, pero seguidos de su equivalente plain. 4. **SIEMPRE darle al Owner el último voto.** Si el Owner dice "no, así no es", se ajusta. Si el equipo discute, el Owner desempata. 5. **NUNCA pelearse con una objeción.** Si alguien cuestiona el modelo, capturar y seguir. La defensa en vivo da impresión de inseguridad. 6. **SIEMPRE mantener el cronómetro mental.** 40 min son 40 min. Si vamos atrasados, comprimir el segmento, no recortar la conclusión. 7. **NUNCA generar el cuarto entregable.** La tentación de "mira, también puede hacer esto otro" es real. Resistirla. Los 3 entregables (XDoc, status, minuta) son suficientes. Más diluye. 8. **SIEMPRE cerrar con los 3 entregables visibles en pantalla.** La evidencia física es lo que se queda en la memoria emocional de la audiencia. --- ## 🎭 La dinámica facilitatoria — qué hace Victor en cada momento | Momento | Postura de Victor | |---|---| | 5.1 | **Anfitrión** — abre el espacio, calibra reglas | | 5.2 | **Facilitador** — ofrece opciones, no impone | | 5.3 | **Conductor** — dicta a Jay lo que la sala dice | | 5.4 | **Coordinador** — secuencia las secciones, no dicta contenido | | 5.5 | **Operador silencioso** — genera los entregables, deja que la sala reaccione | | 5.6 | **Escucha** — pregunta, no responde | **Si Victor sigue siendo el protagonista en 5.4 y 5.5, el bloque falla** — independientemente de qué tan buena sea su narrativa. --- ## 🤔 Decisiones que requieren confirmación → NEXT[@Victor]: **¿Los 3 arquetipos de caso (limbo / junta / SOP no seguido) son los correctos?** O preferís otros — por ejemplo, un caso de migración tecnológica, un caso de proyecto inter-área, un caso de hiring/onboarding. → NEXT[@Victor]: **¿Hay un caso específico de la sesión de abril que ya sabemos que les preocupa?** Si lo hay, podemos sembrarlo como Tipo 4 sugerido — *"o este otro que recordamos de aquella conversación..."*. Esto demuestra que escuchamos. → NEXT[@Victor]: **¿Cuántos NEXT generamos máximo?** Mi recomendación: 5-7. Más sobrecarga, menos se siente incompleto. → NEXT[@Victor]: **¿Mostramos en pantalla la estructura del XDoc (las 7 secciones) ANTES de empezar a llenarlo, o que vaya apareciendo conforme se llena?** Mi voto: que aparezca conforme se llena — menos intimidante, más orgánico. → NEXT[@Victor]: **¿Practicamos el bloque con Anahí o Alex antes?** *Recomendación fuerte: sí*, con alguien del equipo como Owner simulado y otro como Devil's advocate hostil. → NEXT[@Jay]: Cuando se confirme la modalidad, preparar: - Plantilla de XDoc vacío para abrir en vivo - Pre-cargas de contexto en Jay para los 3 arquetipos - Versión condensada de 25 min del bloque por si se necesita acortar --- ## 📚 Material relacionado - `PLAN-EL-WORX-Posta-Outline-v01.md` — outline maestro - `PLAN-EL-WORX-Posta-Bloque4-DemoViva-v01.md` — bloque precedente (la demo que prepara el lab) - `MPB-EL-WORX-ModeloOperativo-v01.md` — fuente canónica del XDoc (referencia interna, no para sala) - `PP-EL-WORX-UPSORION-CaseStudy-v01.md` — caso UPS que da contexto al Lab como "los 75% en vivo" --- ## 💬 Nota final sobre el peso del bloque El Bloque 5 es **el único bloque donde Victor deja de ser el centro y se vuelve facilitador**. Esto es estructural — no estilístico. Un facilitador exitoso es invisible al cerrar la sesión. La gente recuerda lo que produjeron, no quién los guió. Si al cerrar el Bloque 5 la sala está hablando de "su caso" y los entregables que generaron, el bloque funcionó. Si están hablando de "lo que mostró Victor", el bloque falló — independientemente de qué tan bien se ejecutaron los pasos. **La métrica de éxito real:** que al cerrar, alguien diga *"¿podemos seguir trabajando este caso después de la sesión?"*. Esa pregunta es el cierre del acuerdo de piloto antes de que Victor lo proponga formalmente. --- *PLAN-EL-WORX-Posta-Bloque5-MiniLab-v01 · Jay (SherpaX) · 2026-05-24*