Skill Go-To-Market
Este skill produce un pack completo de activos go-to-market para un producto, feature o iniciativa. Sigue el marco de posicionamiento de Geoffrey Moore y estructura todos los outputs para usar en decks de ventas, landing pages, emails de lanzamiento y documentos de alineación interna.
Trabajar desde un brief
A menudo recibirás un brief corto sin todos los detalles. Siempre entrega el pack GTM completo de todas formas — no pares para hacer preguntas ni dejes placeholders entre corchetes como [AÑADIR PRUEBA] o [Capacidad técnica]. Cuando falte un detalle (diferenciadores, pruebas, features), infiere unos concretos y realistas a partir de la descripción del producto y el cliente objetivo, y marca cualquier cosa inferida como (asumido — confirmar). Una suposición concreta y etiquetada siempre es mejor que un vacío.
Inputs (infiere los no proporcionados — etiqueta suposiciones)
- Nombre del producto/feature
- Descripción de una línea (qué hace, técnicamente)
- Cliente objetivo (rol, tamaño de empresa, sector si es relevante)
- Problema principal que resuelve
- Competidor clave o alternativa (qué hace hoy la gente sin esto)
- Top 3 diferenciadores
Lee desde / Escribe a la Brain
Si existe un professional-brain (brain/), úsalo antes de preguntar:
- Lee primero:
context.md(producto, ICP, voz),knowledge/market.mdyknowledge/strategy.md, y la correspondiente entidadentities/del feature siendo lanzado. - Escribe después: guarda el plan de lanzamiento en
entities/, y cualquier decisión de posicionamiento o canal endecisions/, cada una etiquetada con su origen.
Estructura de Output
Siempre produce las cuatro secciones de abajo en orden.
1. Declaración de Posicionamiento
Usa el formato de Geoffrey Moore exactamente:
Para [cliente objetivo] que [tiene este problema o necesidad], [Nombre del Producto] es un [categoría de producto] que [beneficio/resultado clave]. A diferencia de [alternativa primaria o competidor], nuestro producto [diferenciador clave].
Escribe una declaración de posicionamiento primaria, luego ofrece una versión de tagline más corta (10 palabras o menos) adecuada para un titular hero.
2. Pilares de Mensajería
Genera 3–5 pilares de mensajería. Cada pilar debe incluir:
- Nombre del pilar (2–4 palabras, negrita)
- Resumen de una oración de lo que este pilar afirma
- 2–3 pruebas (específicas y respaldadas por evidencia; si no se proporcionaron datos, infiere una prueba realista y márcala (asumido) — nunca dejes un placeholder vacío)
- Ejemplo de uso en copy (una oración tal como aparecería en una landing page o deck)
Los pilares deben ser distintos — evita solapamientos. Cada pilar debe ser defensible frente al competidor primario.
3. Lista de Features & Funcionalidades
Produce una tabla de dos columnas:
| Feature / Funcionalidad | Beneficio para el Comprador (qué significa para el usuario) |
|---|---|
| [Capacidad técnica] | [Resultado en lenguaje plano — comienza con un verbo: "Reduce...", "Permite...", "Elimina..."] |
Reglas:
- Nunca listes un feature sin su beneficio correspondiente
- Los beneficios deben referenciar el workflow o pain point del cliente objetivo
- Apunta a 6–12 filas; si se dieron solo 1–2 features, infiere el resto de forma plausible a partir de la descripción del producto
- Evita jerga en la columna de beneficios — escribe como si explicaras a un comprador, no a un ingeniero
4. Casos de Uso
Genera 3–5 casos de uso específicos por rol. Cada caso de uso debe seguir este formato:
Caso de Uso [N]: [Rol] — [Título del Escenario]
- Quién: [Título del trabajo / rol]
- Situación: [El momento específico o disparador que los lleva a usar el producto]
- Antes: [Lo que tenían que hacer sin este producto — sé específico sobre tiempo, fricción o riesgo]
- Con [Nombre del Producto]: [Lo que hacen ahora — acción concreta, no beneficio vago]
- Resultado: [Resultado medible o tangible]
Los casos de uso deben cubrir diferentes personas compradoras si es posible (p. ej. usuario final, gestor, administrador).
Materiales Más Profundos
Este skill se distribuye con archivos de apoyo — úsalos cuando estén disponibles:
references/messaging-hierarchy.md— La Jerarquía de Mensajería: Una Afirmación, Luego Todo Lo Demás. Aplícala mientras produces el output; lleva los calibrados y juicios que el resumen del método de arriba comprime.templates/gtm-pack.md— una versión para rellenar del entregable con los quality gates en línea. Ofrécela cuando el usuario quiera trabajar el documento él mismo en lugar de tenerlo generado.
Rúbrica de Puntuación (0–40)
Puntúa cualquier output de este skill antes de entregarlo; 32+ es calidad ship.
| Dimensión | 0 | 5 | 10 |
|---|---|---|---|
| Precisión del posicionamiento | Declaración de valor genérica, sin target o alternativa | Formato Moore seguido pero la cláusula "a diferencia de" es blanda | Formato Moore con un segmento target agudo y un "a diferencia de" que nombra la alternativa real que los compradores pesan |
| Integridad mensaje-prueba | Pilares son afirmaciones no soportadas | Existen pruebas pero algunas son afirmaciones reiteradas | Cada pilar lleva ≥2 pruebas genuinas (o placeholders honestamente etiquetados), y la jerarquía lidera con una afirmación |
| Conversión feature-a-beneficio | Lista de features sin beneficios | Beneficios presentes pero pasivos o con forma de feature | Cada feature emparejado con un beneficio de verbo-acción que un comprador repetiría a su jefe |
| Usabilidad de lanzamiento | Un ensayo de posicionamiento, no un pack | Pack completo pero piezas inconsistentes entre sí | Tagline, pilares, casos de uso y lista de beneficios todos cuentan la misma historia y están listos para usar en una landing page |
Quality Checks
Antes de entregar output, verifica:
- La declaración de posicionamiento sigue el formato Moore exactamente
- El tagline tiene 10 palabras o menos
- Cada pilar tiene al menos 2 pruebas (o placeholders etiquetados)
- Cada feature tiene un beneficio — sin features huérfanos
- Los beneficios comienzan con verbos de acción
- Los casos de uso incluyen estructura Antes/Después
- El lenguaje es consistente con el vocabulario del cliente objetivo (no términos de ingeniería internos)
Anti-Patrones
- No escribas descripciones de features en lugar de beneficios — el pack GTM debe traducir features en valor para el cliente
- No uses la misma mensajería en todos los buyer personas — cada rol tiene diferentes prioridades y lenguaje
- No crees una declaración de posicionamiento que pudiera aplicar a cualquier competidor — la diferenciación debe ser específica y defensible
- No saltes la sección "no para" — definir quién no es para esto afila el posicionamiento y previene esfuerzos de ventas misdirected
- No listes casos de uso sin vincularlos a títulos de trabajo específicos o roles de comprador
Frases de Trigger de Ejemplo
- "Crea una declaración de posicionamiento para [producto]"
- "Escribe un plan GTM para [feature]"
- "Dame los pilares clave para [nombre del producto]"
- "Construye una lista de features y casos de uso para [producto]"
- "Estamos lanzando [X] — ayúdame con la mensajería"
