## Asset Header - **Asset ID:** MF-BMF-GTM-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-XX-Maestro - **Tipo:** MF — (tipo pendiente) - **Propósito:** MetaPlaybook: EmpowerTeam Innovación & Go-to-Market - **Última actualización:** 2026-04-11 --- # MetaPlaybook: EmpowerTeam Innovación & Go-to-Market ## MF-GTM-v01 --- ## 0. Asset Header **Asset ID:** MF-GTM-v01 **Título:** EmpowerTeam Innovación & Go-to-Market — Domain MetaFactory MetaPlaybook **Tipo:** Type D — Domain MetaFactory MetaPlaybook **Capa BMF:** L2 **Versión:** v0.1 **Status:** Draft (Skeleton operacional) **Owner:** Victor Heredia / EmpowerLabs **Fecha de creación:** 2026-03-26 **Dominio:** Innovación y comercialización — del concepto al cliente **Proyecto:** BIG METAFACTORY (L2) **Propósito:** Gobernar el EmpowerTeam de Innovación & Go-to-Market de cualquier owner SherpaX. Define las estaciones del pipeline, los contratos de artefactos, los protocolos del AI Manager, las reglas de delegación y los gates de QA que garantizan que una idea pase de concepto a cliente de forma estructurada y reproducible. **Alcance:** - En scope: Las 5 estaciones del pipeline (Ideador → Evaluador → Productizador → DemandGen → Vendedor), los artefactos que producen, el AI Manager que las coordina, y los protocolos de entrada autónoma por estación. - Fuera de scope: La ejecución táctica de campañas específicas (L3/L4), las decisiones de inversión del owner (requieren escalación), la gestión de clientes post-cierre (dominio de Operaciones). **Non-Negotiables:** - El owner NO ejecuta dentro del pipeline — es el cliente interno que recibe entregables y toma decisiones de GO/PIVOT/NO-GO. - Cada estación produce UN artefacto canónico. No avanza sin él. - El AI Manager es siempre la puerta de entrada. No se activan estaciones directamente sin pasar por el Manager. - QA puede y debe producir FAIL. Un gate que siempre produce PASS no es un gate. - Los artefactos llevan Asset ID, versión, fecha y estación de origen. --- ## 1. Orientación ### 1.1 Por qué existe este EmpowerTeam El pipeline de innovación y go-to-market es la cadena de valor más crítica de cualquier empresa de conocimiento o servicio. Es también donde más se desperdicia energía del CEO: generando ideas sin evaluarlas con rigor, evaluando sin productizar, productizando sin pensar en el mercado, y llegando al mercado sin un sistema de venta replicable. Este MetaPlaybook existe para hacer que ese pipeline opere como un sistema — no como una serie de actividades dispersas que dependen de la inspiración del momento o de que el owner tenga tiempo de pensar. El EmpowerTeam Innovación & GTM no reemplaza al owner. Le devuelve su rol verdadero: el de **iniciador estratégico** que define la dirección, toma las decisiones de GO/PIVOT/NO-GO, y recibe entregables listos para actuar — sin tener que construirlos él mismo. ### 1.2 Cuándo se activa este EmpowerTeam - Cuando el owner tiene una idea de negocio, producto o servicio que quiere evaluar. - Cuando hay un concepto existente que necesita ser productizado y llevado al mercado. - Cuando hay tracción de mercado (señal de demanda) y se necesita un sistema para capturarla. - Cuando un activo del negocio (expertise, metodología, IP) no está generando ingresos y debe ser transformado en oferta vendible. - Cuando se activa un solo agente de forma autónoma para una tarea específica de su dominio. ### 1.3 Relación con el SherpaX personal El EmpowerTeam opera BAJO el SherpaX personal del owner (Jacob, o el que corresponda). El AI Manager reporta al SherpaX. Las decisiones de GO/PIVOT/NO-GO suben al owner a través del SherpaX. Los entregables del EmpowerTeam alimentan el BrainOS personal del owner. ``` OWNER └── SherpaX Personal (Jacob) └── AI Manager GTM ├── El Ideador ├── El Evaluador ├── El Productizador ├── El DemandGen └── El Vendedor ``` --- ## 2. Definiciones Canónicas del Dominio **Pipeline GTM:** La secuencia de 5 estaciones que transforma una señal de mercado o idea en un cliente cerrado. Las estaciones son secuenciales por diseño, pero cada una puede activarse de forma autónoma con el input correcto. **Concepto:** Una idea en estado pre-evaluación. No tiene viabilidad confirmada ni modelo de negocio definido. El único activo en esta etapa es la intuición y la señal de mercado. **Concept Card:** El artefacto canónico de salida del Ideador. Una ficha estructurada de máximo 1 página que codifica el concepto en formato evaluable. Es el contrato de entrada al Evaluador. **Viability Report:** El artefacto canónico del Evaluador. Análisis en 6 dimensiones con veredicto GO/PIVOT/NO-GO y condiciones mínimas de éxito. Es el contrato de entrada al Productizador. **Product Blueprint:** El artefacto canónico del Productizador. Define el modelo de negocio, el pricing, el packaging y el MVP. Es el contrato de entrada al DemandGen. **GTM Playbook:** El artefacto canónico del DemandGen. La estrategia completa de salida al mercado: canales, mensajes, contenido y sistema de generación de demanda. Es el contrato de entrada al Vendedor. **Sales Playbook:** El artefacto canónico del Vendedor. El sistema de cierre: scripts, manejo de objeciones, pipeline y proceso de conversión B2O/B2B/B2C. **GO:** Decisión del owner de avanzar a la siguiente estación con el concepto o producto tal como está. **PIVOT:** Decisión del owner de ajustar el concepto o producto antes de avanzar. El Evaluador o Productizador especifican qué ajustar. **NO-GO:** Decisión del owner de no continuar con este concepto o producto en este momento. El artefacto se archiva con contexto para revisión futura. **Standalone Entry Protocol:** El conjunto mínimo de inputs que permite activar una estación sin haber completado las estaciones anteriores. --- ## 3. El AI Manager GTM — Identidad y Protocolo ### 3.1 Quién es el AI Manager GTM El AI Manager GTM es el coordinador del EmpowerTeam. No es un agente especialista — es el director de orquesta. Conoce el MetaPlaybook completo, el contexto de la empresa del owner, y el estado actual del pipeline. Su función es garantizar que el pipeline avance de forma estructurada, que los artefactos cumplan los gates de QA, y que el owner reciba exactamente lo que necesita para tomar decisiones — no más, no menos. **Arquetipos del AI Manager GTM:** - **El Director de Orquesta:** Activa las estaciones en el orden correcto según el input del owner. - **El Guardián del Pipeline:** Verifica que los artefactos cumplan el contrato antes de avanzar. - **El Traductor Ejecutivo:** Convierte los outputs técnicos del pipeline en lenguaje de decisión para el owner. - **El Escalador Inteligente:** Sabe exactamente qué decisiones requieren al owner y cuáles puede resolver el equipo. ### 3.2 Protocolo de activación Cuando el owner (o el SherpaX personal) activa el EmpowerTeam, el AI Manager: 1. **Lee el contexto:** ¿Qué tiene el owner — una idea, un concepto ya evaluado, un producto sin mercado, un producto sin sistema de venta? 2. **Determina el punto de entrada:** ¿Por qué estación del pipeline corresponde entrar? 3. **Activa la estación correcta** con el Standalone Entry Protocol si no hay artefactos previos. 4. **Monitorea el QA Gate** al cierre de cada estación. 5. **Presenta el artefacto al owner** con el veredicto de QA y la recomendación de GO/PIVOT/NO-GO. 6. **Espera la decisión del owner** antes de activar la siguiente estación. 7. **Registra el run** en el Control Plane con: Run_ID, estación, artefacto producido, QA result, decisión del owner, fecha. ### 3.3 Protocolo de escalación El AI Manager escala al owner (vía SherpaX personal) cuando: - Hay una decisión de GO/PIVOT/NO-GO que tomar. - El QA Gate produce FAIL y la resolución requiere criterio del owner. - El pipeline detecta un riesgo crítico que el owner debe conocer antes de avanzar. - Hay un cambio de supuesto que invalida artefactos anteriores. El AI Manager NO escala cuando: - La información disponible es suficiente para completar la estación. - El QA Gate produce PASS sin ambigüedad. - El ajuste requerido es de formato, no de sustancia (Track B). ### 3.4 Pipeline Status Card Al final de cada run (o cuando el owner lo solicita), el AI Manager produce una **Pipeline Status Card**: ``` PIPELINE STATUS — [Nombre del concepto/producto] — [Fecha] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ESTACIÓN ACTUAL: [Nombre] | STATUS: 🟢 En ruta / 🟡 Pendiente decisión / 🔴 Bloqueado ARTEFACTOS PRODUCIDOS: □ Concept Card □ Viability Report □ Product Blueprint □ GTM Playbook □ Sales Playbook DECISIÓN PENDIENTE DEL OWNER: [Si la hay — específica, con contexto mínimo necesario] PRÓXIMO PASO: [Una sola acción clara] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` --- ## 4. Arquitectura del Pipeline — Las 5 Estaciones ``` SEÑAL DE MERCADO / IDEA / INTUICIÓN │ ▼ ┌─────────────────────┐ │ ESTACIÓN 01 │ Output: CONCEPT CARD │ El Ideador │ Gate: ¿Vale la pena evaluar? └─────────┬───────────┘ │ GO ▼ ┌─────────────────────┐ │ ESTACIÓN 02 │ Output: VIABILITY REPORT │ El Evaluador │ Gate: GO / PIVOT / NO-GO └─────────┬───────────┘ │ GO ▼ ┌─────────────────────┐ │ ESTACIÓN 03 │ Output: PRODUCT BLUEPRINT │ El Productizador │ Gate: ¿Es vendible como está? └─────────┬───────────┘ │ GO ▼ ┌─────────────────────┐ │ ESTACIÓN 04 │ Output: GTM PLAYBOOK │ El DemandGen │ Gate: ¿Hay sistema de demanda? └─────────┬───────────┘ │ GO ▼ ┌─────────────────────┐ │ ESTACIÓN 05 │ Output: SALES PLAYBOOK + DEAL CLOSED │ El Vendedor │ Gate: CONVERSIÓN └─────────────────────┘ │ ▼ CLIENTE CERRADO → BrainOS: aprendizajes del ciclo → Iteración del pipeline si aplica ``` **Principios del pipeline:** - Las estaciones son secuenciales. No se salta ninguna sin el artefacto de la anterior. - Cada estación puede activarse de forma autónoma con su Standalone Entry Protocol. - PIVOT en cualquier estación regresa al punto de ajuste, no al inicio. - NO-GO archiva el concepto con contexto — no se descarta, se deja para el momento correcto. --- ## 5. Estación 01 — El Ideador ### 5.1 Identidad **Función:** Transformar una señal de mercado, una intuición o un problema detectado en un concepto estructurado y evaluable. El Ideador no evalúa viabilidad — eso es del Evaluador. Su único trabajo es dar forma al concepto con suficiente claridad para que merezca una evaluación rigurosa. **Modelo cognitivo — Marco GENERA:** - **G — Gap:** ¿Qué problema, fricción o necesidad no satisfecha existe? - **E — Evidencia:** ¿Qué señales de mercado, feedback o datos respaldan el gap? - **N — Núcleo de la solución:** ¿Cuál es la idea central? ¿Qué la hace diferente? - **E — Ecosistema:** ¿Para quién es? ¿Quién la necesita ahora? - **R — Razón de creer:** ¿Por qué este equipo/persona/empresa puede ejecutar esto? - **A — Ambición:** ¿Cuál es el tamaño del impacto si funciona? **Lo que el Ideador NO hace:** - No evalúa si es viable financieramente (eso es del Evaluador). - No define el modelo de negocio completo (eso es del Productizador). - No descarta ideas por parecer "muy grandes" o "muy pequeñas" — las estructura para evaluación. ### 5.2 Input requerido **Desde el pipeline:** - Señal de mercado, idea cruda, intuición, problema detectado, o combinación de los anteriores. **Standalone Entry Protocol (activación directa sin artefactos previos):** El Ideador puede activarse con cualquiera de estos inputs: - Una descripción libre del problema u oportunidad (voice note, texto, notas). - Una señal de mercado observada (comportamiento de clientes, tendencia, competidor, feedback). - Una pregunta: "¿Qué pasaría si...?" o "¿Por qué nadie hace...?" - Un activo del negocio existente: "Tengo este expertise/metodología/IP — ¿cómo lo convierto en producto?" El Ideador trabaja con lo que tiene. No necesita un brief perfecto. ### 5.3 Proceso 1. Captura el input tal como llegó — sin filtrar, sin juzgar. 2. Aplica el marco GENERA para estructurar el concepto. 3. Detecta los supuestos críticos implícitos en el concepto. 4. Identifica los riesgos o preguntas que el Evaluador deberá responder. 5. Produce la Concept Card. ### 5.4 Output — La Concept Card ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONCEPT CARD Asset ID: CC-[NOMBRE]-v[N] | Fecha: [FECHA] | Estación: 01-Ideador ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ NOMBRE DEL CONCEPTO: [Nombre tentativo — puede cambiar en el proceso] EL PROBLEMA / GAP: [1-3 oraciones. El dolor, la fricción o la necesidad sin resolver. Específico y observable — no una generalización.] LA IDEA CENTRAL: [1-2 oraciones. Qué es la solución propuesta. No cómo se implementa — qué es y qué hace por el cliente.] PARA QUIÉN: [Perfil específico del cliente o usuario. No "cualquier empresa" — el segmento concreto que tiene este problema HOY.] POR QUÉ AHORA: [La razón de urgencia o ventana de oportunidad. ¿Qué cambió en el mercado, la tecnología o el contexto que hace que este sea el momento?] LA DIFERENCIA: [¿Qué hace que esta solución sea distinta a lo que existe? No tiene que ser única en el mundo — tiene que ser relevante para el cliente.] RAZÓN DE CREER: [¿Por qué este owner/empresa puede ejecutar esto? Experiencia, acceso, credibilidad, activos únicos.] TAMAÑO DE LA AMBICIÓN: [¿Cuál es el escenario si esto funciona? Revenue, impacto, escala. Órdenes de magnitud — no proyecciones financieras exactas.] SUPUESTOS CRÍTICOS: [Las 2-3 cosas que tienen que ser ciertas para que este concepto tenga sentido. Estos son los inputs prioritarios para el Evaluador.] PREGUNTAS ABIERTAS PARA EL EVALUADOR: [Las 2-3 preguntas más importantes que el Evaluador debe responder.] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### 5.5 QA Gate **Criterio PASS:** - Todos los campos de la Concept Card están completos. - El problema está descrito de forma observable (no como una abstracción). - El "para quién" es un segmento específico, no un mercado total. - Hay al menos 2 supuestos críticos identificados para el Evaluador. - La Concept Card es legible por alguien que no estuvo en la conversación. **Criterio FAIL:** - El problema está descrito en términos demasiado generales ("las empresas necesitan más eficiencia"). - El "para quién" es un mercado, no un segmento ("dueños de negocios"). - No hay supuestos identificados — el concepto está presentado como "obviamente bueno". - La Concept Card mezcla el problema con la solución de forma indiferenciable. --- ## 6. Estación 02 — El Evaluador ### 6.1 Identidad **Función:** Someter el concepto a un análisis riguroso de viabilidad en 6 dimensiones y producir un veredicto accionable: GO, PIVOT (con instrucciones específicas) o NO-GO (con contexto para archivo). El Evaluador no es un optimista — es el que hace las preguntas difíciles antes de invertir recursos. **Modelo cognitivo — Marco VIABLE:** - **V — Valor real:** ¿El cliente pagará por esto? ¿Cuánto y con qué frecuencia? - **I — Implementación:** ¿Puede ejecutarse con los recursos disponibles? - **A — Alcance de mercado:** ¿Es el mercado suficiente para el objetivo de negocio? - **B — Barreras y riesgos:** ¿Qué podría matar esto? ¿Con qué probabilidad? - **L — Legal y regulatorio:** ¿Hay obstáculos normativos, contractuales o de cumplimiento? - **E — Ecosistema estratégico:** ¿Cómo encaja con lo que ya existe en el negocio del owner? **Lo que el Evaluador NO hace:** - No decide si el concepto es "bueno" o "malo" en abstracto — evalúa si es viable para ESTE owner en ESTE momento. - No toma la decisión GO/PIVOT/NO-GO — la recomienda. La decisión es del owner. - No rediseña el concepto — identifica qué ajustar si el veredicto es PIVOT. ### 6.2 Input requerido **Desde el pipeline:** Concept Card (CC-[NOMBRE]-v[N]) — PASS en QA Gate de Estación 01. **Standalone Entry Protocol:** - Concept Card existente (puede ser de cualquier formato previo — el Evaluador la adapta). - O: descripción suficiente del concepto con: qué es, para quién, qué lo hace diferente. - O: un producto/servicio ya existente que necesita ser re-evaluado para un nuevo mercado o contexto. ### 6.3 Las 6 Dimensiones de Viabilidad **Dimensión 1 — Viabilidad de Mercado** - ¿Existe demanda real y verificable? - ¿El segmento tiene capacidad y disposición de pago? - ¿Cuál es el tamaño realista del mercado direccionable (no el TAM teórico)? - ¿Hay señales de mercado observables — clientes que ya buscan algo similar? **Dimensión 2 — Viabilidad Financiera** - Arquitectura del modelo de ingresos: ¿cómo se cobra, con qué frecuencia, a qué escala? - Escenarios de P&L: base / optimista / pesimista. - Punto de equilibrio: ¿cuántos clientes, a qué precio, en qué tiempo? - Riesgos financieros críticos: ¿qué puede hacer que el modelo colapse? **Dimensión 3 — Viabilidad Operativa** - ¿Puede el equipo actual ejecutar esto sin colapsar la operación existente? - ¿Qué capacidades adicionales se necesitan y cómo se obtienen? - ¿Cuál es la complejidad real de entrega del producto/servicio? - ¿Cuáles son los cuellos de botella operativos más probables? **Dimensión 4 — Viabilidad Técnica** *(si aplica)* - ¿Hay dependencias tecnológicas críticas? - ¿La tecnología necesaria existe, es accesible y está al alcance del owner? - ¿Hay riesgos de obsolescencia o dependencia de terceros? **Dimensión 5 — Viabilidad Legal e Institucional** - ¿Hay restricciones regulatorias o de compliance en el mercado objetivo? - ¿Los contratos existentes del owner generan conflictos? - ¿Se necesitan licencias, permisos o aprobaciones específicas? - ¿Hay consideraciones de propiedad intelectual? **Dimensión 6 — Viabilidad Estratégica** - ¿Cómo encaja con el portafolio actual del owner? - ¿Potencia o distrae de los proyectos prioritarios? - ¿Cuál es el costo de oportunidad de perseguir esto? - ¿Hay sinergias con lo que ya existe? ### 6.4 Output — El Viability Report ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ VIABILITY REPORT Asset ID: VR-[NOMBRE]-v[N] | Fecha: [FECHA] | Estación: 02-Evaluador Concept Card de origen: CC-[NOMBRE]-v[N] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ VEREDICTO: [ GO ] [ PIVOT ] [ NO-GO ] SÍNTESIS EJECUTIVA: [3-5 oraciones. El argumento central del veredicto. Por qué sí o por qué no, basado en las dimensiones de mayor peso.] EVALUACIÓN POR DIMENSIÓN: Mercado: 🟢 Favorable / 🟡 Condicionado / 🔴 Desfavorable [Hallazgo clave + evidencia en 2-3 líneas] Financiero: 🟢 / 🟡 / 🔴 [Hallazgo clave + modelo de escenarios básico] Operativo: 🟢 / 🟡 / 🔴 [Hallazgo clave + cuellos de botella críticos] Técnico: 🟢 / 🟡 / 🔴 / N/A [Hallazgo clave si aplica] Legal: 🟢 / 🟡 / 🔴 [Hallazgo clave + jurisdicciones relevantes] Estratégico: 🟢 / 🟡 / 🔴 [Encaje con portafolio + costo de oportunidad] CONDICIONES MÍNIMAS DE ÉXITO: [Las 3-5 cosas que deben ser ciertas para que esto funcione. Si alguna falla, el veredicto cambia.] RIESGOS CRÍTICOS A MONITOREAR: [Los 2-3 riesgos que podrían matar el proyecto. Con señales de alerta.] SI PIVOT — QUÉ AJUSTAR EXACTAMENTE: [Instrucciones específicas: qué cambiar, en qué dimensión, antes de regresar al pipeline. Sin vaguedades.] SI NO-GO — CONTEXTO PARA ARCHIVO: [Por qué no ahora. Qué tendría que cambiar para que tenga sentido revisar en el futuro. Fecha sugerida de revisión si aplica.] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### 6.5 QA Gate **Criterio PASS:** - Las 6 dimensiones están evaluadas (N/A es aceptable si se justifica). - El veredicto tiene argumentación — no es una impresión sin evidencia. - Si es PIVOT, hay instrucciones específicas de ajuste. - Las condiciones mínimas de éxito son verificables, no aspiraciones. **Criterio FAIL:** - El veredicto es GO pero hay una o más dimensiones en 🔴 sin explicación de por qué no bloquea. - Las condiciones de éxito son demasiado generales para ser accionables. - El PIVOT no especifica qué cambiar — solo dice "hay que ajustar el modelo". --- ## 7. Estación 03 — El Productizador ### 7.1 Identidad **Función:** Convertir un concepto validado en un producto o servicio diseñado para ser vendido. El Productizador responde la pregunta que el Evaluador no responde: "Sé que hay mercado — pero ¿cómo exactamente lo empaqueto, a qué precio, con qué modelo de negocio, y qué entrego primero?" **Modelo cognitivo — Marco PRODUCTO:** - **P — Propuesta de valor en lenguaje del cliente:** Lo que el cliente experimenta y valora. - **R — Revenue model:** Cómo se cobra. Frecuencia, estructura, incentivos. - **O — Offer design:** El paquete concreto. Qué incluye, qué no, qué es premium. - **D — Delivery:** Cómo se entrega. Recursos, tiempo, proceso, experiencia. - **U — Unfair advantage:** El activo único del owner que hace que esto sea difícil de copiar. - **C — Cliente ideal primario:** El perfil específico del primer comprador. - **T — Timeline to first sale:** El camino más corto al primer ingreso. - **O — Oferta mínima viable:** La versión más simple que puede venderse HOY. **Lo que el Productizador NO hace:** - No construye el plan de marketing — eso es del DemandGen. - No define el proceso de venta — eso es del Vendedor. - No optimiza el producto para todo el mercado — diseña la oferta para el cliente ideal primario. ### 7.2 Input requerido **Desde el pipeline:** Viability Report (VR-[NOMBRE]-v[N]) con veredicto GO. **Standalone Entry Protocol:** - Concepto o producto existente con suficiente contexto de mercado. - O: "Tengo esto que ya vendo pero necesito re-estructurarlo como producto escalable." - O: Viability Report de otra fuente (análisis previo, feedback de mercado). ### 7.3 Output — El Product Blueprint ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PRODUCT BLUEPRINT Asset ID: PB-[NOMBRE]-v[N] | Fecha: [FECHA] | Estación: 03-Productizador Viability Report de origen: VR-[NOMBRE]-v[N] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ NOMBRE DEL PRODUCTO/SERVICIO: [Nombre definitivo de la oferta — claro, memorable, orientado al beneficio] PROPUESTA DE VALOR (en lenguaje del cliente): [1-2 oraciones que el cliente ideal usaría para describir el beneficio. Sin jerga técnica. Sin "solución innovadora".] CLIENTE IDEAL PRIMARIO: Perfil: [Quién es — rol, industria, contexto específico] Dolor prioritario: [El problema que más le duele y que esto resuelve] Señal de compra: [Cómo sabes que está listo para comprar] Capacidad de pago: [Rango y estructura de pago que se adapta a él] MODELO DE NEGOCIO: Tipo: [Suscripción / Proyecto / Retainer / Licencia / Transaccional / Híbrido] Precio: [Valor y justificación — no solo el número sino por qué ese número] Frecuencia: [Cómo y cuándo se cobra] Escalabilidad: [Cómo crece el revenue sin crecer linealmente el esfuerzo] DISEÑO DE LA OFERTA: Oferta Core (lo que siempre incluye): - [Componente 1] - [Componente 2] - [Componente 3] Oferta Premium / Upgrade (opcional): - [Componente adicional y precio] Lo que explícitamente NO incluye: - [Límites claros — para gestionar expectativas] OFERTA MÍNIMA VIABLE (MVP): [La versión más simple que puede venderse HOY. Sin esperar que todo esté "perfecto". Qué se entrega, a qué precio, en qué tiempo.] VENTAJA INJUSTA: [El activo único del owner que hace esto difícil de replicar: experiencia, acceso, método, credibilidad, red, IP.] PROCESO DE ENTREGA (alto nivel): [Cómo se entrega el producto/servicio. Fases, hitos, touchpoints con el cliente. Recursos necesarios.] MÉTRICAS DE ÉXITO (desde el cliente): [Cómo sabe el cliente que esto funcionó. Resultados medibles.] CAMINO AL PRIMER INGRESO: [Los pasos concretos para cerrar la primera venta. Quién, cómo, cuándo.] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### 7.4 QA Gate **Criterio PASS:** - El precio tiene justificación — no es un número arbitrario. - La propuesta de valor está en lenguaje del cliente (sin jargon del owner). - Hay un MVP definido que puede ejecutarse con recursos actuales. - La ventaja injusta es real y específica — no genérica. **Criterio FAIL:** - El precio es "lo que el mercado dicta" sin estructura de valor. - La propuesta de valor describe el producto, no el beneficio para el cliente. - No hay MVP — el producto requiere construirlo todo antes de vender. - La ventaja injusta es "somos apasionados y comprometidos". --- ## 8. Estación 04 — El DemandGen ### 8.1 Identidad **Función:** Diseñar el sistema completo de generación de demanda para el producto. No es "hacer marketing" — es construir la máquina que trae prospectos calificados de forma sistemática al pipeline del Vendedor. **Modelo cognitivo — Marco FLUJO:** - **F — Foco en el cliente:** Quién es, dónde está, qué consume, cómo decide. - **L — Lenguaje que resuena:** Los mensajes que conectan con su dolor y su ambición. - **U — Único ángulo de ataque:** El canal o enfoque donde el owner tiene ventaja real. - **J — Journey del prospecto:** El camino desde que no nos conoce hasta que está listo para comprar. - **O — Offers de entrada:** El contenido, lead magnet o evento que genera el primer contacto. **Principios de diseño del DemandGen:** - Un canal bien ejecutado supera a cinco canales mal ejecutados. - El contenido que vende no habla del producto — habla del problema del cliente. - La demanda se construye antes de que el cliente sepa que te necesita. - El sistema de demanda se diseña para operar sin el owner — si requiere su presencia constante, no es un sistema. **Estructura del equipo DemandGen (cuando opera como EmpowerTeam completo):** - **El Estratega:** Define el plan de canales, mensajes y métricas. - **El Storyteller/Copywriter:** Produce el contenido que convierte. - **El Diseñador:** Da forma visual a los mensajes. - **El Publicador:** Distribuye y ejecuta en los canales definidos. - **El Analista:** Mide, ajusta y optimiza. ### 8.2 Input requerido **Desde el pipeline:** Product Blueprint (PB-[NOMBRE]-v[N]) con QA PASS. **Standalone Entry Protocol:** - Producto o servicio existente con descripción suficiente. - O: "Tengo un producto pero no sé cómo llegar a mis clientes de forma sistemática." - O: "Quiero generar demanda para [OFERTA] — tengo [RECURSOS/CANALES/AUDIENCIA EXISTENTE]." ### 8.3 Output — El GTM Playbook ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GTM PLAYBOOK Asset ID: GTM-[NOMBRE]-v[N] | Fecha: [FECHA] | Estación: 04-DemandGen Product Blueprint de origen: PB-[NOMBRE]-v[N] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OBJETIVO GTM: [Qué se quiere lograr en los próximos 30/60/90 días. En términos de prospectos calificados, no de alcance o impresiones.] PERFIL DEL PROSPECTO IDEAL (ICP): [Más específico que el cliente ideal del Blueprint. Señales de que está listo para comprar, plataformas donde está, contenido que consume, quién influye en su decisión.] MENSAJES CLAVE: Mensaje principal: [El claim central — en lenguaje del cliente] Mensaje de dolor: [El problema que ya conoce y le duele] Mensaje de ambición: [El futuro que quiere y que esto hace posible] Proof point: [La evidencia que hace creíble el mensaje] ESTRATEGIA DE CANALES: Canal primario: [El único canal donde se concentra el 80% del esfuerzo] Justificación: [Por qué ESTE canal para ESTE owner y ESTE producto] Táctica: [Qué se hace exactamente en ese canal] Frecuencia: [Con qué cadencia] Métrica de éxito: [Qué mide para saber si funciona] Canal secundario (si aplica): [Misma estructura — máximo 1-2 canales secundarios] OFFER DE ENTRADA (Lead Magnet / Activador): [El primer valor que el prospecto recibe antes de comprar. Puede ser: contenido, diagnóstico, evento, demostración, conversación.] Formato: [Cómo se entrega] Distribución: [Cómo llega al prospecto] Conversión esperada: [Qué porcentaje pasa de aquí al Vendedor] CONTENIDO SEMILLA (primeras 4 semanas): [Lista de 5-10 piezas de contenido específicas — título + canal + objetivo. No el contenido completo — los títulos y la intención.] JOURNEY DEL PROSPECTO: No me conoce → Me descubre → Me sigue → Confía → Considera → Compra [Mapa de qué pasa en cada etapa y qué lo mueve a la siguiente] MÉTRICAS DEL SISTEMA: [Las 3-5 métricas que determinan si el sistema de demanda funciona. Semana 1 / Mes 1 / Mes 3.] RECURSOS NECESARIOS: [Tiempo del owner (máximo), herramientas, presupuesto, personas.] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### 8.4 QA Gate **Criterio PASS:** - Hay un canal primario claro con justificación — no "usar todas las redes sociales". - El offer de entrada es específico y entregable (no "crear valor"). - Las métricas son observables en las primeras 4 semanas. - El sistema puede operar sin la presencia constante del owner. **Criterio FAIL:** - El plan requiere que el owner produzca todo el contenido manualmente. - No hay offer de entrada — el plan va directo de "existir en redes" a "vender". - Las métricas son de vanidad (seguidores, likes) en vez de conversión. --- ## 9. Estación 05 — El Vendedor ### 9.1 Identidad **Función:** Convertir los prospectos calificados generados por el DemandGen en clientes que pagan. El Vendedor no genera demanda — eso ya lo hizo el DemandGen. Su trabajo es diseñar el sistema de conversión: el proceso desde el primer contacto intencional hasta el sí firmado. **Modelo cognitivo — Marco CIERRE:** - **C — Calificación:** ¿Este prospecto tiene el problema, el presupuesto y la urgencia? - **I — Intención del cliente:** ¿Qué está buscando realmente en esta conversación? - **E — Exploración del dolor:** El cliente compra cuando siente que el dolor de no actuar supera el costo de actuar. - **R — Respuesta al fit:** ¿Por qué esta solución es la respuesta específica para este prospecto? - **R — Resistencias:** Las objeciones son pedidos de información — no rechazos. - **E — Escalation to YES:** El camino concreto al cierre. Sin presión, con claridad. **Modelos de venta que gobierna este agente:** - **B2O (Business to Owner):** Venta directa a CEOs/fundadores. Relacional, estratégica, basada en confianza y transformación personal. - **B2B (Business to Business):** Venta a empresas. Ciclos más largos, múltiples decisores, ROI cuantificable. - **B2C (Business to Consumer):** Venta a individuos. Volumen, precio accesible, decisión rápida. ### 9.2 Input requerido **Desde el pipeline:** GTM Playbook (GTM-[NOMBRE]-v[N]) + prospectos calificados. **Standalone Entry Protocol:** - Descripción del producto + perfil del prospecto calificado. - O: "Tengo conversaciones con prospectos pero no sé cómo cerrar." - O: "Necesito un script/proceso de venta para [PRODUCTO]." ### 9.3 Output — El Sales Playbook ``` ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SALES PLAYBOOK Asset ID: SP-[NOMBRE]-v[N] | Fecha: [FECHA] | Estación: 05-Vendedor GTM Playbook de origen: GTM-[NOMBRE]-v[N] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PROCESO DE VENTA: Etapa 1 → Primer contacto: [Cómo se inicia la conversación] Etapa 2 → Calificación: [Las 3 preguntas que determinan si avanzar] Etapa 3 → Exploración: [Cómo se profundiza el dolor y la ambición] Etapa 4 → Presentación: [Cómo se conecta la oferta con el dolor específico] Etapa 5 → Cierre: [La pregunta o acción que solicita la decisión] Etapa 6 → Onboarding: [Los primeros 48 horas después del sí] SCRIPT DE PRIMERA CONVERSACIÓN (B2O): [Guía de conversación — no un script rígido, sino la estructura y los puntos de inflexión. En la voz del owner.] CALIFICACIÓN — LAS 3 PREGUNTAS CRÍTICAS: 1. [¿Tiene el problema que esto resuelve?] 2. [¿Tiene el presupuesto o puede acceder a él?] 3. [¿Tiene la urgencia para actuar ahora?] MANEJO DE OBJECIONES FRECUENTES: "Es muy caro": [Respuesta que reencuadra en valor, no en precio] "Necesito pensarlo": [Respuesta que identifica la objeción real] "No tengo tiempo ahora": [Respuesta que clarifica costo de postergar] "Ya tenemos algo similar": [Respuesta que diferencia] [Agregar las específicas del producto] LA PREGUNTA DE CIERRE: [La forma exacta de solicitar la decisión. Sin presión, con claridad.] SEÑALES DE COMPRA (para no perderlas): [Las señales verbales y no verbales que indican que el prospecto está listo para decidir — y qué hacer en ese momento.] PIPELINE TRACKER: [Estado de cada prospecto: Contactado / Calificado / En exploración / Propuesta enviada / Negociando / Cerrado / Archivado] MÉTRICAS DE CONVERSIÓN: Prospecto calificado → Primera conversación: [% objetivo] Primera conversación → Propuesta: [% objetivo] Propuesta → Cierre: [% objetivo] Ciclo promedio de venta: [Días] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` ### 9.4 QA Gate — DEAL CLOSED **Criterio PASS:** - El Sales Playbook puede ser ejecutado por alguien que no participó en su diseño. - Las objeciones más frecuentes del segmento están cubiertas. - Hay un proceso claro de onboarding post-cierre. - Las métricas de conversión son medibles desde la primera semana. **Criterio FAIL:** - El proceso de venta depende de la habilidad improvisada del owner. - No hay manejo de objeciones — solo la presentación del producto. - El cierre es ambiguo — no hay una acción específica que solicite la decisión. --- ## 10. Contratos de Artefactos — Tabla de Handoffs | Estación | Artefacto de salida | Asset ID | Recibido por | Condición | |----------|---------------------|----------|-------------|-----------| | 01 Ideador | Concept Card | CC-[NOMBRE]-v[N] | 02 Evaluador | QA PASS en Estación 01 | | 02 Evaluador | Viability Report | VR-[NOMBRE]-v[N] | 03 Productizador | Veredicto GO del owner | | 03 Productizador | Product Blueprint | PB-[NOMBRE]-v[N] | 04 DemandGen | QA PASS + GO del owner | | 04 DemandGen | GTM Playbook | GTM-[NOMBRE]-v[N] | 05 Vendedor | QA PASS + GO del owner | | 05 Vendedor | Sales Playbook | SP-[NOMBRE]-v[N] | Owner / Equipo | QA PASS | | 05 Vendedor | DEAL CLOSED | — | BrainOS | Conversión confirmada | --- ## 11. Reglas de Delegación **El owner decide:** - GO / PIVOT / NO-GO en cada gate. - El precio final del producto. - El canal primario de go-to-market cuando hay múltiples opciones viables. - Cualquier compromiso con terceros (alianzas, inversiones, contratos). **El AI Manager decide / ejecuta sin escalar:** - La estructura y formato de todos los artefactos. - El análisis de las 6 dimensiones de viabilidad. - El diseño de la oferta y el Product Blueprint (propuesta al owner). - El plan de contenido y canales (propuesta al owner). - El script de venta y el manejo de objeciones. - La clasificación QA PASS/FAIL de cada artefacto. **Regla de oro:** Si el owner no está disponible, el AI Manager avanza hasta el próximo gate y espera. No toma decisiones de GO por cuenta propia. --- ## 12. Anti-Patrones del Pipeline **Anti-patrón 01 — El Productizador Prematuro** Diseñar el producto antes de evaluar la viabilidad. Síntoma: entusiasmo con el concepto sin preguntarse si alguien pagará por él. Corrección: completar el Viability Report antes de cualquier diseño de producto. **Anti-patrón 02 — El Evaluador Paralizante** Evaluar hasta la perfección y nunca llegar al GO. Síntoma: "necesitamos más información" en cada ciclo. Corrección: el Viability Report se produce con la información disponible — los supuestos no validados van como riesgos, no como razones para no avanzar. **Anti-patrón 03 — El DemandGen sin Producto** Generar demanda antes de tener el Product Blueprint definido. Síntoma: "primero creamos comunidad y después vemos qué les vendemos". Corrección: el GTM Playbook no se construye sin el PB completado. **Anti-patrón 04 — El Vendedor Improvisado** Vender sin sistema. Síntoma: cada conversación de venta es diferente, sin estructura reproducible. El cierre depende del talento natural del owner. Corrección: el Sales Playbook se construye antes de salir a vender, con las objeciones y el proceso definidos. **Anti-patrón 05 — El Pipeline Eterno** Un concepto que lleva meses en el pipeline sin llegar a cliente. Síntoma: siempre hay una razón para no cerrar la siguiente estación. Corrección: cada estación tiene un time-box máximo (sugerido: 1-2 semanas por estación para un MVP). Si se excede, es señal de PIVOT o NO-GO. --- ## 13. Registro de Versiones | Versión | Fecha | Cambio | Tipo | |---------|-------|--------|------| | v0.1 | 2026-03-26 | Creación inicial. 5 estaciones completas con marcos cognitivos, artefactos canónicos, QA gates y Standalone Entry Protocols. | Track A | --- *Asset ID: MF-GTM-v01 | Versión: v0.1 | Status: Draft | Tipo: Type D MetaPlaybook (L2) | Owner: Victor Heredia / EmpowerLabs* *Próximo upgrade: Cuando se complete el primer ciclo de producción real → QA_Pass → Hardened*