---
asset_id: TP-HIORGS-Productizacion-v01
tipo: TP (Transfer Pack)
entidad: HIORGS
proyecto: Productizacion
version: v01
fecha_creacion: 2026-04-24
owner: "@Victor"
sponsor: "@Victor"
estado: Draft — arranque de room de diseño
confidencialidad: Interno EmpowerLabs
proposito: Habilitar un room de diseño para productizar formalmente el ecosistema HIORG (Organizaciones Hiperinteligentes) — transformar el conjunto de servicios, metodologías y capas técnicas en un Sistema-Producto con identidad, arquitectura, ciclo de vida, equipo dueño, pricing por valor, playbook reproducible y roadmap. Este TP es precondición del TP de Demand Gen: no se puede generar demanda sostenible de algo que aún no está definido como producto.
read_order:
  1. Este TP (secciones 0-4 — marco, tensión central, inventario)
  2. OUT-HIORGS-BioPappel-RespuestasAlberto-v01.md (la oferta contada cliente-facing)
  3. TP-EL-WORX-PostaScript-v04.md (script destilado + pricing de referencia)
  4. VR-EL-SX-SherpaX-v01.md (visión-roadmap de SherpaX como producto)
  5. project_empowernomics_productization (memoria — naming EmpowerScan / SumaX / SUMATÓN)
  6. GPT-Master-Productizer-Expert-v01.md (framework de productización Victor ya usaba)
  7. TP-HIORGS-DemandGen-Ecosistema-v01.md (track hermano, pausado hasta que este entregue catálogo)
related:
  - TP-HIORGS-DemandGen-Ecosistema-v01.md
  - CP-HIORGS-CRM-Pipeline-v01.md
  - OUT-HIORGS-BioPappel-RespuestasAlberto-v01.md
  - PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01.md
  - OUT-HiORG-CorpBrainOS-ProblemStatement-v01.md
  - VR-EL-SX-SherpaX-v01.md
  - TP-EL-WORX-PostaScript-v04.md
  - GPT-Master-Productizer-Expert-v01.md
  - Memory: project_empowernomics_productization (naming Empowernomics)
  - Memory: feedback_nunca_projects_folder (gate de ruta innegociable)
tags: [transfer-pack, productizacion, HIORG, WORX, SherpaX, CorpBrainOS, Lab40, ecosistema, room-opener, producto-sistema]
changelog:
  - 2026-04-24 — Creación del TP. Detona del mensaje de apertura de Victor que pide abrir room de "Generación de Demanda + Productización de servicios HIORG". Se decidió que productización merece room propio (dependencia upstream de demand gen) y se creó este TP hermano del de DemandGen. Alcance inicial acotado por Victor: tanto "Ecosistema HIORG como producto único" como "las 3 capas como productos independientes" — tensión a resolver en el room, no decisión pre-hecha.
---

# Transfer Pack — Productización Formal del Ecosistema HIORGs

> Este TP abre un room de diseño. No es estrategia ya decidida — es el brief para decidirla con rigor. Su propósito es producir la definición formal del producto (o productos) que vende EmpowerLabs bajo la categoría HIORG: qué es, cómo se empaqueta, cómo se entrega, quién lo opera, cómo se cobra, cómo evoluciona. El output de este room es precondición para que el TP de DemandGen pueda generar demanda sostenible.

---

## ✅ Contexto pre-room (decisiones ya ratificadas)

Antes de abrir el room, estas decisiones ya están cerradas y el documento parte de ellas — no se vuelven a debatir:

**1. Productización formal ≠ empaquetamiento.** No se trata de agrupar lo que ya vendemos en SKUs con precio. Se trata de definir el producto como entidad con identidad, arquitectura interna, ciclo de vida, equipo dueño, métricas de éxito, pricing por valor capturado, playbook de entrega reproducible, y roadmap. Es un esfuerzo de product management, no de marketing.

**2. Productización es upstream de Demand Gen.** `TP-HIORGS-DemandGen-Ecosistema-v01` queda en standby hasta que este room entregue catálogo y arquitectura v01. No se puede generar demanda calificada de algo que aún no está definido como producto — cascada editorial sin producto produce promesas que el equipo no puede sostener.

**3. HIORG es pilar independiente de Re100X.** Ratificado 2026-04-24. Los productos que salgan de este room pertenecen al paraguas HIORG (enterprise, CIO/director como comprador, ticket alto) — no se mezclan con los productos Re100X (reinvención personal, experto/CEO en transición como comprador, membresía/curso).

**4. Alcance inicial incluye dos perspectivas que entran en tensión.** Victor marcó como alcance de arranque tanto "Ecosistema HIORG como producto único" como "Las 3 capas (Corp-Brain-OS / WORX / SherpaX) como productos independientes". No es una contradicción — es la tensión central del room (sección 3). La resolución puede ser un bundle único con decomposición opcional, un catálogo modular con bundle como SKU premium, o una arquitectura de producto-madre + productos-hijos.

---

## 0. Para el Claude / colaborador que lea esto

