product-playbook 1.0.0

package/i18n/es/references/04b-solutions.md

@@ -0,0 +1,269 @@
+# Etapa 3: Desarrollo — Diseño de Solución y Priorización
+
+## 3.2 Principio de Prototipado Paralelo
+
+Desarrolla múltiples enfoques paralelos simultáneamente — no diseñes una sola solución y te apresures a ejecutar:
+
+```
+| Pregunta HMW | Solución A (Conservadora/Incremental) | Solución B (Equilibrada) | Solución C (Audaz/Disruptiva) |
+|---|---|---|---|
+| [HMW1] | | | |
+```
+
+Tres puertas de calidad para soluciones:
+- ¿La Solución A es claramente mejor que el enfoque actual?
+- ¿La Solución C realmente resuelve el JTBD central?
+- ¿Las tres soluciones son genuinamente diferentes, o solo variaciones de la misma idea?
+
+## 3.3 Pre-mortem de Shreyas Doshi
+
+**Aplicable: Completitud media/alta / audiencia es ingenieros/planificación interna**
+
+Antes de comprometerse con una solución, asume que ya falló:
+
+```
+Supón: Elegimos la Solución X y declaramos fracaso después de [período de tiempo]. ¿Por qué falló?
+
+| Razón de Fracaso | Probabilidad (Alta/Media/Baja) | Prevenibilidad (Alta/Media/Baja) | Medida Preventiva |
+|------------------|-------------------------------|--------------------------------|-------------------|
+| | | | |
+```
+
+**Escenarios de falla de seguridad** (debe considerar al menos uno, especialmente para productos que manejan datos de usuarios):
+
+```
+| Riesgo de Seguridad | Probabilidad | Prevenibilidad | Medida Preventiva |
+|---------------------|-------------|----------------|-------------------|
+| Filtración de datos de usuario (intrusión a base de datos, acceso no autorizado a API) | | | |
+| Toma masiva de cuentas (fuerza bruta, credential stuffing) | | | |
+| Abuso de API (sin rate limiting, scraping masivo) | | | |
+| Ataques XSS / CSRF perjudicando usuarios | | | |
+| Exposición accidental de datos sensibles (secretos en control de versiones, contraseñas en logs) | | | |
+```
+
+> Si el producto no involucra autenticación de usuarios o datos sensibles, marca como "No aplicable" y explica por qué.
+
+## 3.4 Modelo de Priorización GEM de Gibson Biddle (Netflix)
+
+```
+| Funcionalidad | G (Growth) | E (Engagement) | M (Monetization) | Prioridad General |
+|---------------|-----------|----------------|------------------|------------------|
+| | | | | |
+```
+
+**Matriz de Impacto / Esfuerzo:**
+
+```
+| Funcionalidad / Solución | Impacto (Alto/Medio/Bajo) | Esfuerzo Requerido (Alto/Medio/Bajo) | Cuadrante |
+|---|---|---|---|
+| | | | Quick Win / Estratégico / Complemento / Evitar |
+```
+
+## 3.5 Priorización Cuantitativa RICE
+
+**Aplicable: Alta completitud / audiencia es científicos de datos/ejecutivos**
+
+```
+Puntuación RICE = (Reach × Impact × Confidence) / Effort
+
+| Funcionalidad | Reach (usuarios impactados/mes) | Impact (0.25/0.5/1/2/3) | Confidence (%) | Effort (persona-meses) | Puntuación RICE |
+|---------------|-------------------------------|------------------------|----------------|----------------------|----------------|
+| | | | | | |
+```
+
+**Definiciones de Escala de Impacto:**
+| Puntuación | Nivel | Criterio |
+|-----------|-------|----------|
+| 3 | Masivo | Cambia fundamentalmente la experiencia del usuario; resuelve directamente el JTBD central |
+| 2 | Alto | Mejora significativamente la experiencia del usuario; impacto positivo claro en la North Star Metric |
+| 1 | Medio | Mejora perceptible; útil para algunos usuarios o algunos escenarios |
+| 0.5 | Bajo | Mejora menor; agradable de tener |
+| 0.25 | Mínimo | Diferencia apenas perceptible; trabajo de mantenimiento |
+
+**Referencia para Juicio de Confianza:**
+- 100%: Respaldado por datos cuantitativos (pruebas A/B, datos de usuario)
+- 80%: Respaldado por datos cualitativos (entrevistas de usuario, validación competitiva)
+- 50%: Hipótesis razonable pero no validada
+- 20%: Pura intuición o conjetura
+
+> "No priorices funcionalidades — prioriza problemas. Las funcionalidades son soluciones, y solo importan después de que hayas confirmado la prioridad de los problemas." — Shreyas Doshi
+
+## 3.6 Tabla de User Stories
+
+**Aplicable: Audiencia es ingenieros**
+
+```
+| # | User Story | Criterios de Aceptación | Prioridad |
+|---|---|---|---|
+| US1 | Como [Persona], quiero [acción], para poder [valor] | | |
+```
+
+---
+
+## 📄 Formato de Output PRD (Usado cuando la audiencia es ingenieros)
+
+Cuando el usuario dice "produce un PRD" o "produce un documento para ingenieros," consolida todos los pasos relevantes anteriores y produce el siguiente formato completo:
+
+```
+# [Nombre del Producto] Documento de Requisitos de Producto
+
+**Versión**: v[X.X]　**Fecha**: [Fecha]　**Autor**: [Nombre del PM]
+**Estado**: Borrador / En Revisión / Aprobado
+
+---
+
+## 1. Antecedentes y Objetivos
+
+**Declaración del Problema**: [Transformado de la pregunta HMW — un párrafo explicando qué problema se resuelve para quién]
+**Persona Objetivo**: [Qué Persona]
+**JTBD Central**: [Cliente Objetivo] + quiere [Job] + en el contexto de [Contexto del Job]
+**Métricas de Éxito**: [North Star Metric + Hero Metric]
+
+---
+
+## 2. Resumen de Solución (del PR-FAQ)
+
+**Descripción en una línea**: [Titular del PR-FAQ]
+**Aha Moment**: Cuando el usuario completa [acción], experimenta el valor central
+**Posicionamiento del Producto**: [Resumen de posicionamiento April Dunford, si se completó]
+
+---
+
+## 3. Alcance de Funcionalidades
+
+### Imprescindibles del MVP
+| Funcionalidad | Descripción | Prioridad | Notas |
+|---------------|-------------|----------|-------|
+| | | P0 | |
+
+### Adiciones V2
+| Funcionalidad | Descripción | Prioridad | Notas |
+|---------------|-------------|----------|-------|
+| | | P1 | |
+
+### Explícitamente No Hacer (Lista de No Hacer)
+| No Hacer | Razón |
+|----------|-------|
+| | |
+
+---
+
+## 4. User Stories
+
+| # | Como un... | Quiero... | Para poder... | Criterios de Aceptación | Prioridad |
+|---|-----------|-----------|--------------|------------------------|----------|
+| US-001 | [Persona] | [Acción] | [Valor] | - [ ] Condición 1 | P0 |
+
+---
+
+## 5. Especificaciones de Funcionalidades
+
+> Para cada funcionalidad P0, documenta lo siguiente:
+
+### [Nombre de la Funcionalidad]
+- **Descripción**: [Qué hace esta funcionalidad]
+- **Condición de Activación**: [Cuándo se activa]
+- **Camino Feliz**: [Paso 1 → 2 → 3]
+- **Casos Límite**: [Escenarios de error, condiciones de frontera]
+- **Criterios de Aceptación**:
+  - [ ] [Condición específica comprobable]
+  - [ ] [Condición específica comprobable]
+
+---
+
+## 6. Consideraciones Técnicas
+
+**Restricciones Técnicas Conocidas**: [Restricciones que los ingenieros necesitan conocer]
+**Dependencias**: [Servicios de terceros, APIs, prerequisitos de otras funcionalidades]
+**Requisitos de Rendimiento**: [Tiempos de carga, concurrencia, etc., si aplica]
+**Requisitos de Seguridad**: [Protección de datos, permisos, etc., si aplica]
+
+---
+
+## 7. Riesgos y Suposiciones (del Pre-mortem)
+
+| Riesgo | Probabilidad | Impacto | Medida Preventiva |
+|--------|-------------|---------|-------------------|
+| | Alta/Media/Baja | Alto/Medio/Bajo | |
+
+**Suposiciones Centrales**: [Suposiciones que necesitan validación — si resultan falsas, la dirección necesita reevaluación]
+
+---
+
+## 8. Hitos y Cronograma
+
+| Hito | Fecha Objetivo | Incluye |
+|------|---------------|---------|
+| Alpha | | [Versión mínima testeable] |
+| Beta | | [Pruebas con usuarios limitados] |
+| Lanzamiento | | [Release oficial] |
+
+---
+
+## 9. Preguntas Abiertas
+
+| Pregunta | Responsable | Fecha Esperada de Resolución |
+|----------|-------------|----------------------------|
+| | | |
+```
+
+---
+
+## 🗂️ Artefactos de Desarrollo (Activados bajo demanda)
+
+### Diagrama de Flujo (sintaxis Mermaid)
+
+Cuando el usuario dice "produce un diagrama de flujo," genera un diagrama de flujo Mermaid basado en User Stories y especificaciones de funcionalidades:
+
+```mermaid
+flowchart TD
+    A[Usuario entra] --> B{¿Autenticado?}
+    B -- Sí --> C[Mostrar pantalla principal]
+    B -- No --> D[Redirigir a login]
+    C --> E[Completar acción central]
+    E --> F[Alcanzar Aha Moment]
+```
+
+Incluir: Flujo principal del usuario / Ramas de decisión clave / Escenarios de error
+
+### DB Schema (sintaxis Mermaid ERD)
+
+Cuando el usuario dice "produce un DB schema," genera un Mermaid erDiagram basado en el alcance de funcionalidades del MVP:
+
+```mermaid
+erDiagram
+    USER {
+        int id PK
+        string name
+        string email
+        datetime created_at
+    }
+    PRODUCT {
+        int id PK
+        string name
+        int owner_id FK
+    }
+    USER ||--o{ PRODUCT : "owns"
+```
+
+Incluir: Entidades principales / Relaciones / Campos clave (FKs, recomendaciones de índices)
+
+### UI Wireframe (wireframe HTML)
+
+Cuando el usuario dice "produce un UI wireframe," produce un wireframe de baja fidelidad en HTML + CSS inline, incluyendo:
+- Páginas centrales (determinar cantidad de páginas basado en User Stories)
+- Esquema de colores en escala de grises, sin colores de marca
+- Anotar el propósito funcional de cada elemento
+- Anotar dónde ocurre el Aha Moment
+
+---
+
+## 📎 Consejos de Integración de Archivos para esta Etapa
+
+| Contenido Subido | Integrar En | Acción de Integración |
+|-----------------|-------------|----------------------|
+| PRD existente / documento de requisitos | 3.7 MVP | Extraer lista de funcionalidades existentes como referencia para decisiones de límite del MVP |
+| Documento de arquitectura técnica | 3.5 RICE (Effort) | Usar complejidad técnica real para evaluar puntuaciones de Esfuerzo |
+| Mockups de diseño / wireframes | 3.2 Prototipado Paralelo + UI Wireframe | Usar como referencia visual para soluciones; identificar necesidades de diseño existentes vs. nuevas |
+| Documento de estimación de ingeniería | 3.5 RICE + 3.7 MVP | Reemplazar Esfuerzo asumido con estimaciones reales; ajustar alcance del MVP |
+| Postmortems de versiones anteriores | 3.3 Pre-mortem | Complementar lista de riesgos con lecciones históricas de fracaso |

