--- type: CP asset_id: CP-HIORGS-Producto-Estrategia-v01 version: v01 status: Draft owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-20 fecha_ultima_actualizacion: 2026-05-20 fecha_migracion_bmf: 2026-05-20 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank proposito: CP · Producto Estrategia · IB-EL-EmpowerLabs nota_migracion: Frontmatter BMF agregado en batch masivo 2026-05-20 · Workbench FASE 5C · proposito pendiente revisión manual --- # CP-HIORGS-Producto-Estrategia-v01 **Canonical Piece — Estrategia de Producto del SO-HiORG** **Fuente única de verdad sobre qué es el SO-HiORG como producto, cómo se posiciona en el mercado, qué frontera tiene con SherpaX Personal, cuál es su ciclo de vida, quién es su dueño, cómo se mide y cómo se gobierna.** --- | Campo | Valor | |---|---| | **Asset ID** | CP-HIORGS-Producto-Estrategia-v01 | | **Tipo** | Canonical Piece (Estrategia) | | **Room** | PB-HiOrg — Hyperintelligent Org | | **IntelliBank** | IB-EL-EmpowerLabs | | **SubBank** | PB-EL-Project-Bank / PB-HiOrg-Hyperintelligent Org | | **Owner** | Victor Heredia | | **Sponsor** | Victor Heredia | | **Runners** | Jay (coordinación), Jesús + Gustavo (futuros ejecutores), Anahí + Paloma (soporte) | | **Versión** | v01 | | **Fecha de creación** | 2026-04-25 | | **Última actualización** | 2026-04-25 | | **Estado** | Activo — v01 firme tras D-012/013/014 | | **Documentos padre** | XP-EL-HIORGS-Portfolio-v01 (XPack vivo del room) | | **Documentos hermanos** | CP-HIORGS-Solucion-Arquitectura-v01, CP-HIORGS-Producto-Catalogo-v01, MPB-HIORGS-Replicacion-Playbook-v01, MPB-HIORGS-Lab40-Playbook-v01 | | **Continúa desde** | TP-HIORGS-Productizacion-v01 §3 (cerrado por Síntesis F) + MIN-HIORGS-RoomProductizacion-v01 (D-012/013/014) | | **Tags** | [canonical-piece, estrategia, producto, SO-HiORG, sintesis-F, dos-productos, frontera-SherpaX-Personal, pricing-3-capas, gobernanza] | --- ## 0. Propósito de este documento Esta Canonical Piece existe para resolver una pregunta operativa concreta: > *Cuando alguien pregunta "¿qué es el SO-HiORG como producto?", "¿qué incluye?", "¿qué no incluye?", "¿cómo se cobra?", "¿quién lo opera?", "¿qué pasa con SherpaX Personal?" — ¿qué respondemos, con qué frontera, y sobre qué arquitectura comercial?* Es el documento que cualquier miembro de EmpowerLabs debe poder abrir antes de: - Diseñar una propuesta comercial nueva. - Definir un SKU del catálogo. - Negociar pricing con un prospecto. - Decidir si una conversación entrante pertenece al embudo HIORG o al embudo SherpaX Personal. - Capacitar un Sherpa Guide o un facilitador externo certificado. CP-Solucion-Arquitectura-v01 responde *qué hace* el SO-HiORG (capas problema, pilares, fases, entregables). Este documento responde *qué es como producto* — identidad, frontera, ciclo, gobernanza, economía. Es la pieza que cristaliza las decisiones D-012, D-013 y D-014 cerradas el 2026-04-25 en un activo operable. --- ## 1. Identidad de producto — la Síntesis F ### 1.1 Dos productos, no uno La tensión §3 del TP-Productizacion ("¿un producto o tres?") se resolvió con una respuesta que ninguna de las cuatro opciones originales contemplaba: **dos productos**, no uno ni tres. | Producto | Mercado | Unidad de cliente | Promesa central | |---|---|---|---| | **SO-HiORG** | B2B-equipo | Equipo + proyecto vivo | Instalar el sistema operativo organizacional sobre un equipo real con un proyecto real, en 40 días, sin pausar la operación. | | **SherpaX Personal** | B2O *(business-to-one)* | Persona individual | Acompañar a un profesional en su flujo personal con su propio Sherpa, sin requerir transformación organizacional. | Esta es la **Síntesis F**, ratificada como D-012. Resuelve la tensión central porque reconoce que dentro del ecosistema HIORG vivían dos lógicas distintas: - Una lógica de **transformación organizacional** que opera sobre equipos vivos con proyectos vivos. - Una lógica de **adopción individual** que opera sobre personas y no requiere transformación organizacional para entregar valor. Ambas comparten arquitectura técnica y filosofía, pero tienen economías, canales y ciclos de venta distintos. Mantenerlas como un solo producto las confundía. Separarlas en dos productos limpia el catálogo, los pitches y los criterios de calificación de prospecto. ### 1.2 Posicionamiento del SO-HiORG **Categoría:** Sistema Operativo Organizacional. No es un servicio de consultoría, no es una plataforma SaaS, no es una herramienta de productividad, no es un programa de capacitación. **Promesa:** > *Un sistema operativo instalable que convierte a una organización tradicional en una organización hiperinteligente — sin pausar su operación actual, sobre sus equipos reales, con sus proyectos vivos, en 40 días de instalación y 12 meses de consolidación.* **Diferenciador estructural vs. consultoras tradicionales:** el cliente no abandona ni pausa sus proyectos actuales. El Lab los toma como sustrato. La transformación ocurre *sobre* la operación viva, no *en lugar de* ella. **Diferenciador estructural vs. plataformas SaaS:** el SO-HiORG no es software que se compra y se instala. Es un sistema operativo que se *instala con un equipo humano* (Sherpa Guides + Detonadores) que dejan al equipo del cliente operando con autonomía al final del Lab. **Diferenciador estructural vs. programas de capacitación:** la capacitación es un subproducto, no el producto. Lo que se entrega es un ecosistema corriendo en proyectos reales — el equipo queda capacitado *como consecuencia* de instalarlo, no como objetivo independiente. ### 1.3 Posicionamiento de SherpaX Personal (referencia, no scope) SherpaX Personal **no pertenece al scope HIORG** — vive en su propio Room. Se documenta aquí solo para fijar la frontera. Su ficha completa será un activo del Room SherpaX-Personal-Productizacion (a abrir). **Promesa breve:** *"Tu Sherpa personal, instalado sobre tu flujo real de trabajo, en una semana, sin requerir que tu organización cambie."* **Mercado:** profesionales individuales (consultores, ejecutivos, founders, knowledge workers de alto valor) que quieren operar con un agente personal sin esperar a que su organización se transforme. **Canal:** distinto del canal HIORG. Pricing por persona, ciclo de venta corto, onboarding ligero. ### 1.4 La unidad mínima de transformación — D-013 El SO-HiORG está construido alrededor de una unidad operativa irreductible: > **Equipo + proyecto vivo.** No la persona (eso es SherpaX Personal). No la empresa abstracta (las empresas no se transforman, los equipos sí). No el área funcional (demasiado grande, sin proyecto vivo concreto). Esta unidad determina la economía del producto, el formato del Lab, los SKUs del catálogo y los modelos de replicación. **Todo el catálogo se estructura en torno a "equipos" como SKU base** — no horas, no asientos, no módulos. Esta es la lección de 10+ años de EmpowerLabs original: las transformaciones organizacionales que funcionan ocurren equipo por equipo, sobre proyectos vivos. Las que se intentan a nivel "empresa" sin descender a esa unidad fracasan. --- ## 2. Reglas de frontera — SO-HiORG vs SherpaX Personal Para que la Síntesis F funcione operativamente, hace falta una reja explícita que evite confundir un producto con el otro en el embudo. Estas reglas son normativas — un prospecto que cumple criterio de SO-HiORG no debe ser empujado a SherpaX Personal por presión comercial, y viceversa. ### 2.1 Criterios de calificación SO-HiORG (las 3 condiciones del T-5) Un prospecto califica para SO-HiORG cuando cumple **las tres condiciones acumulativas**: 1. **Equipo identificable con proyecto vivo de horizonte 3–12 meses.** No basta con "queremos transformarnos" — tiene que haber un equipo concreto y un proyecto concreto que sea sustrato del Lab. 2. **Workflows operativos repetibles susceptibles de volverse factorías-IA.** El equipo debe tener procesos reconocibles que se puedan instrumentar — si todo es ad-hoc creativo sin patrón, el ecosistema no tiene dónde aterrizar. 3. **Comprador es CIO / CEO / dueño con autoridad para activar el equipo.** No un gerente medio sin poder de decisión sobre la operación del equipo. Sin esa autoridad, la instalación se atasca en política interna. Si un prospecto cumple las tres → embudo HIORG. Si falta una → conversación correctiva (¿se puede crear la condición?). Si faltan dos o más → no es prospecto SO-HiORG hoy. ### 2.2 Criterios de calificación SherpaX Personal Un prospecto califica para SherpaX Personal cuando: - Es individuo (no organización contratante) o organización pequeña sin estructura de equipo formal. - Quiere instalar un agente personal sobre su propio flujo, sin pretensión de transformación organizacional. - Tolera ciclo de venta corto y onboarding ligero (semana, no Lab). ### 2.3 Casos límite — los Pilotos Accidentales Si un prospecto SO-HiORG dice *"solo queremos SherpaX para mi equipo"*, la respuesta canónica **no** es venderle SherpaX standalone (eso compite por precio con asistentes IA genéricos). La respuesta canónica es: > *"SherpaX vive en el ecosistema. Si quieres SherpaX para un piloto acotado, lo hacemos como **Piloto Accidental** dentro de tu organización — no es venta de SherpaX, es siembra del ecosistema. El piloto es entrada baja al embudo SO-HiORG, no producto independiente."* El Piloto Accidental es un SKU del catálogo SO-HiORG (entrada baja, $X-Y), no del catálogo SherpaX Personal. ### 2.4 La regla del bundle Las **3 capas del SO-HiORG (WORX + Corp-Brain-OS + SherpaX) NO se venden por separado**. Se *miden por separado* (telemetría operativa: "tu Corp-Brain-OS tiene 1.2M XDocs", "tu SherpaX tiene 47 seats activos", "tu WORX está corriendo en 3 áreas"), pero comercialmente son un bundle. Esto resuelve el riesgo de canibalización con competencia modular (Glean, Foundry, ServiceNow) y mantiene la disciplina de la matriz 3×5 del deck. Excepciones permitidas: ninguna en venta directa. Solo el Piloto Accidental como entrada baja — pero el piloto se vende explícitamente como *"siembra del ecosistema completo"*, no como módulo independiente. --- ## 3. Arquitectura del producto (referencia) La arquitectura técnica completa vive en **CP-HIORGS-Solucion-Arquitectura-v01**. Aquí solo se consolida la vista de producto: **Los 3 pilares (capas técnicas del bundle):** - **WORX** — método (cómo opera la organización en su día a día con IA integrada) - **Corp-Brain-OS** — arquitectura cognitiva (sustrato que captura, indexa y sirve el conocimiento corporativo) - **SherpaX** *(componente del bundle, no producto separado)* — interfaz humana (agente personal de cada colaborador del equipo) **La matriz 3×5** (lámina 7 del deck) muestra que ningún pilar resuelve solo las 5 capas del problema — el bundle es estructural, no comercial. --- ## 4. Ciclo de vida del producto El SO-HiORG tiene un ciclo de vida definido por las 3 fases canónicas (D-005), no secuenciales sino superpuestas: ### 4.1 Fase 0 — Detonación (semanas 0-2) **Entrada:** EmpowerScan (puerta baja, 90 min, diagnóstico) o conversación directa con Victor. **Output:** decisión Go/No-Go del Lab + identificación del equipo + mapeo del proyecto vivo. **Entregable:** brief de detonación + propuesta comercial + contrato firmado. ### 4.2 Fase 1 — Lab de 40 días (semanas 1-7, superpuesta con Fase 0) **El núcleo integrador.** El Lab corre en paralelo: - Detonación final + scoping continúa hasta semana 2. - Implementación arranca semana 1 (Corp-Brain-OS instalado, WORX en patrón base, SherpaX seats activados). - Capacitación arranca semana 1 sobre el equipo, sobre el proyecto vivo. - Proyectos del cliente avanzan en paralelo — el Lab los toma como sustrato, no los pausa. **Output al final del Lab:** - Proyectos del cliente avanzados o resueltos (con el ecosistema operando sobre ellos) - Equipo capacitado (entrenado en el flujo nuevo, no en uso de herramientas) - Ecosistema instalado (Corp-Brain-OS + WORX + SherpaX corriendo, no en piloto) **Entregable verificable:** rúbrica de calidad ejecutada por Sherpa Guide certificado (definida en MPB-Lab40-Playbook). ### 4.3 Fase 2 — Acompañamiento M1-M12 (meses 1-12, post-Lab) **Lo que se compra como subscription recurrente.** Operación viva del ecosistema: - Mantenimiento operativo del Corp-Brain-OS. - Evolución del WORX según ritmo del equipo. - Soporte SherpaX (seats, training, evolución). - Cadencias de revisión de salud del ecosistema (mensual al inicio, trimestral al estabilizar). **Output:** ecosistema vivo + telemetría + decisión sobre expansión interna a M13+ o expansión a equipos #2/#3. ### 4.4 Fase 3 — Expansión interna (M6+) **El motor de crecimiento dentro del cliente.** Aquí entra la Red de EmpowerTeamsX (D-014). Modelo A o Modelo B según decisión conjunta: - **Modelo A — EL facilita los equipos #2, #3, #N.** Pricing escalonado: equipo #2 = 50–60% del Lab inicial · equipos #3+ = 30–40% del Lab inicial · todos ajustables por complejidad de los proyectos del nuevo equipo. - **Modelo B — Train-the-Trainers.** Cliente certifica facilitadores internos bajo gate de **certificación EL del ecosistema instalado** (método + arquitectura + gente puestos a punto), no solo certificación de personas. Sin esa certificación EL del ecosistema, el cliente no puede ostentar "ejecución certificada SO-HiORG" y EL no responde por resultados. El playbook completo de replicación vive en **MPB-HIORGS-Replicacion-Playbook-v01**. --- ## 5. Modelo de pricing — las 3 capas El pricing del SO-HiORG opera en **tres capas independientes que se cobran simultáneamente** una vez la venta cierra: ### 5.1 Capa 1 — Implementation Fee (Lab inicial) **Qué cubre:** los 40 días del Lab. Detonación final + instalación + capacitación + arranque de operación sobre proyectos vivos. **Lógica:** fee fijo por equipo. No por hora. El precio refleja **el valor del ecosistema instalado**, no el costo del esfuerzo de instalación. **Referencia:** ver pricing detallado en CP-HIORGS-Producto-Catalogo-v01. **Quién lo cobra:** EmpowerLabs (factura inicial al cierre del contrato + hito al cierre del Lab). ### 5.2 Capa 2 — Subscription recurrente (Acompañamiento M1-M12+) **Qué cubre:** la operación viva del ecosistema durante M1-M12 y opcional renovación M13+. **Lógica:** subscription mensual o anual. Refleja **el valor del ecosistema operando**, no horas de soporte. Incluye Corp-Brain-OS hosting/mantenimiento + WORX evolution + SherpaX seats. **Quién lo cobra:** EmpowerLabs (recurrente). ### 5.3 Capa 3 — Expansión interna (más equipos / seats / capas activas) **Qué cubre:** instalación del ecosistema en equipos #2, #3, #N del mismo cliente. También expansión de SherpaX a más seats de los originales del Lab. También activación de capas en otras divisiones del cliente. **Lógica:** repite el modelo de Capa 1 para cada equipo nuevo, con el descuento Modelo A (equipo #2 = 50–60% / equipos #3+ = 30–40%, ajustable por complejidad). Para Modelo B (Train-the-Trainers), el cobro cambia a fee de certificación + royalty por equipo certificado (a definir en CP-Catálogo). **Land-and-expand:** este es el motor de crecimiento dentro del ecosistema. No requiere abrir nuevos clientes — requiere replicar dentro del cliente actual. Una vez instalado el equipo #1, el costo marginal de venta de equipo #2 es bajísimo (mismo comprador, mismo CIO/CEO, ROI ya demostrado). ### 5.4 Pricing del SherpaX Personal (referencia, no scope) Subscription por persona. Ciclo de venta corto. No comparte modelo de pricing con SO-HiORG. Detalle vive en el Room SherpaX-Personal-Productizacion (pendiente de abrir). --- ## 6. Equipo dueño y gobernanza ### 6.1 Roles del SO-HiORG | Rol | Responsabilidad | Quién hoy | Quién al consolidar el playbook | |---|---|---|---| | Product Owner | Decisiones de producto, identidad, frontera, pricing, roadmap | Victor | Victor (mantiene PO indefinido) | | Sales Lead | Calificación de prospecto, negociación, cierre | Victor | Victor + facilitador certificado externo (mediano plazo) | | Detonador | Conduce Fase 0 — diagnóstico + brief + scoping | Victor + Jay | Jesús o Gustavo certificados | | Sherpa Guide | Conduce el Lab de 40 días — facilitador principal | Victor (cliente cero) | Jesús + Gustavo certificados | | Implementation Lead | Arquitectura técnica del Corp-Brain-OS + WORX | (a definir) | rol nuevo a contratar / desarrollar | | Account Lead M1-M12 | Acompañamiento post-Lab | Victor + Jay | Anahí + Paloma como soporte, lead a definir | ### 6.2 Gobernanza del producto - **Cambios de identidad del producto** (qué es / qué no es / frontera) → decisión de Victor, sin excepción. - **Cambios de catálogo o pricing referencia** → propuesta de Jay → ratificación de Victor → registro en CP-Catálogo + CHANGELOG del XPack. - **Cambios del playbook del Lab** → propuesta de Sherpa Guide ejecutor → revisión Jay → ratificación Victor → registro en MPB-Lab40-Playbook. - **Excepciones comerciales** (descuentos, scope ajustado, casos especiales) → aprobación Victor caso por caso. Si el patrón se repite → propuesta de canonización. ### 6.3 Cadencia operativa del room - **Sesiones de diseño** Victor + Jay → conforme se levanten tensiones nuevas. - **Revisión de XPack vivo** → al cierre de cada bloque de outputs canónicos. - **Auditoría de catálogo** → trimestral, sobre el estado del pipeline + ejecuciones reales del Lab. - **CHANGELOG inmutable** → cada decisión vinculante registrada en el XPack del room. --- ## 7. Métricas — qué se mide a nivel producto El SO-HiORG se mide en tres planos distintos. Las 3 capas del bundle (WORX + Corp-Brain-OS + SherpaX) se miden por separado *operativamente* (telemetría) pero se reportan al cliente como salud del bundle. ### 7.1 Métricas de instalación (Lab de 40 días) - Tiempo a primer entregable del proyecto vivo del cliente. - % de capacitación efectiva del equipo (medido con rúbrica del playbook). - Estado del Corp-Brain-OS al cierre (cantidad de XDocs indexados, conexiones a fuentes vivas). - Estado de SherpaX al cierre (seats activos × tasa de uso real). - Estado del WORX al cierre (procesos del equipo corriendo en patrón). ### 7.2 Métricas de operación (M1-M12) - Salud del Corp-Brain-OS (crecimiento de XDocs, queries/mes, hit rate). - Salud del SherpaX (seats activos / contratados, tareas ejecutadas/mes). - Salud del WORX (procesos en patrón / total identificados, ritmo de cadencias). - Resultado en proyectos del cliente (avance / cierre / nuevos proyectos detonados). - Renovación/Expansión (M12 → M13+, equipos #2/#3+ activados). ### 7.3 Métricas de producto (vista EL interna) - Pipeline cualificado SO-HiORG (prospectos que cumplen las 3 condiciones T-5). - Conversión EmpowerScan → Lab (tasa). - Tiempo promedio Lab → cierre. - Net Revenue Retention por cliente (M12+). - Expansión interna por cliente (equipos #2/#3+ activados / cliente). - Adopción Modelo A vs Modelo B en clientes con ≥ 2 equipos. ### 7.4 Lo que NO se mide a nivel producto SO-HiORG - Métricas de SherpaX Personal (su producto, sus métricas). - Métricas EmpowerScan como producto independiente (vive en track Empowernomics). - Adopción de IA "en general" en el cliente (irrelevante — lo que importa es adopción del ecosistema instalado por EL). --- ## 8. Roadmap del producto (v01 → v02 → v03) **v01 (firme — 2026-04-25):** Síntesis F + D-013 + D-014 cerradas. Catálogo v01 + playbooks v01 en producción esta semana. **v02 (Q3 2026 estimado):** ajustes de pricing tras 1-2 ejecuciones reales del Lab post-EL. Playbook del Lab refinado por Sherpa Guide certificado. Caso CAS-EL-LabPraxis-ArquitecturaProducto producido. Demand Gen reactivado. **v03 (2027 estimado):** versión en la que el producto opera sin Victor — Sherpa Guides certificados externos corren Labs autónomamente. Modelo B (Train-the-Trainers) certificó a 1-2 clientes ancla y operan ecosistema instalado con autonomía. Catálogo internacional (cliente fuera de México como referencia). **Qué destrabaría un v04:** SherpaX Personal validado como producto independiente con economía propia + reactivación de la conversación de Demand Gen ecosistémica con datos reales de tracción. --- ## 9. Riesgos canónicos del producto ### 9.1 Riesgo de canibalización (alto) **Si SherpaX Personal "se pega" en el mercado, ¿no compite con SO-HiORG?** No — su mercado es B2O, no B2B-equipo. Ningún CIO/CEO compra SherpaX Personal en lugar de SO-HiORG. Pero un knowledge worker que adoptó SherpaX Personal puede convertirse en evangelista interno → embudo de entrada baja al SO-HiORG. **La frontera de mercado los hace complementarios, no canibales.** ### 9.2 Riesgo de dependencia de Victor (alto) **Si Victor es el único capaz de cerrar ventas y de conducir Labs, el producto no escala.** Mitigación: MPB-Lab40-Playbook + MPB-Replicacion-Playbook + certificación de Jesús/Gustavo. Métrica de éxito: una venta cerrada y un Lab corrido por alguien que no sea Victor antes de fin de 2026. ### 9.3 Riesgo de dilución de método (medio-alto) **Modelo B (Train-the-Trainers) puede diluir la calidad del SO-HiORG si la certificación es laxa.** Mitigación: certificación EL del **ecosistema instalado** (gente + método + arquitectura), no solo de personas. Auditoría EL post-certificación obligatoria. Renovación de certificación cada 12 meses. ### 9.4 Riesgo de competencia plataforma (medio) **Glean, Foundry, ServiceNow et al. pueden empujar a clientes a comprar capas modulares baratas en lugar del bundle.** Mitigación: deck v02 + matriz 3×5 + paper como activos de venta que argumentan a favor del bundle. Disciplina absoluta de "no se vende por separado". ### 9.5 Riesgo operativo del Lab (medio) **Un Lab fallido de un cliente ancla daña reputación y catálogo.** Mitigación: rúbrica de calidad ejecutable por Sherpa Guide certificado + auditoría EL al cierre del Lab + criterios de detención si la Fase 0 detecta condiciones que no cumplen las 3 del T-5. --- ## 10. Decisiones canonizadas que sostienen este documento | Decisión | Qué fija | Documento de cierre | |---|---|---| | D-001 | HIORG es pilar independiente de Re100X | TP-HIORGS-Productizacion-v01 | | D-002 | Productización es upstream de Demand Gen | TP-HIORGS-Productizacion-v01 | | D-003 | El sistema-producto se llama **SO-HiORG** | CP-HIORGS-Solucion-Arquitectura-v01 | | D-004 | 3 pilares canónicos: WORX + Corp-Brain-OS + SherpaX | CP-HIORGS-Solucion-Arquitectura-v01 | | D-005 | 3 fases NO secuenciales: Detonación + Lab 40d + Acompañamiento M1-M12 | CP-HIORGS-Solucion-Arquitectura-v01 | | D-006 | Lab 40d incluye arranque de proyectos en paralelo (no después) | CP-HIORGS-Solucion-Arquitectura-v01 | | D-007 | 3 entregables simultáneos: proyectos resueltos + equipo capacitado + ecosistema instalado | CP-HIORGS-Solucion-Arquitectura-v01 | | D-008 | Argumento anti-pause es central | CP-HIORGS-Solucion-Arquitectura-v01 | | **D-012** | **Síntesis F: dos productos (SO-HiORG + SherpaX Personal)** | **MIN-HIORGS-RoomProductizacion-v01 + este documento** | | **D-013** | **Unidad mínima de transformación = equipo + proyecto vivo** | **MIN-HIORGS-RoomProductizacion-v01 + este documento** | | **D-014** | **Dos modelos de replicación post-Lab — Red de EmpowerTeamsX** | **MIN-HIORGS-RoomProductizacion-v01 + este documento + MPB-HIORGS-Replicacion-Playbook-v01** | --- ## 11. Qué destrabar al cerrar este documento Una vez ratificado este CP, queda inmediatamente desbloqueado: 1. **CP-HIORGS-Producto-Catalogo-v01.md** — define los SKUs vendibles que cuadran con esta estrategia (Lab inicial + equipos subsiguientes Modelo A + tier Train-the-Trainers Modelo B + EmpowerScan + acompañamiento M1-M12). 2. **MPB-HIORGS-Replicacion-Playbook-v01.md** — define el "cómo" de Modelo A y Modelo B con gate de certificación. 3. **MPB-HIORGS-Lab40-Playbook-v01.md** — define el "cómo" del Lab de 40 días ejecutable por Sherpa Guide certificado (no solo Victor). 4. **PLAN-HIORGS-Productizacion-Sprint-v01.md** — plan de 3-6 semanas para ejecutar la v01 del catálogo + playbooks. 5. **Conversación pricing equipos #3+ ya cerrada** (30–40% del Lab inicial, ajustable por complejidad) — se canoniza directo en CP-Catálogo. 6. **Apertura del Room SherpaX Personal** — fuera del scope HIORG. NEXT@Jay registrado en XPack. --- ## 12. Cierre Este Canonical Piece queda cerrado en v01 al cierre del bloque de tripleta (CP-Estrategia + CP-Catálogo + MPB-Replicación) con VoBo de Victor. Próxima revisión esperada: tras la primera ejecución completa del Lab por un Sherpa Guide certificado que no sea Victor → producir v02 con ajustes derivados del aprendizaje real. --- *CP-HIORGS-Producto-Estrategia-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-Hyperintelligent Org/ · 2026-04-25* *Pieza canónica de Estrategia de Producto del SO-HiORG. Cristaliza Síntesis F (D-012) + D-013 + D-014. Sigue MePB-XX-CanonicalPiece-Schema-v01.*