**Qué es este documento.** Un Transfer Pack que consolida el estado actual del ecosistema HIORG desde la óptica de *producto* (no desde la óptica de *venta* ni de *marketing*). Sirve para arrancar un room de diseño de producto sin reconstruir contexto desde cero.

**Qué NO es.** No es la definición del producto — es el brief para definirlo. No es el catálogo. No es el roadmap. No es el pricing formal. Todos esos son outputs del room.

**Regla #1 — Codenames.** Posta es codename. Nunca usar el nombre real del cliente en ningún material.

**Regla #2 — Productización ≠ Ventas.** El Script Acto 0-9 (`TP-EL-WORX-PostaScript-v04`) es un activo de ventas, no de producto. Se apalanca para entender cómo se cuenta la oferta hoy, pero el room decide la arquitectura de producto con criterios propios (valor entregado, entregables verificables, operabilidad sin Victor), no con criterios de pitch.

**Regla #3 — Pricing en reserva.** Los rangos de Posta (USD 85-95K primer caso / USD 140-160K lista) son referencia interna. En este room se discute *cómo* se cobra (modelo por valor vs. por esfuerzo, fija vs. recurrente, por módulo vs. bundle), no los números específicos por cliente.

**Regla #4 — Separación Empowernomics.** `EmpowerScan` y `SumaX` tienen su propio track de productización (memoria: `project_empowernomics_productization`). No empujar naming Empower hacia HIORG. En este TP, EmpowerScan aparece solo como posible puerta de entrada al funnel HIORG, no como producto HIORG.

**Regla #5 — Gate de ruta innegociable.** Cualquier output del room se escribe en `Reinventaverse/IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/` (o subcarpeta dedicada). No se escribe en `Projects/`, `Companies/`, `CloudVault/` ni `00-Inbox/`. Memoria de referencia: `feedback_nunca_projects_folder`.

---

## 1. Propósito del room

Diseñar la **productización formal del ecosistema HIORG** — qué es el producto (o productos) que vendemos, cómo se arma, cómo se entrega, quién lo opera, cómo se mide, cómo se cobra, cómo evoluciona.

El room debe producir, al cierre, los outputs listados en la sección 9. Si al terminar no existen esos artefactos, el room no cumplió.

**Tiempo objetivo:** 1-2 sesiones de diseño (3-4h totales) para la versión v01 + 4-6 semanas de ejecución para estabilizar la arquitectura de producto y dejarla operable por alguien que no sea Victor.

**Criterio de éxito del room:** al cerrar, cualquier miembro del equipo EL (o un colaborador externo leyendo el output) puede responder sin ambigüedad:
- ¿Qué producto(s) vende HIORG?
- ¿Qué obtiene el cliente, exactamente, cuando compra?
- ¿Cómo se entrega y en cuánto tiempo?
- ¿Quién lo opera (no solo Victor)?
- ¿Cómo se cobra y por qué ese modelo?
- ¿Cómo evoluciona el producto en los próximos 12-24 meses?

---

## 2. El marco — qué es "productizar formalmente"

Productización formal implica definir 8 dimensiones. Cada dimensión es una decisión consciente, no un default heredado del modo proyecto:

**2.1 Identidad del producto.** Nombre, promesa de valor en una línea, enemigo que mata (contra qué problema compite), job-to-be-done del cliente, categoría en la que juega, frase ancla cliente-facing.

**2.2 Arquitectura interna.** Componentes del producto, dependencias entre ellos, qué es *core* (sin esto no hay producto) vs. qué es *extensión* (opcional, agregable, modular). Boundaries claros: dónde empieza y termina el producto.

**2.3 Ciclo de vida del producto en manos del cliente.** Onboarding (cómo arranca) → operación (cómo se usa día a día) → evolución (cómo crece) → retirement (cómo termina o se reemplaza). Cada fase tiene entregables, rituales y métricas propias.

**2.4 Equipo dueño.** Product Owner (decide qué entra al producto y qué no), squad de entrega (quién construye e implementa con el cliente), soporte (quién resuelve tickets y consultas operativas), evangelista (quién lo muestra al mercado). Roles con nombres — no "Victor" como default.

**2.5 Métricas de éxito del producto.** Qué mide que el producto está cumpliendo su promesa (ej. tiempo compactado, decisiones aceleradas, IP capturada, adopción en Sherpas activos, NPS cliente). Distintas de métricas de venta (pipeline, conversión, ticket).

**2.6 Pricing por valor capturado.** El precio refleja el valor que el cliente captura, no el esfuerzo que nos cuesta entregarlo. Hoy Posta fue cotizado por esfuerzo (40 días + horas/mes). Productizar pide reframe: ¿cuánto vale para un cliente de USD 500M-5B recuperar 60% de grasa de coordinación? Ese número ancla el pricing, no las horas.

**2.7 Playbook de entrega reproducible.** Documentación operativa tal que alguien distinto a Victor (Jesús, Gustavo, un Sherpa Guide externo) pueda entregar el producto con calidad estable. Incluye checklists, templates, criterios de aceptación, guiones de sesiones clave, rúbrica de éxito.

