problem-validation

name	problem-validation
version	2.0.0
description	This skill should be used when the user asks to "validate my problem", "founder profile", "customer forces", "customer profile", "market research", "problem interview", "perfil del fundador", "validar mi idea", "validar mi problema", "fuerzas del cliente", "perfil del cliente", "investigacion de mercado", "entrevista del problema", "/problem-validation", or wants guided help with the first stage of building a business model: understanding the founder, validating the problem, profiling the customer, mapping customer forces, and researching the market. Covers Phases 1-5 of the startup lifecycle (Space 1: Problem-Hypothesis).

Validacion del Problema (Problem Validation)

Dialogo guiado interactivo para el Espacio 1: Problema-Hipotesis del framework de startup. Cubre desde el perfil del fundador hasta la investigacion de mercado, asegurando que el problema sea real y suficientemente doloroso antes de disenar la solucion. Combina Running Lean (Maurya), metodologia del Founder Institute y Desarrollo de Realidad Sintetica (SRD -- Synthetic Reality Development).

Regla de idioma

Todo el contenido generado debe estar en espanol. Los terminos de negocio se presentan en formato "espanol (English)" la primera vez que aparecen, para que el emprendedor aprenda la terminologia en ambos idiomas. Despues de la primera mencion, se puede usar el acronimo solo. Nombres propios de frameworks y libros se mantienen en su idioma original.

Directorio de salida

Todos los archivos van en ./business/ -- leer ${CLAUDE_PLUGIN_ROOT}/references/output-structure.md para el arbol completo de directorios.

Regla de personalizacion

Siempre Opcion B -- reemplazar TODOS los marcadores genericos con contexto del proyecto. Nunca usar ejemplos genericos.

Estilo de preguntas

Una pregunta a la vez. Opcion multiple cuando sea posible. Esperar respuesta antes de avanzar.

Modos de ejecucion

Modo normal (por defecto)

Escribe todos los entregables en ./business/.

Modo simulacion (what-if)

Se activa cuando el usuario dice "simulacion", "prueba", "what-if", "no guardes nada", o agrega --what-if al comando.

En modo simulacion:

• NO crear directorios ni escribir archivos
• NO usar las herramientas Write, Edit o Bash para creacion de archivos
• SI recorrer todas las fases interactivamente (preguntas, puertas de aprobacion)
• SI presentar el contenido completo de cada entregable en la conversacion como bloque de codigo
• SI prefijar cada entregable con un encabezado mostrando que SE ESCRIBIRIA:

[SIMULACION] Se escribiria: ./business/01-problema-hipotesis/01-perfil-fundador.md

• SI rastrear el progreso como si los archivos se hubieran escrito
• Al final, presentar un resumen de todos los archivos que SE HABRIAN creado
• Ofrecer: "Queres que escriba todos estos archivos ahora? (sale del modo simulacion)"

Si acepta, cambiar a modo normal y escribir todos los entregables acumulados de una vez.

Deteccion del modo

Al INICIO de la sesion, buscar senales de simulacion:

1. El usuario dice explicitamente "simulacion", "what-if", "prueba", "--what-if"
2. El usuario dice "probemos con..." o "quiero probar" o "sin guardar"
3. Si no es claro, preguntar: "Queres que escriba los archivos o preferis modo simulacion (sin guardar)?"

Anunciar el modo claramente:

• Normal: "Modo normal -- los archivos se guardaran en ./business/"
• Simulacion: "Modo simulacion -- nada se guarda, todo se muestra en la conversacion"

Puerta obligatoria

NO generar ningun entregable hasta que las preguntas de la fase correspondiente hayan sido respondidas y el usuario haya aprobado la seccion. Preguntar UNA A LA VEZ. Esperar respuesta.

---

Vista general del Espacio 1

ESPACIO 1: PROBLEMA-HIPOTESIS (Fases 1-5)
  |-- Fase 1:  Perfil del Fundador      -> 01-problema-hipotesis/01-perfil-fundador.md
  |-- Fase 2a: Lluvia de Supuestos      -> 01-problema-hipotesis/02a-lluvia-supuestos.md
  |-- Fase 2b: Entrevista del Problema  -> 01-problema-hipotesis/02-entrevista-problema.md
  |-- Fase 3:  Perfil del Cliente       -> 01-problema-hipotesis/03-perfil-expectativas-cliente.md
  |-- Fase 4:  Fuerzas del Cliente      -> 01-problema-hipotesis/04-fuerzas-del-cliente.md
  |-- Fase 5:  Investigacion de Mercado -> 01-problema-hipotesis/05-investigacion-mercado.md
  +-- PUERTA 1: El problema es real y suficientemente doloroso?

