| 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:
- El usuario dice explicitamente "simulacion", "what-if", "prueba", "--what-if"
- El usuario dice "probemos con..." o "quiero probar" o "sin guardar"
- 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:
- 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."
- 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.
- 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)
- Identificar Top 3 supuestos del Cuadrante B (alto riesgo + desconocido) -- esos son los
candidatos principales para testear con las entrevistas de Fase 2b
- 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:
- 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]."
- 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)"
- Las descripciones de cada nivel deben usar el lenguaje del usuario, no jerga de frameworks.
- 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