**2.8 Roadmap y versionado.** Qué trae v01, qué trae v02, qué deprecamos, qué experimentamos. Gobernanza clara: quién decide qué entra y cuándo. Sin roadmap explícito, el producto se infla con "agregados" ad-hoc a cada cliente y deja de ser producto.

**El gap crítico hoy.** El ecosistema HIORG opera en las 8 dimensiones a nivel *implícito*. Victor las tiene en la cabeza, el equipo las infiere, los clientes las experimentan. Pero no están *explicitadas*, lo que hace imposible (a) escalar sin Victor, (b) preservar consistencia entre clientes, (c) evolucionar el producto con disciplina. Este room cambia eso.

---

## 3. La tensión central del room — ¿un producto o tres?

La pregunta que orienta todo lo demás. Victor marcó que el alcance inicial incluye tanto "Ecosistema HIORG como producto único" como "las 3 capas como productos independientes". Eso no es contradicción — es la disyuntiva a resolver.

**Opción A — Producto único "Ecosistema HIORG" (bundle indivisible).**
Se vende y se entrega como unidad. Las 3 capas (Corp-Brain-OS / WORX / SherpaX) son componentes internos, no productos vendibles por separado. El cliente contrata *el ecosistema*; la composición interna es decisión de EL, no opción del cliente.
- Ventajas: narrativa clara, pricing simple, protege la integridad del ecosistema (las capas están diseñadas para operar juntas).
- Desventajas: ticket alto de entrada (barrera), sin puntos de entrada bajos, difícil de probar antes de comprar.

**Opción B — Catálogo modular con 3 productos independientes.**
Corp-Brain-OS, WORX y SherpaX se venden por separado con pricing propio. El cliente puede comprar solo uno, combinarlos, o contratar el bundle (descuento implícito).
- Ventajas: puntos de entrada más bajos, land-and-expand natural, competencia más directa con Glean/Writer (SherpaX), Foundry (Corp-Brain-OS), ServiceNow (WORX).
- Desventajas: diluye la promesa del ecosistema, cada producto necesita su propio playbook/equipo/métrica, riesgo de "canibalización" (cliente compra solo SherpaX y no escala al ecosistema).

**Opción C — Producto-madre + productos-hijos (híbrido).**
El producto principal es "Ecosistema HIORG" (bundle). Los componentes existen como productos-hijos con identidad propia pero *solo se venden en el contexto del producto-madre* (entrada natural vía Lab, expansión modular post-Lab). Pricing principal es del bundle; componentes tienen pricing de referencia para expansión, no para entrada.
- Ventajas: preserva integridad narrativa (entras al ecosistema, no a un módulo), permite expansión modular post-Lab (cliente ya adoptó Corp-Brain-OS, agrega SherpaX para otro equipo), clarifica gobernanza.
- Desventajas: más complejo de comunicar, requiere disciplina editorial para no diluir el bundle en la narrativa de demand gen.

**Opción D — Lab de 40 días como producto principal, ecosistema como "resultado" del Lab.**
El producto que vendemos no es el ecosistema — es la *instalación* (Lab). Post-Lab, lo que sigue es *operación y acompañamiento*, no "el producto". Esto invierte la lógica: no vendemos software ni metodología, vendemos el evento fundacional que deja instalado el ecosistema.
- Ventajas: producto con entregable fijo y finito, ticket acotado, claro qué compras.
- Desventajas: el negocio recurrente (meses 1-12) queda sin arquitectura de producto, tratado como "secuela".

**El room decide entre estas 4 opciones (o sintetiza una quinta).** Cada opción reescribe las otras 7 dimensiones del marco — es la decisión que gobierna todas las demás.

---

## 4. Inventario del ecosistema hoy — nivel de productización actual

Qué tenemos, qué tan definido está, qué tan operable es sin Victor. Score en cada elemento: ⬛ ausente / 🟥 implícito / 🟧 parcial / 🟩 productizado.

| Componente | Identidad | Arquitectura | Ciclo de vida | Equipo dueño | Métricas | Pricing | Playbook | Roadmap |
|---|---|---|---|---|---|---|---|---|
| **Corp-Brain-OS** | 🟧 | 🟧 | 🟥 | 🟥 | ⬛ | 🟥 | 🟥 | ⬛ |
| **WORX (metodología)** | 🟩 | 🟩 | 🟧 | 🟥 | 🟥 | 🟥 | 🟥 | ⬛ |
| **SherpaX** | 🟩 | 🟧 | 🟥 | 🟥 | ⬛ | 🟥 | ⬛ | 🟥 |
| **Torre de Control** | 🟧 | 🟥 | ⬛ | ⬛ | ⬛ | ⬛ | ⬛ | ⬛ |
| **Book Factory** | 🟧 | 🟧 | 🟥 | 🟥 | ⬛ | ⬛ | 🟥 | ⬛ |
| **Lab de 40 días** | 🟧 | 🟥 | 🟥 | 🟥 | ⬛ | 🟧 | 🟥 | ⬛ |
| **Acompañamiento M1-12** | 🟥 | ⬛ | 🟥 | 🟥 | ⬛ | 🟧 | ⬛ | ⬛ |
| **EmpowerScan (puerta)** | 🟩* | 🟩* | 🟧* | 🟥* | 🟥* | 🟧* | 🟧* | 🟥* |
| **Piloto Accidental** | 🟥 | ⬛ | 🟥 | ⬛ | ⬛ | N/A | 🟥 | ⬛ |

