---
asset_id: PLAN-HIORGS-Productizacion-Sprint-v01
title: Sprint de Productización SO-HiORG — Cierre §9 + Bloques de Diseño T-6 / T-7
type: PLAN
intellibank: IB-EL-EmpowerLabs
project: PB-HiOrg-Hyperintelligent Org
version: v01
status: vivo
owner: Victor Heredia
sponsor: Victor Heredia
created: 2026-04-25
horizon: 6 semanas (2026-04-27 → 2026-06-07)
parents:
  - XP-EL-HIORGS-Portfolio-v01
  - MIN-HIORGS-RoomProductizacion-v01
  - CP-HIORGS-Producto-Estrategia-v01
  - CP-HIORGS-Producto-Catalogo-v01
  - MPB-HIORGS-Replicacion-Playbook-v01
  - PAP-HIORGS-ModeloProducto-Interno-v01
tags: [HIORG, productizacion, sprint, plan, T-6, T-7, IIE, diagnostico-hook]
---

# PLAN — Sprint de Productización SO-HiORG

## §0 · Propósito del sprint

Este plan organiza las 6 semanas que cierran la Fase 1 de Productización del SO-HiORG (cerrar los 4 outputs §9 que quedan vivos en el room) **y** abre la Fase 2 incorporando dos bloques de diseño nuevos surgidos al cierre de la Síntesis F:

- **T-6 · Índice de Inteligencia del Equipo (IIE) + tiers tipo ISO** — sistema de medición de madurez en el uso del ecosistema, ligado a certificación.
- **T-7 · Diagnóstico de Madurez SO-HiORG (Hook masivo)** — punto de entrada bajo costo / alto volumen, leído contra los 5 frentes del PAP-GranReto.

El sprint NO produce el producto en sí (el producto ya está canónicamente definido en la tripleta CP-Estrategia + CP-Catálogo + MPB-Replicación). El sprint produce **los activos operativos que un Sherpa Guide y un equipo EL necesitan para vender, ejecutar, escalar y replicar el SO-HiORG sin Victor en la sala**.

> Regla de cierre del sprint: si al día 42 los 4 outputs §9 están firmados y T-6 + T-7 tienen, mínimo, su scaffolding canónico (no la versión final, sí el esqueleto que se puede testear con un equipo real), el sprint cierra exitosamente.

---

## §1 · Alcance del sprint (qué entra / qué NO entra)

### Entra

