Problem Understanding
Entender el dolor y el trabajo del cliente.
Dolor del cliente
Habilidad: Identificar el problema real que el cliente necesita resolver, desde su perspectiva y en su lenguaje.
¿Por qué importa esta habilidad?
Las startups que construyen soluciones antes de entender el dolor real del cliente construyen para sí mismas, no para el mercado. El dolor del cliente es el punto de partida de toda la propuesta de valor.
Qué se ve como un buen resultado
El equipo puede describir el problema del cliente en el lenguaje que el cliente mismo usó, con evidencia de al menos cinco conversaciones de discovery que confirman que el problema es real y urgente.
Errores comunes
- Describir el problema en términos de la solución.
- Asumir el dolor sin validarlo con clientes reales.
- Confundir el síntoma con el problema raíz.
- Usar el lenguaje técnico del equipo en lugar del lenguaje del cliente.
Preguntas que el startup debe responder
- ¿Qué describe el cliente como su mayor frustración en este área?
- ¿Qué consecuencias tiene para el cliente no resolver este problema?
- ¿Cuánto le cuesta al cliente el problema hoy, en tiempo, dinero o riesgo?
- ¿Con qué frecuencia el cliente enfrenta este problema?
Artifact requerido
📄 Ficha del problema prioritario
Propósito: Documentar el problema del cliente con evidencia de discovery, en el lenguaje del cliente.
Card vinculada: Dolor del cliente
Instrucciones de desarrollo
- Escribe el problema en una frase usando el lenguaje que los clientes usaron en entrevistas.
- Documenta las consecuencias reales del problema: tiempo perdido, dinero, riesgo.
- Registra el número de clientes que confirmaron este problema y las citas más representativas.
- Identifica si hay un problema raíz más profundo detrás del síntoma visible.
Estado esperado: Ficha con problema articulado, consecuencias cuantificadas y evidencia de discovery.
Criterios de revisión del Artifact
- El problema está escrito en lenguaje de cliente, no de producto.
- Las consecuencias incluyen al menos un elemento cuantificado.
- Tiene evidencia de al menos tres clientes.
- Distingue síntoma de problema raíz cuando aplica.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La ficha tiene el problema articulado con evidencia de discovery.
- Las consecuencias están cuantificadas.
- El equipo usa la ficha para alinear la propuesta de valor.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ninguna definición del problema del cliente. |
| En progreso | El problema está definido en términos del producto. |
| Completo | La ficha tiene el problema en lenguaje de cliente con evidencia básica. |
| Revisado | Las consecuencias están cuantificadas con datos reales. |
| Cumple estándar | La ficha refleja el consenso de múltiples conversaciones de discovery. |
| Fuerte/Sobresaliente | La ficha se actualiza con cada ronda de discovery y es la base de la propuesta de valor. |
Cards relacionadas / siguiente paso
- Trabajo del cliente
- Urgencia del problema
- Propuesta de valor del cliente
Trabajo del cliente
Habilidad: Definir el trabajo funcional para el que el cliente "contrata" la solución del startup.
¿Por qué importa esta habilidad?
Entender el "trabajo a hacer" (Jobs to Be Done) del cliente revela por qué compra y qué alternativas considera. Esto es más poderoso que solo conocer el problema: permite diseñar la oferta desde la lógica de contratación del cliente.
Qué se ve como un buen resultado
El equipo puede completar la frase "Cuando [contexto], el cliente quiere [trabajo funcional], para que [resultado esperado]" con evidencia real de conversaciones.
Errores comunes
- Confundir el trabajo con la feature del producto.
- Describir el trabajo en términos demasiado abstractos.
- No distinguir entre el trabajo funcional y el trabajo emocional o social.
- Usar el JTBD como ejercicio académico sin conectarlo a decisiones de producto.
Preguntas que el startup debe responder
- ¿En qué momento específico el cliente busca una solución?
- ¿Qué progreso intenta hacer el cliente con esta compra?
- ¿Qué alternativas considera el cliente para hacer ese mismo trabajo?
- ¿Cómo mide el cliente si la solución hizo bien el trabajo?
Artifact requerido
📄 Mapa del trabajo del cliente
Propósito: Documentar el Job to Be Done del cliente con contexto, trabajo y resultado esperado.
Card vinculada: Trabajo del cliente
Instrucciones de desarrollo
- Escribe el JTBD usando la fórmula: "Cuando [contexto], quiero [trabajo], para poder [resultado]".
- Identifica el trabajo funcional (qué hace), emocional (cómo se quiere sentir) y social (cómo quiere ser percibido).
- Documenta las alternativas que el cliente considera para hacer ese trabajo.
- Valida el JTBD con al menos tres citas de discovery que confirmen cada componente.
Estado esperado: Mapa con JTBD completo, tres dimensiones y alternativas del cliente documentadas.
Criterios de revisión del Artifact
- El JTBD sigue la estructura contexto + trabajo + resultado.
- Las tres dimensiones están identificadas.
- Las alternativas del cliente están documentadas.
- El JTBD está respaldado por evidencia de discovery.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- El mapa del trabajo del cliente está completo con las tres dimensiones.
- Las alternativas están documentadas.
- El JTBD se usa para diseñar la propuesta de valor.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay ningún ejercicio de JTBD. |
| En progreso | El JTBD existe pero está escrito en lenguaje de producto. |
| Completo | El mapa tiene la estructura básica contexto + trabajo + resultado. |
| Revisado | Las tres dimensiones y alternativas están documentadas. |
| Cumple estándar | El JTBD guía las decisiones de producto y go-to-market. |
| Fuerte/Sobresaliente | Se actualiza con el aprendizaje de discovery y refleja la evolución del cliente objetivo. |
Cards relacionadas / siguiente paso
- Dolor del cliente
- Urgencia del problema
- JTBD (Collection 9)
Urgencia del problema
Habilidad: Estimar la urgencia y relevancia del dolor del cliente para priorizar el go-to-market.
¿Por qué importa esta habilidad?
No todos los problemas son igualmente urgentes para el cliente. Un problema que el cliente resolvería "algún día" no genera ventas hoy. Evaluar la urgencia es crítico para decidir si el timing del mercado es correcto.
Qué se ve como un buen resultado
El equipo tiene una evaluación documentada de la urgencia del problema en su mercado Beachhead, con evidencia de discovery y un juicio sobre si el timing para entrar al mercado es ahora.
Errores comunes
- Confundir interés del cliente con urgencia.
- Usar respuestas hipotéticas de discovery como evidencia de urgencia real.
- No distinguir entre urgencia del problema y urgencia de compra.
- Ignorar la urgencia externa (regulación, presión competitiva) que puede acelerar la compra.
Preguntas que el startup debe responder
- ¿Qué pasaría si el cliente no resuelve este problema en los próximos seis meses?
- ¿Hay algún evento externo (regulación, temporada, crisis) que haga el problema más urgente ahora?
- ¿El cliente está buscando activamente una solución o solo estaría interesado si se la presentamos?
- ¿Qué tan alto está este problema en la lista de prioridades del cliente vs. otros problemas?
Artifact requerido
📄 Matriz de urgencia del problema
Propósito: Evaluar la urgencia y relevancia del problema en el mercado Beachhead con evidencia de discovery.
Card vinculada: Urgencia del problema
Instrucciones de desarrollo
- Define dos ejes: urgencia para el cliente (1-5) y frecuencia del problema (diaria, semanal, mensual, anual).
- Posiciona el problema del startup en esta matriz usando datos de discovery.
- Documenta los desencadenantes externos (regulación, estación, crisis) que amplifican la urgencia.
- Valida la posición con citas de al menos cinco clientes.
Estado esperado: Matriz con posición del problema, desencadenantes externos y evidencia de discovery.
Criterios de revisión del Artifact
- La urgencia tiene una valoración con evidencia de discovery.
- Los desencadenantes externos están identificados.
- La frecuencia del problema está estimada.
- La evidencia incluye citas directas de clientes.
Estado: ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente
Criterios de completitud
- La matriz tiene el problema posicionado con evidencia.
- Los desencadenantes externos están identificados.
- El equipo puede argumentar por qué el timing de entrada al mercado es correcto.
Rúbrica de revisión
| Nivel | Descripción |
|---|---|
| No iniciado | No hay evaluación de urgencia del problema. |
| En progreso | La urgencia es intuitiva y no está documentada. |
| Completo | La matriz tiene una evaluación con evidencia básica. |
| Revisado | Los desencadenantes externos están documentados. |
| Cumple estándar | La urgencia está respaldada por múltiples conversaciones de discovery. |
| Fuerte/Sobresaliente | La evaluación de urgencia se actualiza con cada ciclo y guía las decisiones de go-to-market. |
Cards relacionadas / siguiente paso
- Dolor del cliente
- Trabajo del cliente
- Propuesta de valor del cliente