*EmpowerScan está productizado en su propio track (Empowernomics). Aquí aparece como puerta de entrada potencial al embudo HIORG, no como producto HIORG.

**Lectura del inventario:**
- **Identidad** es la dimensión más madura — WORX y SherpaX tienen nombres, narrativa, frases ancla validadas en campo. Torre de Control y Piloto Accidental son los más débiles (emergentes, sin nombre defendido).
- **Pricing, playbook y roadmap** son las 3 dimensiones sistemáticamente ausentes o implícitas. Son el corazón del trabajo del room.
- **Equipo dueño** está en rojo en todo — hoy Victor es Product Owner de facto de todo el ecosistema. Este es el cuello de botella estructural.
- **Métricas** son el otro vacío sistémico. No tenemos cómo probarle al cliente (ni a nosotros mismos) que el producto está cumpliendo. Los 2 Pilotos Accidentales produjeron frases ("estoy enamorado", "oro molido") — no números.

---

## 5. Lo que YA tenemos (activos aprovechables)

Material producido que alimenta directamente la productización — no hay que inventarlo, hay que consolidarlo:

**Narrativa cliente-facing validada.**
- Frases ancla probadas en campo (Posta, BioPappel): *"No vengo a vender una herramienta, vengo a instalar un ecosistema"*, *"El 60% del costo organizacional es coordinación — y es eliminable"*, *"Casi nadie en el mundo está capturando el IP de comportamiento. Nosotros sí."*
- Categoría defendida: **Organizaciones Hiperinteligentes** (en español, resuena con CEOs).
- Tesis narrativa ancla: *"Las empresas que no reinventen su modo de operar se van a convertir en empresas tontas — problema de sobrevivencia, no de productividad."*
- OUT de Bio Pappel contiene la explicación canónica de las 3 capas + Torre de Control + 4 ritmos + Book Factory en tono cliente-facing.
→ `OUT-HIORGS-BioPappel-RespuestasAlberto-v01.md`

**Arquitectura conceptual del ecosistema.**
- 3 capas canónicas: Corp-Brain-OS (memoria) / WORX (método) / SherpaX (interfaz).
- 4 ritmos: Colaborador / Runner / Owner / Sistema.
- Torre de Control con 4 capas: Inventario / Operación / Gobernanza / Aprendizaje.
- Unidad atómica de trabajo: XDoc.
- Diferenciador vs. plataformas tradicionales ("piden datos estructurados / nosotros capturamos lenguaje natural").

**Pricing de referencia (Posta 2026).**
- Setup + Lab 40-60 días: USD 85-95K primer caso / USD 140-160K lista.
- Acompañamiento M1-3: USD 4.5-5K/mes.
- Consolidación M4-6: USD 3.5K/mes.
- Operación M7-12: USD 2.8K/mes.
- Año 1 total: USD 130-135K. Año 2: USD 55-80K.
- Comparables: Big 4 USD 400K-1.2M; Slalom/BCG X USD 250-600K; Glean/Writer/Hebbia USD 150-350K año 1.
→ `TP-EL-WORX-PostaScript-v04.md`

**Activos de entrega ya usados en campo.**
- Brain OS Map HTML interactivo (`MAP-XX-VH-BrainOS-Mapa-v01.html`) — usado en demos Posta y Bio Pappel.
- ROI Tracker v04 (`CP-EL-SX-ROI-Tracker-v04.xlsx`) — modelo financiero cliente-facing.
- Deck v02 Posta (`OUT-EL-WORX-Posta-Deck-v02.pptx`) — deck base reutilizable.
- Script Acto 0-9 (`TP-EL-WORX-PostaScript-v04`) — pitch destilado.
- Q&A comparativo 14 dimensiones vs. Microsoft/Google/OpenAI.

**Patrón del Piloto Accidental.**
Ya hay 2 casos observados (Posta-Juan 2026-04-22, BioPappel-equipo 2026-04-23) donde la demo en vivo convierte emocionalmente al prospecto y detona solicitud de material. Al formalizar, se vuelve parte del producto: *"no vendemos demos, sembramos pilotos accidentales"*.

**Visión de producto SherpaX.**
→ `VR-EL-SX-SherpaX-v01.md` tiene visión y roadmap preliminar de SherpaX como producto. Insumo directo si elegimos Opción B o C (SherpaX con identidad propia).

**Plan de implementación HIORG en casa (EmpowerLabs como cliente cero).**
→ `PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01.md`. Es el caso más profundo de entrega del ecosistema — sirve como referencia de playbook para otros clientes.

**Problem statement de Corp-Brain-OS.**
→ `OUT-HiORG-CorpBrainOS-ProblemStatement-v01.md`. Base para la identidad de producto de Corp-Brain-OS si elegimos Opción B o C.