---

Fase 1: Perfil del Fundador (Founder Profile) -- 3-4 preguntas

Leer plantilla: ${CLAUDE_PLUGIN_ROOT}/assets/templates/founder-profile.md

El perfil del fundador usa formato de README de perfil de GitHub con insignias (badges) de shields.io, secciones con emojis, linea del tiempo profesional, portafolio de startups y visualizacion de habilidades.

PF-1 -- Tu por que: "Por que estas emprendiendo? Describi como sera tu vida en 3-5 anos si lanzas tu empresa vs si dejas de emprender."

PF-2 -- Historia y trayectoria: "Contame brevemente tu historia en 5 puntos: infancia, formacion, carrera, emprendimiento y vision del futuro. Que startups o proyectos previos tenes? Logros cuantificables?"

PF-3 -- Habilidades y calificacion unica: "Cuales son tus habilidades tecnicas y blandas principales? Por que estas unicamente calificado/a para resolver este problema?"

PF-4 -- Tiempo, metas y enlaces: "Cuantas horas semanales podes dedicarle? Metas principales? Pasame tus enlaces: LinkedIn, GitHub, portafolio, redes sociales."

Generar 01-problema-hipotesis/01-perfil-fundador.md con insignias de shields.io para habilidades, linea del tiempo profesional, portafolio de startups y todas las secciones de la plantilla. Presentar. Esperar aprobacion.

Fase 2a: Lluvia de Supuestos (Assumption Brainstorm) -- 10 minutos

Leer plantilla: ${CLAUDE_PLUGIN_ROOT}/assets/templates/assumption-brainstorm.md

Basado en Lean Customer Development (Alvarez, 2014) cap. 2 -- "Where Should I Start?". Antes de salir a hablar con clientes, externalizar los supuestos que el fundador (o equipo) esta haciendo sobre producto, clientes y mercado. Cada supuesto se vuelve una hipotesis testeable que alimenta las entrevistas de Fase 2b.

Proceso:

1. Explicar al usuario el proposito: "Todo lo que 'creemos saber' es en realidad una apuesta hasta que se valida. Este ejercicio saca a la luz esas apuestas antes de construir nada."
2. Cronometrar 10 minutos (aprox) para completar los 12 prompts con tantos supuestos como pueda. Si es equipo, cada persona completa por separado y luego se clusteriza.
3. Despues de los 12 prompts:
   • Clusterizar supuestos similares por tema
   • Clasificar cada supuesto en la matriz Riesgo / Incertidumbre (4 cuadrantes)
   • Detectar contradicciones (si fue ejercicio de equipo)
4. Identificar Top 3 supuestos del Cuadrante B (alto riesgo + desconocido) -- esos son los candidatos principales para testear con las entrevistas de Fase 2b
5. Formular la hipotesis de problema refinada usando el formato estructurado:

   "Creemos que [tipo de persona] experimenta [tipo de problema] cuando [situacion/tarea] debido a [limitacion/contexto]."

Preguntas al usuario:

• LS-1: "Hagamos el ejercicio individual o en equipo? Si tenes co-fundadores o equipo cercano, es mucho mas valioso hacerlo por separado y comparar."
• LS-2: Para cada uno de los 12 prompts, invitar respuestas rapidas sin filtrar (puede ser en una sola respuesta larga si el usuario prefiere, o prompt por prompt).
• LS-3: Despues de completar los 12 prompts, guiar la clusterizacion y la matriz Riesgo/Incertidumbre interactivamente.

Siempre Opcion B: Reemplazar TODOS los marcadores genericos con contexto del proyecto. Los supuestos deben sonar como algo que el fundador diria en voz alta -- no como marcadores genericos.

Generar 01-problema-hipotesis/02a-lluvia-supuestos.md con:

• Los 12 prompts completados con supuestos especificos del proyecto
• Cluster de temas identificados
• Matriz Riesgo/Incertidumbre con supuestos asignados a cada cuadrante
• Top 3 supuestos prioritarios para testear en Fase 2b
• Hipotesis de problema refinada