1. **MPB-HIORGS-Lab40-Playbook-v01** (output §9 #1) — playbook operativo del Lab de 40 días.
2. **CAS-HIORGS-LabPraxis-v01** (output §9 #2) — caso canónico de un Lab ejecutado, formato LabPraxis.
3. **HND-HIORGS-DemandGen-v01** (output §9 #3) — handoff al room de Demand Gen con el modelo de funnel basado en el catálogo de 12 SKUs.
4. **PLAN-HIORGS-Productizacion-Sprint-v01** (output §9 #4) — este documento.
5. **DSG-HIORGS-IIE-Scoring-v01** (T-6 scaffold) — diseño del Índice IIE + tiers ISO + rúbrica.
6. **DSG-HIORGS-Diagnostico-Hook-v01** (T-7 scaffold) — diseño del cuestionario + interpretación + entregable canónico.

### NO entra

- Producir el SherpaX Personal Room (Task #16) — entra en sprint siguiente.
- Aplicar el IIE o el Diagnóstico a un cliente real — el sprint produce el diseño, no el primer ciclo de aplicación.
- Reescribir la tripleta o el PAP-Interno — son canónicos, sólo se actualizan via CHANGELOG si T-6/T-7 obligan.

---

## §2 · Estructura del sprint (6 semanas, 3 bloques)

```
Semana  1   2   3   4   5   6
        ┌───────┐
        │ Bloque A — Cierre §9 (operativo)
        └───────┘
            ┌───────────┐
            │ Bloque B — Diseño T-6 IIE
            └───────────┘
                ┌───────────┐
                │ Bloque C — Diseño T-7 Diagnóstico-Hook
                └───────────┘
                            ┌──┐
                            │ Cierre + Demo Day
                            └──┘
```

Los bloques se solapan a propósito: el cierre §9 (Bloque A) destraba operativamente a T-6 y T-7 porque éstos dependen de tener el Lab y el catálogo claros. T-6 y T-7 corren con 1 semana de defasaje (B antes que C) porque el IIE define el lenguaje de madurez con el que el Diagnóstico interpreta resultados.

---

## §3 · Bloque A — Cierre §9 (Semanas 1-3)

### A.1 · MPB-HIORGS-Lab40-Playbook-v01

| Campo | Valor |
|---|---|
| Owner | Victor (autor) + Sherpa Lead (revisor) |
| Inicio | Semana 1, día 1 |
| Cierre target | Semana 2, día 5 |
| Duración estimada | 8 días útiles |
| Dependencias | Tripleta CP-Estrategia + CP-Catálogo + MPB-Replicación (cerradas) |
| Bloqueado por | — |

**Estructura mínima:**

1. Día -7 a Día 0: Detonación (intake + dimensionamiento del proyecto vivo + instalación inicial WORX/CB/SX).
2. Días 1-10: Ola 1 — diagnóstico operativo + canonización del Cognitive Stack del equipo.
3. Días 11-25: Ola 2 — ejecución del proyecto vivo + paralelo instalación profunda del ecosistema.
4. Días 26-35: Ola 3 — entrega del proyecto + ritual de internalización + EmpowerScan post-Lab.
5. Días 36-40: Cierre — handoff al fase Acompañamiento M1-M12 + activación del Sherpa Guide del equipo.

**Criterio de cierre:** un Sherpa Guide externo, leyendo el playbook, puede correr un Lab sin llamarle a Victor.

### A.2 · CAS-HIORGS-LabPraxis-v01

| Campo | Valor |
|---|---|
| Owner | Victor + persona EL que ejecutó el último Lab interno |
| Inicio | Semana 2, día 1 |
| Cierre target | Semana 3, día 3 |
| Duración estimada | 7 días útiles |
| Dependencias | A.1 (estructura del playbook), datos de Lab interno EmpowerLabs |
| Bloqueado por | A.1 — el caso ilustra el playbook |

**Estructura mínima (formato LabPraxis canónico):** contexto del equipo · proyecto vivo elegido · qué se instaló · qué se desbloqueó · qué falló y se aprendió · indicadores antes/después · firma del Sherpa Guide.

**Criterio de cierre:** el caso es enseñable. Un consultor en certificación lo lee y entiende qué es un Lab sin haber estado.

### A.3 · HND-HIORGS-DemandGen-v01

| Campo | Valor |
|---|---|
| Owner | Victor + lead Demand Gen |
| Inicio | Semana 2, día 3 |
| Cierre target | Semana 3, día 5 |
| Duración estimada | 6 días útiles |
| Dependencias | CP-Catálogo (12 SKUs canónicos) + (preferentemente) scaffold T-7 |
| Bloqueado por | — (puede correr sin T-7 cerrado, pero se actualiza al final) |

**Estructura mínima:** mapa funnel (cold → warm → hot) cruzado contra Capa 0 (EmpowerScan + Piloto Accidental) → Capa 1 (Lab inicial + replicaciones) → Capa 2 (Acompañamiento) → Capa 3 (Expansión); definición de qué pieza de contenido alimenta cada paso; gate de qualification de los 3 condiciones T-5; definición de cómo el Diagnóstico-Hook (T-7) sustituye o complementa el EmpowerScan en cuanto exista.

**Criterio de cierre:** el room Demand Gen puede empezar a producir contenido y campañas sin volver a abrir la productización.

### A.4 · Este PLAN

Owner: Victor. Cierre: día 1 del sprint (hoy, ya producido). Vive como documento del sprint hasta cierre día 42.

---

## §4 · Bloque B — Diseño T-6 · Índice de Inteligencia del Equipo (Semanas 2-4)

### B.1 · Marco conceptual del IIE

| Campo | Valor |
|---|---|
| Owner | Victor (arquitectura) + Sherpa Lead (rúbrica) |
| Inicio | Semana 2, día 1 |
| Cierre target | Semana 3, día 5 |
| Duración estimada | 10 días útiles |
| Dependencias | Tripleta canónica + PAP-Interno (definición de los 3 entregables simultáneos) |
| Bloqueado por | — |

**Decisiones a tomar:**

1. **Qué mide el IIE.** Propuesta inicial: 5 dimensiones espejo de los 5 frentes del PAP-GranReto invertidos a operadores → (i) parálisis IA superada · (ii) sangrado invisible cerrado · (iii) caos operacional ordenado · (iv) carga TI distribuida · (v) dimensión humana resignificada.
2. **Cómo mide.** Combinación de evidencia observable (rituales corriendo, frecuencia de uso del Cognitive Stack, número de proyectos vivos resueltos) + auto-evaluación del equipo + auditoría EL.
3. **Quién mide.** El Sherpa Guide del equipo lo aplica trimestralmente; la Auditoría EL lo valida anualmente.
4. **Granularidad.** El IIE existe a nivel **equipo**; agregaciones a nivel división y nivel empresa son derivadas, no nativas.

### B.2 · Tiers tipo ISO

| Tier | Nombre canónico propuesto | Significado operativo |
|---|---|---|
| 1 | **Foundation** | El equipo terminó el Lab inicial. Cognitive Stack instalado. Ritmo básico vivo. |
| 2 | **Operating** | El equipo opera el ecosistema autónomamente 6+ meses. Resuelve nuevos proyectos sin reconfigurar la guía. |
| 3 | **Mastery** | El equipo ha replicado el ecosistema a, mínimo, otro equipo de la misma empresa (Modelo A funcionando). |
| 4 | **Excellence** | El equipo está habilitado para Train-the-Trainers (Modelo B) y/o sostiene el rol de Sherpa Guide para nuevas Olas internas. |

**Decisiones pendientes:**

- ¿El tier es del equipo o de la empresa? (Propuesta: del equipo; la empresa hereda el promedio ponderado.)
- ¿Cuál es la cadencia mínima entre tiers? (Propuesta: mínimo 6 meses entre tier N y tier N+1, salvo evidencia auditada.)
- ¿La pérdida de tier es posible? (Propuesta: sí — la auditoría anual puede degradar; este es el corazón del modelo ISO, sin esto el tier es decoración.)

### B.3 · Rúbrica scoring v0

| Campo | Valor |
|---|---|
| Owner | Sherpa Lead |
| Inicio | Semana 3, día 1 |
| Cierre target | Semana 4, día 5 |
| Duración estimada | 9 días útiles |
| Dependencias | B.1 + B.2 |
| Bloqueado por | B.1 (marco), B.2 (tiers) |

**Entregable:** documento `DSG-HIORGS-IIE-Scoring-v01.md` con — por cada una de las 5 dimensiones — la rúbrica de evidencia observable, el formato de auto-evaluación, el peso relativo en el cálculo, y la regla de transición entre tiers.

**Criterio de cierre:** la rúbrica se puede aplicar simulada al equipo interno EL como dogfooding, sin ambigüedad operativa.

---

## §5 · Bloque C — Diseño T-7 · Diagnóstico de Madurez SO-HiORG (Hook masivo) (Semanas 3-5)

### C.1 · Marco del Diagnóstico-Hook

| Campo | Valor |
|---|---|
| Owner | Victor (arquitectura del cuestionario) + Demand Gen Lead (UX + entregable) |
| Inicio | Semana 3, día 1 |
| Cierre target | Semana 4, día 5 |
| Duración estimada | 10 días útiles |
| Dependencias | PAP-GranReto (5 frentes) + B.1 (lenguaje de madurez del IIE) |
| Bloqueado por | B.1 — el Diagnóstico habla el lenguaje del IIE. |

**Decisiones a tomar:**

1. **Diferencia frente al EmpowerScan (SKU 0.1).** Propuesta: el Diagnóstico es **auto-aplicable, gratis o muy bajo costo, online**. El EmpowerScan es **facilitado, presencial o sincrónico, pagado**. El Diagnóstico es la pre-puerta del EmpowerScan.
2. **Lectura contra los 5 frentes del PAP-GranReto.** Por cada frente, el Diagnóstico devuelve un nivel de madurez (no un tier IIE — el IIE requiere haber pasado por Lab; este es para empresas que aún no entran).
3. **Entregable.** Un reporte de 1 página por frente + 1 página de síntesis + 1 CTA explícito según el nivel detectado (típicamente: convertir a EmpowerScan o a Lab inicial).

### C.2 · Cuestionario v0

| Campo | Valor |
|---|---|
| Owner | Victor + Sherpa Lead |
| Inicio | Semana 4, día 1 |
| Cierre target | Semana 5, día 3 |
| Duración estimada | 8 días útiles |
| Dependencias | C.1 |
| Bloqueado por | C.1 |

**Entregable:** documento `DSG-HIORGS-Diagnostico-Hook-v01.md` con: cuestionario completo (estimado 30-50 preguntas, 5 bloques × 6-10 c/u), motor de scoring (manual v0, automatizable v01+), template de reporte, y mapeo `nivel detectado → CTA recomendado` en términos del catálogo de SKUs.

**Criterio de cierre:** el Diagnóstico puede aplicarse a un primer pool externo (3-5 empresas piloto) en sprint siguiente sin requerir Victor en la sala.

### C.3 · Validación cruzada con Demand Gen

| Campo | Valor |
|---|---|
| Owner | Demand Gen Lead |
| Inicio | Semana 5, día 1 |
| Cierre target | Semana 5, día 5 |
| Duración estimada | 5 días útiles |
| Dependencias | A.3 (Handoff DemandGen) + C.2 |
| Bloqueado por | A.3, C.2 |

Esta es la sub-tarea que cierra el lazo: el Diagnóstico-Hook se enchufa en el funnel del room Demand Gen. Si el handoff §9 #3 quedó sin él, aquí se actualiza.

---

## §6 · Bloque D — Cierre + Demo Day (Semana 6)

| Campo | Valor |
|---|---|
| Owner | Victor |
| Inicio | Semana 6, día 1 |
| Cierre target | Semana 6, día 5 |
| Dependencias | A, B, C cerrados |
| Bloqueado por | A, B, C |

Actividades:

1. Revisión integral: los 6 entregables del sprint se revisan con la mirada de "un Sherpa Guide externo y consultor en certificación leyendo todo en frío".
2. Dogfooding del IIE en equipo EL (aplicación simulada).
3. Demo Day interno: presentación a equipo EL del paquete completo (tripleta + PAP-Interno + 4 §9 + 2 diseños T-6/T-7).
4. Actualización del XPack y del CHANGELOG con todos los entregables.
5. Apertura formal del Room SherpaX Personal (Task #16) y/o sprint siguiente.

---

## §7 · Cadencia operativa del sprint

| Ritmo | Frecuencia | Owner | Output |
|---|---|---|---|
| Standup escrito | Diario, 9:30 AM | Cada owner | 3 líneas por bloque: hecho / hoy / bloqueos |
| Revisión semanal | Viernes, 60 min | Victor | Avance vs hitos · re-balanceo · re-prioritization |
| Mid-sprint review | Día 21, 90 min | Victor + Sherpa Lead + Demand Gen Lead | Health check de los 3 bloques |
| Cierre + Demo Day | Día 42, 120 min | Victor | Firma de entregables y apertura siguiente sprint |
| Captura de tensiones | En vivo | Cualquiera | Cualquier nueva tensión va al room productización como T-9, T-10, etc. |

---

## §8 · Hitos del sprint (resumen ejecutivo)

| Día | Hito | Output esperado |
|---|---|---|
| 1 | Kickoff | PLAN firmado, owners asignados, todos arrancan A.1 / B.1 |
| 7 | Fin Semana 1 | A.1 al 60% · B.1 arrancado |
| 14 | Fin Semana 2 | A.1 cerrado · A.2 al 60% · A.3 arrancado · B.1 al 80% · C.1 arrancado |
| 21 | **Mid-sprint review** | A.1 ✓ · A.2 ✓ · A.3 al 80% · B.1 ✓ · B.2 ✓ · B.3 arrancado · C.1 ✓ · C.2 arrancado |
| 28 | Fin Semana 4 | A cerrado · B.3 al 80% · C.2 al 80% |
| 35 | Fin Semana 5 | B cerrado · C cerrado · validación cruzada DemandGen ✓ |
| 42 | **Demo Day + cierre** | 6 entregables firmados · XPack actualizado · sprint siguiente abierto |

---

## §9 · Owners y banda de carga estimada

| Persona / Rol | Bloques en los que aparece | Carga estimada |
|---|---|---|
| Victor | A (todos), B.1, C.1, C.2, D | Alta — 50% del sprint |
| Sherpa Lead | A.1, A.2, B.1, B.2, B.3, C.2 | Alta — 60% del sprint |
| Demand Gen Lead | A.3, C.1, C.3 | Media — 30% del sprint |
| Persona EL del Lab interno | A.2 | Acotada — 1 semana |
| Equipo EL completo | D (dogfooding) | Acotada — 2 días |

**Nota Anti-pause:** este sprint NO debe parar la operación normal de EmpowerLabs. Si la carga real excede 60% del tiempo de un owner, se re-balancea en la revisión semanal, no se acumula deuda silenciosa.

---

## §10 · Dependencias críticas (mapa)

```
PAP-Interno ──┐
              │
Tripleta ─────┼──► A.1 Lab40 ──► A.2 LabPraxis
              │           │
              │           └──► A.3 DemandGen ◄── C.3 Validación
              │
              └─────────────► B.1 Marco IIE ──► B.2 Tiers ──► B.3 Rúbrica
                                    │
                                    └────────► C.1 Marco ──► C.2 Cuestionario
```

**Camino crítico:** A.1 → A.2 (cierra Bloque A operativo) ‖ B.1 → B.2 → B.3 (cierra IIE) ‖ B.1 → C.1 → C.2 (cierra Hook). El nodo B.1 es el cuello: si B.1 se atrasa, atrasa todo Bloque B y todo Bloque C. Por eso B.1 arranca en Semana 2 con prioridad.

---

## §11 · Registro de riesgos del sprint

| ID | Riesgo | Impacto | Mitigación |
|---|---|---|---|
| R-1 | Carga real de Victor > 50% por urgencias Rebelocity / IRONMAN | Alto — atrasa A.* y B.1 | Pre-bloquear 4 horas/día calendario; delegar A.2 al lead del Lab interno desde día 1 |
| R-2 | T-6 (IIE) se vuelve ambicioso (más de 5 dimensiones, scoring complejo) | Medio — diseño no cierra en sprint | Regla: v0 del sprint es scaffold, no la versión final; testeable, no perfecto |
| R-3 | T-7 (Diagnóstico) compite con SKU 0.1 EmpowerScan en lugar de complementarlo | Alto — confunde el catálogo | Regla canonizada en C.1: Diagnóstico = auto-aplicable / gratis / online; EmpowerScan = facilitado / pagado |
| R-4 | El handoff DemandGen (A.3) cierra antes que C exista y queda desactualizado | Medio — re-trabajo | C.3 está en plan justo para eso; se actualiza A.3 al cierre |
| R-5 | Aparece nueva tensión T-9+ a mitad de sprint y desestabiliza el plan | Medio | Regla del room: T-9+ se documentan pero NO entran al sprint actual; entran al backlog del sprint siguiente |
| R-6 | El Lab interno EL (insumo de A.2) no tiene datos suficientes | Medio | Si pasa, A.2 escala a "caso compuesto canónico" usando 2-3 mini-casos en lugar de 1 completo |
| R-7 | Sherpa Lead disponible <60% del sprint | Alto — cuello en B y C | Identificar Sherpa Lead nominado al día 1; si no hay, el sprint NO arranca formalmente |

---

## §12 · Criterios de cierre del sprint

El sprint se da por cerrado el día 42 si y sólo si:

1. ✅ MPB-Lab40 está firmado y un Sherpa externo lo entiende sin Victor.
2. ✅ CAS-LabPraxis está firmado y es enseñable.
3. ✅ HND-DemandGen está firmado y el room Demand Gen produce la primera campaña sin reabrir productización.
4. ✅ DSG-IIE-Scoring v0 existe, fue dogfooded en EL y produjo un nivel coherente para el equipo interno.
5. ✅ DSG-Diagnostico-Hook v0 existe y puede aplicarse a 3-5 piloto en sprint siguiente.
6. ✅ XPack actualizado con los 6 entregables.
7. ✅ Minuta del room productización cerrada formalmente o renombrada como histórica si se abre un room nuevo.
8. ✅ Tareas #6, #14, #15, #17 cerradas. Task #16 (SherpaX Personal Room) abierta como sprint siguiente.

Si 5 de 8 cierran, el sprint cierra parcialmente y los pendientes pasan al primer hito del sprint siguiente sin penalty.

---

## §13 · Qué este sprint deliberadamente NO resuelve

- Aplicación del IIE a un cliente externo real → primer Lab del próximo sprint.
- Aplicación del Diagnóstico-Hook a un primer pool de 3-5 empresas → sprint siguiente.
- Producto SherpaX Personal (B2O standalone) → Room dedicado nuevo.
- Modelo financiero detallado (CAC, LTV, payback period) → spawn al room Demand Gen una vez SKU se ejerciten en mercado real.
- Internacionalización del SO-HiORG → fuera de horizonte v01.

---

## §14 · Cierre del PLAN

Este sprint no inventa producto. Lo termina de **operacionalizar**: pasa de "el modelo está claro" a "el modelo se puede ejecutar sin Victor". A la vez, abre las dos ventanas que la Síntesis F dejó abiertas (medición de madurez + hook masivo) para que el sprint siguiente entre con el SO-HiORG ya escalable.

Si al día 42 los 6 entregables existen y el equipo EL puede correr el ciclo completo (detección → Lab → acompañamiento → expansión) leyendo sólo lo que produjimos, el sprint cumplió. El producto está canonizado, operacionalizado y medible. Lo que sigue es venderlo y replicarlo.

---

## §15 · Apuntadores

- Padre estratégico: [[XP-EL-HIORGS-Portfolio-v01]]
- Producto canónico: [[CP-HIORGS-Producto-Estrategia-v01]] · [[CP-HIORGS-Producto-Catalogo-v01]] · [[MPB-HIORGS-Replicacion-Playbook-v01]]
- Manual interno: [[PAP-HIORGS-ModeloProducto-Interno-v01]]
- Bitácora viva: [[MIN-HIORGS-RoomProductizacion-v01]]
- Reto cliente (5 frentes): [[PAP-HIORGS-GranReto-v01]]
- Tareas hijas vivas: #6 · #14 · #15 · #16 · #17

---

*PLAN vivo. Cualquier desvío >2 días en hitos críticos abre revisión inmediata, no espera a la revisión semanal.*