**Framework de productización ya disponible.**
→ `GPT-Master-Productizer-Expert-v01.md`. Prompt/método que Victor usaba para productizar — 3 fases (validar idea / conceptualizar / definir específicos). Se puede invocar durante el room para acelerar partes específicas.

---

## 6. Lo que AÚN no tenemos (gaps por resolver)

Gap honesto — sin resolver estos, no hay productización:

**(1) Definición formal del producto como entidad.** Hoy el ecosistema se describe desde 3 lenguajes distintos (técnico: capas; metodológico: WORX; cliente: Lab + acompañamiento). No hay *una* definición canónica que diga "esto es el producto, así se compra, así se recibe, así se usa". La ambigüedad es manejable con Victor en la sala — letal a escala.

**(2) Pricing por valor, no por esfuerzo.** El pricing de Posta es por horas/duración (40 días + meses). Eso no escala: el cliente compara con tarifa consultora, nos ancla al precio-hora, y nos impide capturar el valor real (un 60% de grasa sobre USD 500M = USD 300M recuperables). Necesitamos modelo: valor capturado → % → precio.

**(3) Playbook de entrega sin Victor.** El Lab de 40 días hoy requiere a Victor en la sala. Para escalar, necesitamos (a) descomposición del Lab en fases con entregables verificables, (b) rúbrica de calidad por fase, (c) guiones de sesiones clave (kickoff, cierre, demos internas), (d) criterios de escalamiento (cuándo el equipo asignado llama a Victor), (e) certificación del ejecutor.

**(4) Equipo dueño del producto.** Hoy Victor es Product Owner, Jay es squad de entrega, el resto del equipo es soporte ad-hoc. Para productizar formalmente: definir roles (PO, Squad Lead, Implementation Lead, Support Lead, Evangelista), asignar personas, declarar rituales de gobernanza (standup semanal, review mensual, roadmap trimestral).

**(5) Métricas del producto (no de venta).** Hoy medimos pipeline (3 prospectos) y conversión emocional (frases de los clientes). Falta: ¿cuánto tiempo se compacta realmente con el ecosistema instalado? ¿Cuántas decisiones/semana se aceleran? ¿Cuánto IP se captura? Necesitamos 3-5 métricas que todos los clientes traqueen igual.

**(6) Catálogo con arquitectura explícita.** Documento con: productos vendibles, sus componentes, dependencias, pricing de referencia, entregables por línea. Hoy no existe — cada venta reinventa la propuesta.

**(7) Roadmap 12-24 meses.** ¿Qué trae HIORG v02? ¿Integraciones nativas (Microsoft Graph, Google Workspace, Slack)? ¿Módulos verticales (legal, manufactura)? ¿Capa de observabilidad (Torre de Control v02)? Sin roadmap, cada cliente negocia su propia versión.

**(8) Onboarding del ejecutor (no del cliente).** Para que alguien que no sea Victor pueda entregar: curso interno, certificación, sombra de Victor, primera entrega supervisada, handoff. Hoy es cero.

**(9) SLA y modelo de soporte.** Post-Lab, ¿qué garantizamos? ¿Qué tiempo de respuesta? ¿Qué incluye el acompañamiento y qué no? ¿Cómo se escalan las solicitudes adicionales del cliente?

**(10) Gobernanza de IP del comportamiento.** El diferenciador central ("capturamos IP de comportamiento") requiere claridad legal y operativa: ¿quién es dueño del IP capturado — cliente o EL? ¿Cómo se transporta entre proveedores de IA? ¿Cómo se protege? ¿Qué aparece en el contrato?

---

## 7. Hipótesis estratégicas a validar en el room

Traerlas explícitas para que el diseño sea decisión consciente, no default:

**HIP-P1 (forma del producto).** La Opción C del §3 (producto-madre + productos-hijos) es la que mejor balancea integridad narrativa con flexibilidad comercial. El producto principal es "Ecosistema HIORG" (bundle); Corp-Brain-OS / WORX / SherpaX existen como productos-hijos *solo* vendibles en el contexto del bundle (como expansión, no como entrada).

**HIP-P2 (Lab como producto-onboarding, no como producto-principal).** El Lab de 40 días NO es el producto — es el onboarding del producto. Esto invierte la forma de cobrarlo: el Lab se cobra como *implementation fee* (valor del setup), no como proyecto. El producto que se opera post-Lab es el ecosistema en operación.

**HIP-P3 (pricing por % de valor capturado).** El modelo canónico es: "% de coordinación grasa eliminada × costo organizacional anual del cliente = valor capturado. EmpowerLabs cobra X% de ese valor capturado como fee año 1". Esto reemplaza el pricing por horas. Tomando Posta: valor capturado ≈ USD 3-5M/año; fee EL ≈ 3-5% = USD 130-250K. Coherente con rangos actuales pero justificado por valor, no por esfuerzo.

**HIP-P4 (SherpaX es lo único productable como software).** De las 3 capas, SherpaX es la única que cumple criterios de software-as-a-product (instancia por persona, unit economics de suscripción, roadmap de features). Corp-Brain-OS es *plataforma* (infraestructura), WORX es *metodología* (no software). Confundirlas lleva a empaquetar mal.