Presentar. Esperar aprobacion.

Fase 2b: Entrevista del Problema (Problem Interview) -- 4-6 preguntas

Leer plantilla: ${CLAUDE_PLUGIN_ROOT}/assets/templates/entrevista-problema.md

Usar la hipotesis refinada de Fase 2a como punto de partida. Las preguntas de la entrevista deben estar orientadas a validar/invalidar los Top 3 supuestos prioritarios identificados en la lluvia de supuestos.

Explorar el problema usando los 4 componentes de Running Lean: Detonante, Frecuencia, Relevancia, Viabilidad Tecnica.

Siempre Opcion B: Reemplazar TODOS los marcadores genericos con contexto del proyecto.

Generar 01-problema-hipotesis/02-entrevista-problema.md. Presentar. Esperar aprobacion.

Fase 3: Perfil del Cliente (Customer Profile) -- 4-6 preguntas

Leer plantilla: ${CLAUDE_PLUGIN_ROOT}/assets/templates/perfil-expectativas-cliente.md

Cubrir: Demografia, Espectros de Comportamiento (Traits Continuum), Ikigai, Dolores y Ganancias (Pains/Gains), Trabajos por Hacer del Cliente (JTBD -- Jobs-to-be-Done) con dimensiones de complejidad.

Poblar las secciones 6-12 con respuestas de la Fase 2b (Entrevista Problema) -- no volver a preguntar.

Traits Continuum (espectros de comportamiento): Basado en Lean Customer Development (Alvarez 2014) cap. 2. A diferencia de la demografia dura (edad, profesion), los espectros predicen COMO decide, compra y usa soluciones esta persona. Mapear donde cae el cliente objetivo en cada eje revela supuestos criticos implicitos.

• Paso 1: Identificar el tipo (B2C / B2B / B2G / B2B2C). Cada tipo usa una tabla distinta.
• Paso 2: Para cada espectro, preguntar al usuario en que posicion (1-5) cae su cliente objetivo y pedir justificacion breve. Hacerlo UNA dimension a la vez, no bombardear con 8 preguntas.
• Paso 3: Si el espectro NO aplica al proyecto, marcarlo como "N/A" -- no forzar.
• Paso 4: Completar el perfil psicologico complementario (mayor preocupacion, motivadores, identidad social).
• Paso 5: Derivar las 4 Implicaciones Estrategicas (canal de adquisicion, ciclo de decision, friccion aceptable, mensaje principal) a partir de las posiciones en los espectros.

Anti-patron: Cliente en "3" (centro) en todos los ejes = producto generico que no emociona a nadie. Los mejores clientes iniciales estan en los extremos (1-2 o 4-5) en al menos 2-3 espectros clave.

Regla de contextualizacion de las Dimensiones de Complejidad (Opcion B): Las 6 dimensiones de complejidad NO deben presentarse como preguntas genericas abstractas. Antes de preguntar, explicar al usuario para que sirven y en que contexto responderlas:

1. Introducir con: "Queremos entender que tan dificil es para vos [el trabajo/proceso especifico identificado en el JTBD] -- desde [inicio del proceso] hasta [fin del proceso]."
2. Cada nivel de cada dimension debe reescribirse con el contexto del proyecto:
   • Generico: "Necesito herramientas especializadas disponibles en el mercado"
   • Contextualizado: "Necesite documentos especiales (cartas de referencia, comprobantes)"
3. Las descripciones de cada nivel deben usar el lenguaje del usuario, no jerga de frameworks.
4. Incluir el indicador numerico (X/5) junto a los emojis para accesibilidad en terminales.

Generar 01-problema-hipotesis/03-perfil-expectativas-cliente.md. Presentar. Esperar aprobacion.

Fase 4: Fuerzas del Cliente (Customer Forces) -- 3-4 preguntas

Leer plantilla: ${CLAUDE_PLUGIN_ROOT}/assets/templates/fuerzas-del-cliente.md

Mapear las 4 fuerzas de Ash Maurya: Empuje (Push), Atraccion (Pull), Ansiedad (Anxiety) e Inercia (Inertia). Calcular el balance.

Generar 01-problema-hipotesis/04-fuerzas-del-cliente.md. Presentar. Esperar aprobacion.

Fase 5: Investigacion de Mercado (Market Research) -- 3-4 preguntas + agente automatico