package/i18n/es/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# Etapa 3: Desarrollo — Definición del Alcance del MVP
+
+## 3.7 Definición del Alcance del MVP
+
+Criterios de decisión del MVP: **¿Puede validar la hipótesis central? ¿Puede permitir que los usuarios objetivo experimenten completamente el JTBD Primario?**
+
+```
+| Categoría | Imprescindible del MVP | Agregar en V2 | Consideración Futura |
+|---|---|---|---|
+| Funcionalidades Centrales | | | |
+| Experiencia de Usuario | | | |
+| Requisitos Técnicos | | | |
+```
+
+**Lista de No Hacer (Igualmente importante):**
+
+```
+| No Hacer | Razón |
+|----------|-------|
+| | |
+```

package/i18n/es/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# Fase 4: Entrega — North Star + Aha Moment
+
+## 4.1 Principios de Empowered Teams de Marty Cagan
+
+**Aplicable cuando: alta completitud / audiencia del entregable es liderazgo o equipos cross-funcionales**
+
+> 4.1 Empowered Teams solo se muestra cuando la audiencia del entregable es liderazgo o equipos cross-funcionales; de lo contrario se omite.
+
+```
+| Dimensión | Feature Team (Evitar) | Empowered Team (Meta) |
+|-----------|----------------------|----------------------|
+| Asignado | Lista de funcionalidades (Output) | Problema a resolver (Outcome) |
+| Éxito definido como | Entregar funcionalidades a tiempo | Lograr métricas de usuario y negocio |
+| Rol del PM | Recopilador de requisitos y project manager | Explorador de problemas y validador de soluciones |
+| Rol de Ingenieros | Ejecutar especificaciones | Participar en exploración de problemas y diseño de soluciones |
+```
+
+> "El verdadero descubrimiento de producto se hace **junto con** ingenieros y diseñadores, no por el PM solo entregando trabajo terminado." — Marty Cagan
+
+**Tres Responsabilidades del PM de Lenny:**
+- **Shape**: Sintetizar insights de usuarios, datos e inteligencia de mercado para decidir qué construir
+- **Ship**: Asegurar que un producto de alta calidad se lance a tiempo, sin sorpresas
+- **Synchronize**: Mantener a todos los stakeholders alineados en visión, estrategia, metas y roadmap
+
+## 4.2 Framework de Métricas de Éxito (North Star + Señales de Tres Capas)
+
+Una North Star metric debe satisfacer:
+- Refleja el valor real que los usuarios reciben (no una métrica vanidosa)
+- Puede crecer continuamente (no tiene un techo natural)
+- Alinea a todo el equipo alrededor de un solo objetivo
+
+```
+| Empresa | North Star Metric | Por Qué Esta Métrica |
+|---------|-------------------|----------------------|
+| Airbnb | Noches reservadas | Representa valor entregado tanto a anfitriones como a huéspedes |
+| Spotify | Horas de escucha mensual | Representa usuarios genuinamente usando y disfrutando la música |
+| Facebook | Ratio DAU / MAU | Representa visitas de retorno habituales |
+| Slack | Mensajes enviados por semana | Representa equipos genuinamente colaborando |
+| Salesforce | ACV de clientes activos (Valor de Contrato Anual) | Representa clientes derivando valor de negocio continuamente (B2B) |
+```
+
+**Tu North Star Metric:**
+```
+North Star Metric: [Un solo número que representa el valor central creado para los usuarios y el producto]
+Definición: [Método de cálculo preciso]
+Por qué esta métrica: [Explica por qué representa valor real para el usuario, no solo un resultado de negocio]
+```
+
+### 📝 Lista de Verificación de Calidad de North Star
+- ✅ ¿Refleja el valor que los usuarios reciben? (No ingresos, no DAU)
+- ✅ ¿Puede crecer continuamente? (No tiene un techo natural)
+- ✅ ¿Todos en el equipo saben qué hacer cuando ven esta métrica?
+- ✅ ¿Puede ser manipulada? (Si sí, se necesitan métricas de protección)
+- ✅ Productos B2B: ¿Refleja valor a nivel organizacional, no solo de usuarios individuales?
+- ❌ Problemas comunes: usar ingresos como North Star (los ingresos son un resultado, no un impulsor), métrica demasiado compuesta para actuar sobre ella
+
+**Sistema de Señales de Tres Capas (debe lograrse en orden):**
+
+```
+| Capa | Tipo de Métrica | Definición | Objetivo B2C | Objetivo B2B |
+|---|---|---|---|---|
+| Capa 1 (Prerequisito) | Tasa de Éxito de Acción Central | ¿El usuario completó la acción central del producto? | 30–40%+ | 60–80%+ (usuarios más motivados) |
+| Capa 2 (Proxy de Valor) | Tasa de Retención D14 / D28 | ¿Los usuarios siguen regresando? | Productos de consumo 15–20%+ | Retención de logos 90%+; Net Revenue Retention 100%+ |
+| Capa 3 (Señal de Pasión) | Sean Ellis Score | "Si ya no pudieras usar este producto, ¿qué tan decepcionado estarías?" | 40%+ responde "muy decepcionado" | 40%+ responde "muy decepcionado" |
+| Métricas de Protección | Prevenir sobre-optimización | Asegurar que otras dimensiones importantes no se perjudiquen | Depende del contexto | Depende del contexto |
+```
+
+Nota: La Capa 1 es prerequisito de la Capa 2. Si la tasa de éxito de la acción central es muy baja, los datos de retención son irrelevantes porque los usuarios nunca tuvieron la oportunidad de experimentar el valor del producto.
+
+## 4.4 Diseño del Aha Moment
+
+```
+Definición del Aha Moment:
+Cuando un usuario completa [comportamiento específico], ha experimentado el valor central de este producto.
+Meta: Llevar a los usuarios a este momento dentro de [X minutos / X pasos] de entrar al producto.
+
+Tasa de Alcance del Aha Moment: [% objetivo]
+Barreras Actuales: [¿Qué impide que los usuarios alcancen el Aha Moment más rápido?]
+Plan de Mejora: [¿Cómo eliminar las barreras?]
+```
+
+**Ejemplos:**
+| Producto | Aha Moment | Objetivo de Tiempo |
+|---------|-----------|-------------------|
+| Slack | El equipo envía su mensaje número 2,000 | Primeras dos semanas |
+| Dropbox | Primer archivo sincronizado a un segundo dispositivo | Dentro de 10 minutos del primer uso |
+| Zoom | Primera conexión con un clic con video fluido | Primer uso |
+
+### 📝 Lista de Verificación de Calidad del Aha Moment
+- ✅ ¿Es un comportamiento específico y rastreable? (No "siente que el producto es útil")
+- ✅ ¿Está directamente vinculado al job funcional del JTBD?
+- ✅ ¿El objetivo de tiempo es razonable? (B2C debería ser dentro del primer uso; B2B puede ser dentro del período de prueba)
+- ✅ ¿Se puede diseñar el onboarding para ayudar a los usuarios a alcanzarlo más rápido?