**HIP-P5 (equipo de producto canónico).** Product Owner = Victor (por ahora). Squad Lead = Jay (Claude Agent + orquestador). Implementation Leads = Jesús, Gustavo (ejecutores certificables). Support = Anahí, Paloma. Evangelista = Victor (hasta que exista segundo voz). El room decide si esta estructura es la que opera, o si hay que contratar roles.

**HIP-P6 (Piloto Accidental se vuelve parte del producto, no del funnel).** Hoy se percibe como tácticas de venta. En realidad, la demo en vivo + OUT post-demo ES una fase del producto (Fase 0: Detonación). Al productizarlo como parte del producto, se cobra (aunque sea mínimamente) o se convierte en pre-requisito para el Lab.

**HIP-P7 (EmpowerScan como puerta de entrada al funnel HIORG, NO como producto HIORG).** EmpowerScan pertenece al track Empowernomics (memoria ratificada). En HIORG aparece solo como puerta de entrada de bajo ticket (diagnóstico 90 min → "aquí está el valor a rescatar" → propuesta Lab). El room confirma o descarta esta conexión.

**HIP-P8 (roadmap priorizado por gaps del Lab, no por features técnicos).** La v02 del producto no sale de "qué feature agregamos a SherpaX" sino de "qué dejó de entregar bien el Lab en los primeros 3 clientes". El roadmap se escribe desde campo, no desde lab.

**HIP-P9 (Torre de Control es propiedad emergente, no componente productizable).** Emerge de combinar Corp-Brain-OS + WORX + SherpaX operando. No se vende por separado, no se cobra por separado. Aparece en la narrativa como *resultado*, no como *producto*.

**HIP-P10 (handoff de ejecución en 6 meses como deadline).** Si al 2026-10-24 Victor sigue siendo el único que puede ejecutar el Lab, la productización falló. Ese es el criterio operativo duro.

---

## 8. Preguntas por resolver en el room

Las decisiones que salen del room. Organizadas por eje:

**Identidad del producto:**
1. ¿El producto se llama "Ecosistema HIORG" en contratos cliente-facing, o tiene otro nombre comercial (ej. "Sistema Operativo Cognitivo", "Plataforma HIORG")?
2. ¿Mantenemos "Lab de 40 días" como nombre del onboarding, o le ponemos nombre que lo ancle al producto (ej. "HIORG Launchpad", "Activación HIORG")?
3. ¿Qué job-to-be-done resuelve específicamente? (no "transformación digital" — algo accionable y verificable).
4. ¿Qué *no* es el producto? (frontera explícita: no es consultoría, no es software, no es entrenamiento).

**Arquitectura del producto (resolver tensión §3):**
5. ¿Opción A (bundle único) / B (catálogo modular) / C (producto-madre + hijos) / D (Lab como producto principal) / E (síntesis)?
6. Si C: ¿cuáles son las reglas de dependencia entre Corp-Brain-OS / WORX / SherpaX? ¿Se pueden vender en cualquier orden o hay secuencia obligatoria?
7. ¿Torre de Control y Book Factory son componentes, propiedades emergentes, o productos-adyacentes?
8. ¿El Piloto Accidental es una fase del producto (Fase 0) o sigue siendo táctica de ventas?

**Ciclo de vida:**
9. ¿Cuáles son las fases canónicas del producto? (propuesta: Detonación → Lab → Consolidación → Operación → Evolución).
10. Entregables verificables por fase — ¿qué firma el cliente al cierre de cada fase?
11. Rúbrica de éxito por fase — ¿cómo sabemos que la fase cerró bien?

**Equipo dueño:**
12. ¿Los roles de la HIP-P5 son los correctos? ¿Faltan? ¿Sobra Victor en alguno?
13. ¿Qué roles son internos EL y cuáles pueden ser externos (Sherpa Guides certificados)?
14. ¿Cuándo contratamos rol dedicado de Product Owner que no sea Victor?

**Pricing:**
15. ¿Pricing por valor capturado (HIP-P3) o por esfuerzo (actual)? ¿O modelo híbrido?
16. ¿Cómo se calcula "valor capturado" de forma defendible ante un CIO? (fórmula, benchmarks, validación).
17. ¿Modelo de cobro: fee único (Lab) + subscription (acompañamiento) / todo-fee / todo-subscription?
18. ¿Descuento por caso de estudio? ¿Cómo se protege que caso de estudio se use efectivamente?

**Playbook:**
19. ¿Qué debe contener el playbook del Lab para que Jesús o Gustavo lo corran con calidad?
20. ¿Qué se mantiene en posesión exclusiva de Victor y qué se transfiere al equipo?
21. Certificación del ejecutor — ¿qué criterios, quién certifica, cuánto tiempo?

**Métricas:**
22. ¿Qué 3-5 métricas define el éxito del producto en manos del cliente?
23. ¿Cómo se instrumentan esas métricas — auto-reportadas, auditadas, medidas por EL?
24. ¿Qué métricas operativas internas monitoreamos para detectar deriva del producto?