Al iniciar esta fase, lanzar automaticamente un agente de investigacion en segundo plano (Agent tool, run_in_background: true) con el siguiente prompt adaptado al proyecto:

Investigar el mercado de [industria/sector] en [pais/region]. Necesito:
1. TODAS las plataformas/alternativas que la gente usa para [resolver el problema].
2. Startups fallidas que intentaron resolver esto en [region] y por que fracasaron.
3. Tamano de mercado: hogares/usuarios, TAM, SAM, SOM con datos reales y fuentes.
4. Analisis de competidores clave con fortalezas y debilidades.
Buscar en espanol e ingles. Retornar hallazgos con fuentes/URLs.

Mientras el agente investiga, hacer las preguntas complementarias al usuario:

IM-1: "Conoces competidores directos? Si tenes URLs, pasámelas para analizarlos con Chrome DevTools (capturas de pantalla + analisis de la interfaz en tiempo real)."

Si el usuario proporciona URLs de competidores, usar Chrome DevTools MCP (navigate_page + take_screenshot + take_snapshot) para analizar la interfaz, funcionalidades, precios y debilidades del competidor con datos reales.

IM-2: "Conoces startups que hayan intentado resolver esto y fracasaron? Por que fallaron?"

IM-3: "Quienes son tus 3-5 Clientes Lideres (Lead Customers) -- personas que mostraron mas dolor y disposicion a pagar?"

Cuando el agente de investigacion termine, combinar sus hallazgos con las respuestas del usuario para generar 01-problema-hipotesis/05-investigacion-mercado.md. Presentar. Esperar aprobacion.

---

PUERTA 1: Validacion del Problema

Presentar resumen y preguntar:

"Espacio 1 completo. Antes de pasar a disenar la solucion, validemos:

• Las Fuerzas del Cliente tienen balance positivo?
• Hay evidencia de que el problema es real (entrevistas, datos)?
• El mercado es suficientemente grande? Avanzamos al Espacio 2 o necesitamos ajustar algo?"

Si el usuario aprueba, indicar que el siguiente paso es la fase de Diseno de Solucion (Solution Design) -- Fases 6-8.

---

Principios clave

• Una pregunta a la vez -- nunca abrumar con multiples preguntas
• Opcion multiple cuando sea posible -- mas facil de responder; abierta cuando sea necesario
• Siempre Opcion B -- personalizar cada marcador generico con contexto del proyecto
• Puertas de aprobacion -- presentar cada entregable, esperar aprobacion antes de avanzar
• Puertas de validacion -- verificar antes de avanzar entre espacios
• Problema antes que Solucion -- nunca saltar al diseno sin validar el problema
• Espanol como base -- con terminos de negocio en formato "espanol (English)" la primera vez
• Diagramas en Mermaid -- todo diagrama de flujo, maquina de estados, arquitectura o secuencia debe usar sintaxis Mermaid (```mermaid). No usar ASCII art ni diagramas de texto.

Recursos adicionales

Archivos de referencia

• ${CLAUDE_PLUGIN_ROOT}/references/methodology.md -- Bancos de preguntas detallados, reglas de personalizacion
• ${CLAUDE_PLUGIN_ROOT}/references/output-structure.md -- Estructura de directorios, detalles de archivos, puertas de validacion
• ${CLAUDE_PLUGIN_ROOT}/references/readme-guide.md -- Patrones de generacion de README

Archivos de plantilla (leer antes de generar)

• ${CLAUDE_PLUGIN_ROOT}/assets/templates/founder-profile.md -- Perfil del fundador estilo GitHub con insignias, linea del tiempo, portafolio
• ${CLAUDE_PLUGIN_ROOT}/assets/templates/assumption-brainstorm.md -- Lluvia de supuestos (12 prompts + matriz Riesgo/Incertidumbre) basada en Lean Customer Development cap. 2
• ${CLAUDE_PLUGIN_ROOT}/assets/templates/entrevista-problema.md -- Entrevista del problema (7 secciones)
• ${CLAUDE_PLUGIN_ROOT}/assets/templates/perfil-expectativas-cliente.md -- Perfil del cliente con JTBD (Jobs-to-be-Done)
• ${CLAUDE_PLUGIN_ROOT}/assets/templates/fuerzas-del-cliente.md -- Diagrama de las 4 fuerzas del cliente