package/i18n/es/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# Etapa 4: Entrega — PMF + GTM + Modelo de Negocio
+
+## 4.3 Framework de Cuatro Niveles de PMF de Todd Jackson (First Round Capital)
+
+```
+| Nivel | Nombre | Características | Tu Tarea | Etapa Típica de la Empresa |
+|-------|--------|----------------|----------|---------------------------|
+| Nivel 1 | PMF Naciente | Encontró 3-5 clientes dispuestos a pagar por la solución | Atender profundamente a estos primeros usuarios, encontrar un patrón repetible | Pre-seed / Seed |
+| Nivel 2 | PMF en Desarrollo | El boca a boca comienza, pero el crecimiento aún es inestable | Encontrar un canal de adquisición escalable, mejorar retención | Seed / Serie A |
+| Nivel 3 | PMF Fuerte | "Los peces saltan al bote" — los referidos se convierten en el principal impulsor de crecimiento | Construir canales de demanda escalables, mejorar métricas de eficiencia | Serie A / B |
+| Nivel 4 | PMF Extremo | Las métricas son robustas, la empresa supera las 100 personas, considerando expansión de TAM | Entrar en nuevos mercados o lanzar nuevos productos | Serie C+ |
+```
+
+**Cuatro P's (Preguntas clave para encontrar PMF en Nivel 1-2):**
+1. Problem: ¿El problema que estás resolviendo es realmente urgente e importante?
+2. Promise: ¿Qué promesa hace tu producto a los usuarios? ¿La creen?
+3. Product: ¿Tu producto realmente cumple esa promesa?
+4. Pitch: ¿Cómo haces que los usuarios objetivo descubran y crean en tu producto?
+
+## 4.7 Estrategia GTM (Go-to-Market)
+
+**Aplicable: Modo completo / alta completitud / audiencia es ejecutivos/ventas/marketing**
+
+Una vez que el producto está construido, ¿cómo haces que los usuarios objetivo lo conozcan y comiencen a usarlo?
+
+### Selección de Canal de Adquisición
+
+```
+| Tipo de Canal | Ideal Para | Métodos Típicos | Métricas Clave |
+|--------------|----------|----------------|---------------|
+| Product-Led Growth (PLG) | Productos donde los usuarios pueden auto-servirse para experimentar el valor | Prueba gratuita, Freemium, invitación viral | Conversión de registro, tasa de activación, tasa de invitación |
+| Contenido y Comunidad | Usuarios objetivo comparten necesidades de información comunes o comunidad | Blog, SEO, construcción de comunidad, KOL | Tráfico, tasa de conversión de contenido, engagement de comunidad |
+| Adquisición Pagada | Necesidad de validación rápida o ROI claro | SEM, anuncios sociales, retargeting | CAC, ROAS, LTV/CAC |
+| Sales-Led | B2B alto ACV, requiere demo y negociación | SDR, AE, Demo, contratos enterprise | Pipeline, tasa de cierre, ACV |
+| Alianzas | Usuarios objetivo concentrados en plataformas o ecosistemas específicos | Integración API, revenue sharing, co-marketing | Tasa de conversión del canal de alianza, número de aliados |
+```
+
+### Plan de Adquisición de los Primeros 100 Usuarios
+
+```
+Perfil de usuario objetivo: [Del Persona]
+Dónde encontrarlos: [Lugares online/offline donde se congregan]
+Qué gancho para atraerlos: [Del Aha Moment del PR-FAQ]
+Cómo hacer que prueben: [Métodos para bajar la barrera]
+Meta inicial: [X usuarios probando el producto en Y días]
+```
+
+### Estrategia de Lanzamiento
+
+| Estrategia | Descripción | Ideal Para |
+|-----------|-------------|----------|
+| Beta Cerrada | Invitar manualmente 10-50 personas, recopilar feedback profundo | PMF Nivel 1, producto aún en refinamiento |
+| Beta Abierta | Pública pero etiquetada como Beta, gestionando expectativas | PMF Nivel 1-2, necesitan más datos |
+| Soft Launch | Lanzamiento discreto en un mercado o canal específico | Necesitan pruebas del mundo real sin exposición completa |
+| Lanzamiento Completo | Release oficial en todos los canales | PMF Nivel 2-3, producto es estable |
+
+## 4.8 Modelo de Negocio y Precios
+
+**Aplicable: Modo completo / alta completitud / audiencia es ejecutivos/ventas**
+
+### Selección de Modelo de Ingresos
+
+```
+| Modelo | Cómo Funciona | Ideal Para | Métricas Clave |
+|--------|-------------|----------|---------------|
+| Freemium | Nivel básico gratuito + premium pagado | Productos con gran base de usuarios, nivel gratuito demuestra valor | Tasa de conversión gratuito-a-pagado (objetivo 2-5%) |
+| Suscripción | Suscripción mensual/anual | Herramientas o servicios que proveen valor continuo | MRR/ARR, tasa de churn |
+| Basado en uso | Paga por lo que usas | APIs, servicios de nube, plataformas de transacciones | Gasto promedio por usuario, tasa de crecimiento de uso |
+| Compra única | Compra directa | Software de herramientas, cursos | Valor promedio de orden, tasa de recompra |
+| Comisión por transacción | Porcentaje por transacción | Plataformas, marketplaces | GMV, take rate |
+| Por asiento | Cobro por usuario | Herramientas de colaboración B2B | Asientos promedio por cuenta, tasa de expansión |
+```
+
+### Alineación de Precios Basados en Valor
+
+```
+Preguntas centrales de precios:
+1. ¿Cuánto ahorra o genera tu producto para los usuarios? (Ancla de valor)
+2. ¿Cuánto pagan actualmente los usuarios por alternativas? (Referencia competitiva)
+3. ¿Tu precio es proporcional al valor que los usuarios reciben? (Percepción de justicia)
+
+Estrategia de precios:
+  - Elección de modelo: [Freemium / Suscripción / Basado en uso / ...]
+  - Rango de precio: [Basado en ancla de valor y referencia competitiva]
+  - Qué incluye el nivel gratuito: [Suficiente para alcanzar el Aha Moment, pero no para necesidades avanzadas]
+  - Punto de activación de pago: [¿Qué comportamiento de uso o volumen activa un upgrade?]
+
+⚠️ Errores comunes de precios:
+  - Precio demasiado bajo (señala "no vale mucho")
+  - Nivel gratuito demasiado generoso (sin motivación para upgrade)
+  - Desalineación precio-valor (precios basados en funcionalidades vs. basados en valor)
+  - B2B sin descuentos por contrato anual (perdiendo estabilidad de flujo de caja)
+```
+
+---
+
+## 📎 Consejos de Integración de Archivos para esta Etapa
+
+| Contenido Subido | Integrar En | Acción de Integración |
+|-----------------|-------------|----------------------|
+| Datos financieros / reportes de ingresos | 4.8 Modelo de Negocio | Reemplazar suposiciones con estructura de ingresos real, evaluar razonabilidad de precios |
+| Datos de canales de marketing | 4.7 GTM | Usar CAC real, tasas de conversión y otros datos para evaluar selección de canales |