**Roadmap:**
25. ¿Qué trae HIORG v02 (horizonte 12 meses)? ¿v03 (24 meses)?
26. ¿Gobernanza de roadmap — quién decide qué entra, en qué ritmo se revisa?
27. ¿Qué se deprecar (si es que algo) — componentes que el ecosistema tenía y ya no sirven?

**Handoff a Demand Gen (y cuándo se reactiva ese track):**
28. ¿Qué mínimo tiene que entregar este room para que DemandGen pueda reactivarse?
29. ¿Cuándo se firma el handoff — ¿en qué artefacto, quién lo valida?

**Ejecución:**
30. ¿Plazo para producir la v01 del catálogo? (propuesta: 3 semanas de sprint).
31. ¿Plazo para primer handoff de Lab a ejecutor no-Victor? (propuesta: 2026-10 como HIP-P10).

---

## 9. Outputs esperados al cierre del room

Si el room es productivo, al terminar existen estos 6 artefactos canónicos (orden sugerido de producción):

**(1) CP-HIORGS-Producto-Estrategia-v01.md** — documento estratégico canónico. Define identidad del producto, arquitectura interna (resolución de la tensión §3), ciclo de vida, equipo dueño, métricas, modelo de pricing, gobernanza. Es el "documento ancla" que todo lo demás referencia.

**(2) CP-HIORGS-Producto-Catalogo-v01.md** — catálogo formal de producto(s). Lista de SKUs vendibles, componentes, dependencias, pricing de referencia, entregables por línea. Documento cliente-facing candidato (con versión interna separada si hay datos sensibles).

**(3) MPB-HIORGS-Lab40-Playbook-v01.md** — playbook del Lab de 40 días. Fases, entregables verificables por fase, rúbrica de calidad, guiones de sesiones clave, checklists, criterios de escalamiento. Diseñado para que Jesús o Gustavo lo corran bajo supervisión de Victor.

**(4) PLAN-HIORGS-Productizacion-Sprint-v01.md** — plan de 3-6 semanas para ejecutar la v01. Qué se construye, quién, con qué cadencia, con qué entregables verificables por semana.

**(5) CAS-EL-LabPraxis-ArquitecturaProducto-v01.md** — caso LabPraxis que captura las decisiones de este room como aprendizaje operativo (por qué optamos por X sobre Y, qué desechamos, qué queda en observación).

**(6) Handoff-Demand-Gen-Reactivacion-v01** — nota breve + update al TP de DemandGen: se cumplen los mínimos (§28-29), DemandGen puede reactivarse con este catálogo como insumo.

**Opcionales deseables si el tiempo alcanza:**
- (7) `MPB-HIORGS-Acompanamiento-M1-12-Playbook-v01.md` — playbook del acompañamiento post-Lab.
- (8) `VR-HIORGS-Roadmap-v01.md` — visión-roadmap consolidada (insumo: VR-EL-SX-SherpaX-v01).
- (9) `TP-HIORGS-Productizacion-Handoff-Ejecutores-v01.md` — brief para entrenar a Jesús / Gustavo / Sherpa Guide externo.

---

## 10. Dependencias con otros TPs y tracks

**Upstream (este TP depende de):**
- `TP-EL-WORX-PostaScript-v04` — tracker canónico de cómo se cuenta la oferta hoy. Insumo para identidad y narrativa.
- `OUT-HIORGS-BioPappel-RespuestasAlberto-v01` — explicación canónica de las 3 capas en tono cliente-facing. Insumo para arquitectura y catálogo.
- `PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01` — caso de entrega más profundo (EL como cliente cero). Insumo para playbook.
- `VR-EL-SX-SherpaX-v01` — visión-roadmap de SherpaX. Insumo para decidir si SherpaX es producto-hijo con identidad propia.
- `OUT-HiORG-CorpBrainOS-ProblemStatement-v01` — base de identidad de Corp-Brain-OS.
- Memoria `project_empowernomics_productization` — naming + separación EmpowerScan / SumaX / SUMATÓN.

**Downstream (este TP alimenta a):**
- `TP-HIORGS-DemandGen-Ecosistema-v01` — **queda en standby** hasta que este room entregue §9.1 y §9.2. Al cierre de este room se agrega nota al TP de DemandGen y cambia su estado a "reactivado".
- Futuros TPs de prospección — cada venta nueva usa el catálogo de §9.2 como punto de partida, no reinventa la propuesta.
- Training interno del equipo EL — playbook §9.3 se vuelve material de onboarding de cualquier nuevo implementador.

**Tracks paralelos (se apalancan pero no se mezclan):**
- Track Empowernomics (EmpowerScan / SumaX / SUMATÓN). Conexión posible: EmpowerScan como puerta de entrada al embudo HIORG. Decisión en §8.7.
- Track Re100X (paraguas personal Victor). No se mezcla narrativamente. Se apalanca solo en canal (LinkedIn de Victor).
- Track WORX MPB (metodología). Es insumo directo del componente WORX del producto HIORG.

---

## 11. Starter prompt para abrir el room

Copiar en un room limpio de Cowork o Claude Code para iniciar la sesión de diseño:

