Jobs to Be Done aplicado a una entrevista de validación no busca qué problema tiene tu cliente, sino cuándo aparece. En esta edición comparto un método de 4 pasos para mapear el trabajo del cliente, detectar el momento de fricción y capturarlo con una Job Story del tipo "Cuando…, quiero…, para poder…".
La Job Story aplicada a validación, en la forma que enseña Pablo Granados Ruiz en Fase UNO, es un formato breve —«Cuando [situación], quiero [intención], para poder [resultado]»— derivado del marco Jobs to Be Done. Sirve para capturar el momento exacto en el que aparece un problema del cliente, no solo el síntoma, y diseñar una solución que encaja justo cuando se necesita.
Lo más difícil de una entrevista no es escuchar, sino saber qué parte de la conversación importa de verdad.
Detrás de cada "me pasa esto" hay un CUÁNDO que cambia todo.
El problema que nadie ve: no saber cuándo ocurre el problema
Uno de los errores más comunes al entrevistar es creer que entendemos el problema solo porque lo escuchamos de su boca.
Nos dicen: "Pierdo mucho tiempo con esto", "Me cuesta organizar aquello", "Me frustra hacer esto cada día". Lo anotamos como hallazgo y seguimos a la siguiente pregunta.
Pero lo que el cliente dice es solo la punta del iceberg. Detrás de cada "me pasa esto" hay un momento específico en el que todo empieza a fallar.
El método Jobs to Be Done (JTBD) ayuda exactamente a entender ese "cuándo", es decir, identificar dónde realmente aparece la necesidad.
Cuando sabes cuándo ocurre el problema, entiendes qué lo provoca, qué lo rodea y por qué duele de verdad. Sin ese contexto, lo que crees que es un problema puede ser solo un síntoma aislado.
Si preguntas "¿cuándo te pasa?" y la respuesta es vaga ("depende del día", "a veces"), no estás entendiendo el problema real del cliente, solo sus palabras.
Antes de construir nada, hay que aprender a reconocer el momento exacto en que surge el problema.
Mi método paso a paso para detectar el "cuándo"
No es teoría: lo uso cada vez que entrevisto a alguien o intento entender un nuevo mercado.
Paso 1. Olvídate de la solución y escucha el problema completo
Antes de entrar en detalles, dejo que el cliente cuente cómo intenta hacer su trabajo hoy, desde el principio hasta el final.
No pregunto por herramientas ni por productos, sino por lo que está intentando lograr. Si saltas a hablar de tu idea, pierdes el mapa completo.
El objetivo: trazar el recorrido que va desde "no está hecho" hasta "ya lo consiguió".
Paso 2. Mapea cada paso como si observaras el proceso
Voy anotando los pasos que menciona, aunque salgan caóticos. Después los ordeno y elimino las acciones que dependen de una herramienta concreta.
No escribo "abre Excel" ni "clic en enviar". Anoto cosas como "organiza la información", "verifica resultados", "comparte con su equipo".
Este pequeño cambio lo transforma todo: empiezas a ver el trabajo como una secuencia humana, no como un uso de software. Ahí aparecen los puntos de fricción reales.
Paso 3. Busca los momentos de fricción
En cada flujo hay un punto donde el cliente deja de avanzar con naturalidad. Puede ser cuando se da cuenta de que falta algo, cuando pierde tiempo o cuando improvisa una solución. Ese es el momento donde aparece el problema.
A veces lo menciona sin darse cuenta ("ahí es cuando me desespero", "tengo que repetirlo varias veces"). Otras veces no lo verbaliza, pero lo notas por el cambio de tono o por las interrupciones para justificar algo.
Busco la transición, el cambio de ritmo que marca el comienzo del dolor.
Paso 4. Captura el contexto con una Job Story
Una vez detecto el punto de fricción, lo transformo en una mini historia:
Cuando [situación específica], quiero [intención o necesidad], para poder [resultado o progreso].
Por ejemplo:
"Cuando tengo que enviar un informe rápido después de una reunión, quiero tener todos los datos en un solo lugar, para poder responder sin perder tiempo buscando información."
Esta estructura me obliga a precisar el contexto, no el síntoma. Ya no hablo de "problemas con informes", sino del momento exacto en que ese problema aparece.
Caso real: cuando el problema no era el problema
Hace poco ayudé a una emprendedora que quería lanzar una app para organizar menús semanales. Su hipótesis era clara:
"La gente no sabe qué cocinar cada día y pierde tiempo decidiendo."
Tenía lógica. Pero al entrevistar usuarios, algo no encajaba. Todos decían "sí, me cuesta planificar las comidas". Parecía validado.
Hasta que alguien dijo casi al pasar:
"El problema no es decidir el menú… es que cuando llego del trabajo estoy agotada y no me da la cabeza para pensar qué cocinar."
Ahí estaba. El problema no era la planificación, sino el momento del día en que tenían que decidir qué cenar, sin energía ni tiempo.
La Job Story quedó así:
"Cuando llego tarde y estoy cansada, quiero tener una idea rápida de qué puedo cocinar con lo que tengo, para poder comer bien sin pensar demasiado."
Ese cuándo lo cambió todo. El producto dejó de ser una agenda de comidas para convertirse en un asistente que resolvía el problema justo en el instante en que aparecía.
Si hubiéramos seguido validando "me cuesta planificar", habríamos construido algo que nadie necesitaba cuando realmente lo necesitaba.
Reto final
Elige una de tus últimas entrevistas y búscale el "cuándo". El momento exacto en el que el cliente pasa de tranquilo a frustrado.
Escríbelo con la fórmula:
"Cuando…, quiero…, para poder…"
Verás cómo todo el problema cambia de forma. No estás buscando una frase bonita: estás construyendo evidencia para validar.
Si quieres ayuda para mapear el trabajo de tu cliente paso a paso y encontrar el momento clave donde nace la oportunidad, responde al email.
Sigue aprendiendo
- Cómo hacer entrevistas que te digan lo que tus clientes no te dicen — la base para que el "cuándo" emerja en conversación.
- Cómo encontrar grandes problemas (y que la gente pague por resolverlos) — el método para clasificar el problema una vez detectado el contexto.
- El método Zoom x3: cómo elegir a tus primeros clientes — del "cuándo" al perfil de cliente accionable.