package/i18n/es/references/05c-validation-spec.md

@@ -0,0 +1,117 @@
+# Etapa 4: Entrega — Validación de Hipótesis + Resumen de Spec de Producto
+
+## 4.5 Plan de Validación de Hipótesis
+
+**Aplicable: Completitud media/alta / audiencia es científicos de datos/uno mismo**
+
+```
+| Hipótesis Central | Método de Validación | Momento de Validación | Criterio de Éxito | Si la hipótesis es incorrecta, vamos a... |
+|-------------------|----------------------|----------------------|------------------|------------------------------------------|
+| | Entrevistas a usuarios alpha / datos | | | |
+```
+
+Principios: Validación cualitativa (entrevistas de usuario, estudios de diario) + validación cuantitativa (datos) tienen igual peso; mantente alerta a tu propio sesgo de confirmación.
+
+## 4.6 Resumen de Spec de Producto
+
+El Resumen de Spec de Producto es el entregable final en todos los modos (el Modo Rápido produce un resumen de dirección de una página — estructura diferente pero mismo espíritu).
+El Resumen de Spec de Producto tiene tres secciones, correspondientes a diferentes profundidades de lectura:
+
+### Sección 1: Resumen de Decisiones (Legible en 30 segundos)
+
+```
+**Descripción en una línea**: [Titular del PR-FAQ]
+**Para Quién**: [Persona objetivo en una oración]
+**Valor Central**: [Job funcional JTBD + job emocional, en una oración]
+**North Star Metric**: [Nombre de la métrica + definición]
+**Nivel PMF Actual**: [Nivel 1-4 + explicación de una oración]
+```
+
+### Sección 2: Límites de Ejecución (Legible en 2 minutos)
+
+```
+**Declaración JTBD Central**: [Cliente Objetivo] + quiere [Job] + en el contexto de [Contexto del Job]
+**Aha Moment**: Cuando el usuario completa [acción], experimenta el valor central. Meta: alcanzarlo dentro de [X].
+**Imprescindibles del MVP**: [3-5 funcionalidades/capacidades más críticas]
+**No Hacer (Deliberadamente excluido de esta versión)**: [Exclusiones explícitas + razones]
+**Hipótesis Clave**: [2-3 hipótesis centrales que necesitan validación]
+**Riesgos Principales del Pre-mortem**: [2-3 causas más probables de fracaso]
+**Hero Metric**: [1-2 métricas de éxito más importantes + valores objetivo]
+```
+
+### Sección 3: Referencia Profunda (Consultar cuando sea necesario)
+
+```
+**Desglose JTBD**:
+  - Job Funcional:
+  - Job Emocional:
+  - Job Social:
+**Posicionamiento April Dunford**:
+  - Alternativas competitivas reales:
+  - Nuestros atributos únicos:
+  - Valor central para usuarios objetivo:
+  - Características del mercado objetivo:
+  - Categoría de mercado:
+**Pregunta HMW Central**: [De la etapa de Definición]
+**Descripción de la Solución**: [Del resumen del PR-FAQ]
+**Modelo de Negocio**: [Modelo de ingresos + estrategia de precios, si se completó]
+**Estrategia GTM**: [Canal de adquisición inicial + estrategia de lanzamiento, si se completó]
+```
+
+Después de completar las tres secciones, Claude **debe agregar proactivamente las siguientes tres secciones** sin esperar a que el usuario las solicite:
+
+---
+
+### ⚠️ Registro de Riesgos
+
+Consolida todos los riesgos identificados a lo largo del proceso de planificación (fuentes: Pre-mortem + Evaluación de Oportunidades + Validación de Hipótesis):
+
+```
+| Tipo de Riesgo | Descripción del Riesgo | Severidad (Alta/Media/Baja) | ¿Mitigación Implementada? |
+|---------------|----------------------|---------------------------|--------------------------|
+| Riesgo de mercado | | | |
+| Riesgo de suposición de usuario | | | |
+| Riesgo técnico | | | |
+| Riesgo competitivo | | | |
+| Riesgo de ejecución | | | |
+```
+
+---
+
+### 🔍 Brechas y Puntos Ciegos
+
+Claude identifica proactivamente los siguientes tipos de brechas basándose en todo el flujo de conversación:
+
+```
+| Tipo | Descripción | Siguiente Paso Recomendado |
+|------|------------|---------------------------|
+| Pasos no ejecutados | [Qué frameworks se omitieron y qué puntos ciegos puede causar] | |
+| Datos insuficientes | [Qué decisiones están basadas en suposiciones en lugar de datos reales de usuarios] | |
+| Saltos lógicos | [Dónde el razonamiento carece de evidencia intermedia] | |
+| Hipótesis no validadas | [Lista de todas las hipótesis centrales sin método de validación aún] | |
+| Definiciones poco claras | [Qué conceptos necesitan definición más precisa antes de la ejecución] | |
+```
+
+---
+
+### 💡 Recomendaciones Adicionales
+
+Claude proporciona 3-5 recomendaciones específicas y accionables basadas en las características del producto, etapa y riesgos conocidos:
+
+```
+1. [Máxima prioridad]: [Acción específica] — Justificación: [Por qué esto importa más]
+2. [Segunda prioridad]: [Acción específica] — Justificación:
+3. [Tercera prioridad]: [Acción específica] — Justificación:
+...
+```
+
+Las recomendaciones pueden cubrir: métodos de validación con usuarios, ajustes de límites del MVP, estrategia competitiva, diseño de métricas, asignación de equipo, prioridades del próximo hito.
+
+---
+
+## 📎 Consejos de Integración de Archivos para esta Etapa
+
+| Contenido Subido | Integrar En | Acción de Integración |
+|-----------------|-------------|----------------------|
+| Datos de comportamiento de usuario (CSV / Excel) | 4.2 North Star + 4.3 PMF | Usar datos reales de retención y engagement para evaluar nivel de PMF; calibrar línea base de North Star |
+| Resultados de encuesta Sean Ellis | 4.3 PMF + 4.2 Señales de Tres Capas | Calcular Score directamente, llenar en Capa 3 |