```
Jay — abrimos el room de productización formal del ecosistema HIORG.

Carga este TP como contexto canónico:
TP-HIORGS-Productizacion-v01.md

Lee también, en este orden:
1. OUT-HIORGS-BioPappel-RespuestasAlberto-v01.md
2. TP-EL-WORX-PostaScript-v04.md
3. VR-EL-SX-SherpaX-v01.md
4. PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01.md
5. OUT-HiORG-CorpBrainOS-ProblemStatement-v01.md
6. Memory: project_empowernomics_productization
7. GPT-Master-Productizer-Expert-v01.md (framework auxiliar)

El room produce, al cierre, los 6 artefactos del §9:
- CP-HIORGS-Producto-Estrategia-v01
- CP-HIORGS-Producto-Catalogo-v01
- MPB-HIORGS-Lab40-Playbook-v01
- PLAN-HIORGS-Productizacion-Sprint-v01
- CAS-EL-LabPraxis-ArquitecturaProducto-v01
- Handoff-Demand-Gen-Reactivacion-v01

Orden de trabajo propuesto:
(a) Resolver §3 — la tensión central (1 producto / 3 productos / híbrido / Lab
    como producto principal). Sin resolver esto, todo lo demás flota.
(b) Validar/refutar las 10 hipótesis estratégicas de §7.
(c) Recorrer las 31 preguntas de §8 por eje (identidad → arquitectura →
    ciclo de vida → equipo → pricing → playbook → métricas → roadmap).
(d) Producir los artefactos en el orden de §9.

Reglas del room:
- Productización ≠ empaquetamiento.
- El Script Acto 0-9 es activo de ventas, no arquitectura de producto.
- Posta es codename, pricing en reserva.
- EmpowerScan pertenece al track Empowernomics — aquí solo aparece como
  posible puerta de entrada.
- Gate de ruta: todo output va a IB-EL-EmpowerLabs/PB-EL-Project-Bank/
  PB-HiOrg-Hyperintelligent Org/. Nada en Projects/.

Arranca por la pregunta central — ¿Opción A, B, C, D o E del §3? — y
vamos desplegando.
```

---

## 12. Archivos relacionados (tabla de consulta rápida)

| Asset ID | Uso en este room |
|---|---|
| `TP-HIORGS-DemandGen-Ecosistema-v01.md` | Track hermano — pausado hasta que este TP entregue catálogo |
| `CP-HIORGS-CRM-Pipeline-v01.md` | Estado actual de prospectos — contexto de qué tipo de cliente compra |
| `OUT-HIORGS-BioPappel-RespuestasAlberto-v01.md` | Explicación canónica de las 3 capas en tono cliente-facing |
| `PLAN-EL-HiOrg-ImplementacionEmpowerLabs-v01.md` | Caso de implementación más profundo (EL como cliente cero) |
| `OUT-HiORG-CorpBrainOS-ProblemStatement-v01.md` | Base de identidad de Corp-Brain-OS |
| `VR-EL-SX-SherpaX-v01.md` | Visión-roadmap SherpaX como producto |
| `TP-EL-WORX-PostaScript-v04.md` | Script Acto 0-9 — cómo se cuenta la oferta hoy |
| `GPT-Master-Productizer-Expert-v01.md` | Framework de productización (3 fases) |
| `DK-EL-WORX-NuevoModeloTrabajo-v01.pptx` | Deck conceptual de WORX |
| `DK-EL-WORX-NuevoModeloTrabajo-Dark-v01.pptx` | Deck conceptual de WORX (versión dark) |
| `MAP-XX-VH-BrainOS-Mapa-v01.html` | Mapa visual interactivo (activo de entrega) |
| `CP-EL-SX-ROI-Tracker-v04.xlsx` | Modelo ROI cliente-facing (activo de entrega) |
| Memory: `project_empowernomics_productization` | Naming EmpowerScan / SumaX / SUMATÓN + separación de tracks |
| Memory: `project_doix_corpbrainos` | Piloto 0 del Corp-Brain-OS en EL |
| Memory: `project_worx_mpb` | MPB de WORX (3 niveles, 4 ritmos, XDoc) |
| Memory: `feedback_nunca_projects_folder` | Gate de ruta innegociable |

---

## 13. Bitácora del TP

| Fecha | Autor | Nota |
|---|---|---|
| 2026-04-24 | Jay | Creación inicial. Se detona de la apertura del room donde Victor pidió trabajar "Generación de Demanda + Productización de servicios HIORG". Tras diálogo, se decide que productización merece room propio (dependencia upstream de demand gen). Alcance inicial acotado por Victor: tanto "Ecosistema único" como "3 capas independientes" — tensión explícita a resolver en §3. Path corregido a `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/` tras error inicial de escribir en `Projects/HIOrgs/` — detonó grabación de `feedback_nunca_projects_folder` como regla invariante. |

---

*TP-HIORGS-Productizacion-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/ · 2026-04-24*
*Si al leer este TP descubres que alguna decisión del room ya se tomó, actualiza la sección correspondiente (ej. mover de §8 a §1 "decisiones ratificadas") y registra en §13.*