Guía

Jobs to Be Done (JTBD) en español: guía práctica para validar ideas

Qué es Jobs to Be Done, cómo aplicarlo en una entrevista, cómo escribir una Job Story y por qué cambia tu forma de validar una idea de negocio. Guía con ejemplos reales.

Qué es Jobs to Be Done

Jobs to Be Done (JTBD) es un marco de discovery de producto popularizado por Clayton Christensen que cambia la pregunta clave de un fundador. En lugar de:

¿Quién es mi cliente y qué características tiene?

JTBD pregunta:

¿Qué "trabajo" está intentando hacer mi cliente en un momento concreto, y por qué contrata mi solución para hacerlo?

La idea es sencilla: las personas no compran productos por sus características; "contratan" un producto para que les ayude a hacer un progreso en su vida en una situación específica.

Por qué Jobs to Be Done importa al validar una idea de negocio

La trampa más común al investigar el problema de un cliente es quedarse en el qué (síntoma) y no llegar al cuándo (contexto). Como cuento en Así descubro cuándo ocurre realmente el problema del cliente:

Detrás de cada "me pasa esto" hay un cuándo que cambia todo.

Si solo sabes el síntoma, construyes una solución genérica. Si entiendes el contexto, construyes algo que encaja justo cuando el cliente lo necesita.

El formato Job Story

JTBD se expresa con una Job Story, no con una user story tradicional. El formato:

Cuando [situación específica], quiero [intención o necesidad], para poder [resultado o progreso esperado].

Ejemplo real de la edición 009:

"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."

Compáralo con una user story tradicional:

"Como persona ocupada, quiero una app de menús semanales, para ahorrar tiempo."

La user story habla de un usuario abstracto. La Job Story habla de un momento concreto con presión emocional y limitaciones reales. Es mil veces más útil para diseñar tu MVP.

Cómo aplicar Jobs to Be Done en una entrevista de validación

Mi método de 4 pasos para extraer Job Stories en una conversación:

Paso 1 — Olvídate de la solución y escucha el trabajo completo

Pide al cliente que cuente cómo intenta hacer su trabajo hoy, desde el inicio hasta el final. No preguntes por herramientas. Pregunta por lo que está intentando lograr.

Paso 2 — Mapea cada paso sin referencias a herramientas

Mientras escuchas, anota los pasos. Después elimina las acciones que dependen de una herramienta concreta. No escribas "abre Excel"; escribe "organiza la información".

Este pequeño cambio te muestra el trabajo como una secuencia humana, no como un uso de software. Ahí aparecen los puntos de fricción reales.

Paso 3 — Detecta 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, cuando improvisa. Ese es el momento donde aparece el "trabajo" que tu solución debe atacar.

A veces lo verbaliza ("ahí me desespero", "tengo que repetirlo"). A veces solo lo notas por el cambio de tono o las justificaciones. Busca la transición.

Paso 4 — Captura el contexto con una Job Story

Convierte el punto de fricción en una Job Story con la fórmula "Cuando…, quiero…, para poder…".

Caso real: del "qué" al "cuándo"

Una emprendedora quería lanzar una app de menús semanales. Su hipótesis era:

"La gente no sabe qué cocinar cada día y pierde tiempo decidiendo."

Tenía lógica. Las entrevistas parecían confirmarla. Hasta que alguien dijo 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."

La Job Story real era:

"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."

El producto pasó de planificador semanal (algo que se usa el domingo con calma) a asistente reactivo (algo que se usa a las 21:00 con hambre y poca energía). Solución completamente distinta.

Errores comunes al aplicar JTBD

  • Convertir el "trabajo" en una funcionalidad. "El trabajo es planificar menús" → mal. Demasiado abstracto.
  • Ignorar las emociones y la presión social. "Quiero comer bien sin pensar demasiado" es una mezcla de hambre, cansancio y culpa por no cuidarse. Capturar las tres es clave.
  • Buscar el trabajo del producto, no del cliente. El trabajo no es "usar mi app". Es lo que el cliente intenta lograr en su vida, con o sin ti.
  • Confundir JTBD con user research genérico. JTBD se centra en el momento de elección: cuándo decidió contratar la solución actual y por qué.

Cómo combinar JTBD con el resto del proceso de validación

JTBD encaja en la fase de investigación de tu proceso de validación, pero alimenta todas las demás:

  • En la fase de encontrar grandes problemas, JTBD te ayuda a clasificar la urgencia: un problema con "cuándo" claro suele estar en nivel 4-5.
  • En la fase de entrevistas, las preguntas tipo "cuéntame la última vez que pasó…" están diseñadas para extraer Job Stories.
  • En la fase de elegir a tus primeros clientes con Zoom x3, el Nivel 3 (comportamiento) está directamente conectado con la Job Story: la situación específica donde tu solución es la única lógica.

Lecturas recomendadas

Reto práctico

Coge la última entrevista que hayas hecho. Releeé las notas. Busca una transición en el flujo del cliente: un momento donde pasa de "todo va bien" a "esto no funciona".

Escríbelo con la fórmula:

"Cuando…, quiero…, para poder…"

Si te cuesta encontrar ese "cuándo", probablemente la entrevista no llegó lo suficientemente profunda. Repítela buscando el momento, no el síntoma.

¿Quieres seguir aprendiendo? Suscríbete a Fase UNO y recibe cada quincena una edición sobre validación, JTBD, entrevistas y MVPs.