Jobs to Be Done (JTBD) es un framework que reformula la pregunta fundamental del diseño de producto: en lugar de preguntar "quién es mi usuario", pregunta "por qué mi usuario está usando un producto". La diferencia es sutil, pero cambia radicalmente la forma de diseñar.
Este framework fue popularizado por Clayton Christensen, profesor de Harvard y autor de "The Innovator's Dilemma", a través de su famosa teoría de 2007: "La gente no compra un taladro. Compra un agujero en la pared. Y en realidad, ni siquiera un agujero: compra la satisfacción de tener un cuadro colgado". Esta idea, aparentemente simple, cambió la forma en que equipos de producto de empresas como Glovo, Cabify, Intercom o Spotify piensan en su trabajo.
En esta guía te explico qué es el framework JTBD en términos concretos, cómo formular un job statement que realmente te sirva, la diferencia entre JTBD y las user personas, y cómo aplicarlo con ejemplos reales de productos que lo usan.
Qué aprenderás en esta guía:
- Qué es un "job" en el sentido de JTBD (y no es un empleo)
- La estructura de un job statement y cómo escribir uno correctamente
- La diferencia entre JTBD y user personas (son complementarios, no alternativos)
- Los tres tipos de jobs: funcional, emocional y social
- Cómo realizar "job interviews" (diferentes de las entrevistas clásicas)
- 5 ejemplos reales de productos que han usado JTBD para decisiones estratégicas
¿Qué es un "Job" en el framework JTBD?
Un job en el framework JTBD no es una profesión. Es una tarea que el usuario intenta completar en una circunstancia específica. El nombre completo es "Job to be Done" porque enfatiza que hay algo por hacer, no alguien por ser.
La definición más rigurosa viene de Tony Ulwick, el otro padre del framework (Strategyn):
"Un job es un objetivo fundamental que la gente intenta alcanzar, independientemente de las soluciones disponibles en el mercado en un momento dado."
Tres características distinguen un job de una "necesidad" o una "feature":
- Es independiente de la solución. "Escuchar música mientras corro" es un job. "Comprar unos AirPods" no lo es: los AirPods son una posible solución al job.
- Es estable en el tiempo. Los jobs permanecen constantes durante décadas. Las soluciones cambian: de los casetes a los MP3 y al streaming. El job "escuchar música mientras me muevo" es idéntico desde 1979 (Walkman).
- Es contextual. El mismo usuario tiene jobs diferentes en circunstancias distintas. La misma persona que por la mañana "quiere llegar al trabajo sin estrés" por la noche "quiere relajarse con una serie de TV".
El clásico ejemplo del batido (milkshake)
Christensen cuenta un caso famoso: una cadena de comida rápida quería aumentar las ventas de batidos. Al estudiar las personas de sus clientes (edad, género, ingresos) no encontraron nada útil. Entonces, alguien preguntó: "¿Para qué job contratan los clientes el batido?".
Al estudiarlos en su contexto, descubrieron que el 40% de los batidos se vendían por la mañana, a las 7:30. El perfil típico era un trabajador que conducía de camino al trabajo. ¿Por qué compraba precisamente un batido?
El "job" era este: "Quiero algo que me mantenga ocupado durante los 30 minutos de trayecto, que me haga sentir menos solo en el atasco, que no me manche las manos, que no sea tan pesado como para darme sueño, y que me sacie lo suficiente para no tener hambre hasta las 11".
Una vez entendido el job, la solución cambió: batidos más espesos (duran más), con trozos de fruta (algo que explorar mientras conduces), y servidos en vasos que encajan en el portavasos del coche. Las ventas se duplicaron.
Ninguna persona demográfica habría llevado a esa solución. Solo fue posible al entender el job en su contexto específico.
Cómo formular un Job Statement
El job statement es la síntesis escrita de un job to be done. Existen varias fórmulas, pero la más extendida es la de Tony Ulwick (Strategyn):
Verbo + objeto del verbo + calificador de contexto
Ejemplos:
- "Minimizar el tiempo dedicado a organizar notas de reunión" (productividad para un knowledge worker)
- "Sentirme menos solo durante las pausas del trabajo" (app de mensajería)
- "Encontrar un restaurante cercano para comer con amigos sin pasar horas buscando" (app de delivery como Glovo o Rappi)
- "Mantener a mi equipo alineado sobre los objetivos trimestrales" (herramienta de gestión de proyectos B2B)
Las 3 reglas de oro de un job statement
- Usa un verbo de acción (minimizar, encontrar, sentir, entender, evitar). No adjetivos vagos como "ser productivo".
- Sin referencias a la solución. "Usar Slack para comunicar" es incorrecto. "Comunicarme con mis compañeros sin interrumpir su concentración" es correcto.
- Estable en el tiempo. Si el job suena como algo que cambiará en 10 años, es demasiado específico. Abstrae más.
El "Cuando... quiero... para poder..." — la forma extendida
Alan Klement propuso una variante narrativa útil cuando quieres un contexto más rico:
Cuando [situación / detonante], quiero [motivación], para poder [resultado esperado]
Ejemplo: "Cuando voy en el metro hacia la oficina por la mañana, quiero sentirme informado sobre las noticias del día, para poder participar en las conversaciones con mis compañeros sin parecer desinformado."
Esta forma narra mejor el porqué emocional del job y es más útil en talleres con equipos no técnicos.
Los 3 tipos de Job
Un job rara vez es solo funcional. Casi siempre es una mezcla de tres dimensiones:
1. Job funcional
La tarea práctica, observable y medible. "Transferir dinero a un amigo", "Imprimir un documento", "Recordar una cita".
Es la parte más fácil de entender y medir, pero rara vez es lo único que importa.
2. Job emocional
Cómo quiere sentirse el usuario mientras y después de realizar el job. "Sentirse seguro", "Sentirse organizado", "Sentirse experto delante de los compañeros".
Los jobs emocionales son la razón por la que productos "funcionalmente idénticos" ganan o pierden. Notion y Evernote hacen (a grandes rasgos) lo mismo, pero Notion te hace sentir "moderno y creativo", mientras que Evernote te hace sentir "un archivero diligente". Dos jobs emocionales diferentes.
3. Job social
Cómo quiere el usuario ser percibido por los demás al hacer el job. "Ser visto como un innovador", "Parecer atento a la familia", "No parecer tacaño".
Los jobs sociales son potentes en mercados con un componente de estatus: moda, coches, tecnología de consumo. Una persona no compra un iPhone solo por el job funcional de "llamar por teléfono"; también está el job social de "ser percibido como alguien que está a la última".
Un buen job statement captura los tres niveles cuando son relevantes, no solo el funcional.
JTBD vs. User Personas: complementarios, no rivales
Muchos artículos contraponen ambos frameworks. En realidad, son complementarios:
| User Persona | Jobs to Be Done | |
|---|---|---|
| Responde a | ¿Quién es el usuario? | ¿Qué está intentando hacer? |
| Foco | Identidad, contexto, demografía | Objetivo, motivación, circunstancia |
| Resultado | Perfil narrativo | Job statement |
| Riesgo de | Estereotipar | Ignorar el contexto humano |
| Fuerte en | Marketing, alinear al equipo | Decisiones de producto, descubrir oportunidades |
Los equipos más sofisticados usan ambos:
- User personas para entender quiénes son los segmentos de usuarios (marketing, copy, dirección visual).
- Jobs to Be Done para entender por qué usan el producto (priorización de features, messaging, estrategia de producto).
Para profundizar sobre las user personas, lee nuestra guía completa de user personas.
Cómo realizar una "Job Interview"
Las entrevistas de JTBD son diferentes de las entrevistas de UX clásicas. Se centran menos en opiniones y más en historias de uso real. La técnica más usada es la de Bob Moesta y Chris Spiek (The Rewired Group):
Paso 1 — Encuentra a personas que hayan realizado el job recientemente
No "personas interesadas en...". Personas que hayan hecho algo concreto en las últimas 2-4 semanas: comprar un producto, usar una app, tomar una decisión. El recuerdo fresco es crucial.
Paso 2 — Pide que te cuenten el "primer pensamiento"
"¿Cuándo se te ocurrió por primera vez la idea de [acción]? ¿Dónde estabas? ¿Qué estaba pasando?". Reconstruye el contexto físico y emocional, no dejes que el entrevistado te dé opiniones racionalizadas a posteriori.
Paso 3 — Sigue el proceso de decisión
"¿Y luego qué hiciste? ¿Hablaste con alguien? ¿Buscaste en internet? ¿Qué alternativas consideraste?". Reconstruye cada paso hasta la adopción de la solución.
Paso 4 — Indaga en las "fuerzas" que influyeron en la decisión
JTBD identifica 4 fuerzas que actúan en cada decisión:
- Push (Empuje): lo que aleja al usuario de la situación actual.
- Pull (Atracción): lo que le atrae hacia una nueva solución.
- Habit (Hábito): lo que le retiene en su costumbre actual.
- Anxiety (Ansiedad): lo que le preocupa de la nueva solución.
Una decisión ocurre cuando Push + Pull > Habit + Anxiety. Las entrevistas buscan identificar estas 4 fuerzas en cada caso.
Paso 5 — Sintetiza en un job statement
Después de 5-10 entrevistas, busca los patrones. Los jobs emergen de la repetición, no de los casos aislados.
5 ejemplos reales de empresas que usan JTBD
1. Intercom
Intercom es famosa por publicar uno de los primeros libros de código abierto sobre JTBD ("Intercom on Jobs-to-be-Done", 2016). Usó el framework para decidir qué features construir basándose en jobs recurrentes: "cuando un usuario compra, quiero saber quién es y qué hace en el producto, para poder darle soporte contextual".
2. Basecamp
Basecamp (37signals) usa JTBD como mentalidad para todas sus decisiones de producto. Su libro "Shape Up" describe un proceso en el que cada nueva feature parte de un pitch que incluye explícitamente el job to be done, no las user stories.
3. Spotify Discovery
Spotify reformuló su "Descubrimiento Semanal" en base a un JTBD preciso: "cuando estoy en el trabajo y quiero música de fondo sin distracciones, quiero música nueva que sé que me gustará sin tener que elegir". El resultado fue una playlist que no te pide que elijas nada y que ha generado miles de millones de horas de escucha.
4. Snickers ("No eres tú cuando tienes hambre")
No es UX, pero es un ejemplo perfecto. Durante años, Snickers intentó venderse como "una chocolatina muy rica". Luego identificaron el job emocional: "cuando tengo hambre y no puedo comer nada serio, quiero algo que me recupere sin hacerme sentir culpable por comer comida basura". La campaña "No eres tú cuando tienes hambre" (2010) nació de ese job statement. Las ventas globales aumentaron un 15% el primer año.
5. IKEA — Tienda de Täby
IKEA estudió los jobs de los clientes de su tienda en Täby (Suecia) y descubrió que el 30% de los visitantes tenían el job "pasar una tarde de domingo con la familia visitando un lugar interesante y luego comer juntos". No el job "comprar muebles". Rediseñaron el recorrido de la tienda con más zonas de descanso, un área de restaurante más grande y más entretenimiento para niños. Las ventas aumentaron a pesar de que el tiempo medio de permanencia se duplicó.
Errores comunes al usar JTBD
- Confundir job y solución. "Usar WhatsApp" no es un job. "Mantenerme en contacto con mis seres queridos de forma inmediata y personal" es un job.
- Jobs demasiado genéricos. "Ser feliz" no es un job útil. Demasiada abstracción lo hace inservible.
- Ignorar el contexto. El mismo usuario tiene jobs diferentes en contextos distintos. No lo trates como una entidad única.
- Saltarse las entrevistas. Un job statement escrito por el equipo sin investigación suele ser lo contrario al de los usuarios reales.
- Usarlo solo para mejoras incrementales. JTBD es potente precisamente para la innovación disruptiva: entender jobs que el mercado aún no ha cubierto.
Herramientas y plantillas para JTBD
- Job Statement Template (Strategyn) — disponible en el libro de Tony Ulwick "Jobs to Be Done: Theory to Practice".
- Forces of Progress canvas (The Rewired Group) — plantilla gratuita en FigJam para mapear push/pull/habit/anxiety.
- JTBD Playbook — libro de Jim Kalbach (gratuito y de código abierto), una de las referencias más completas para aplicar el framework.
- Plantillas de FigJam — busca "Jobs to Be Done" en la Comunidad de Figma, encontrarás decenas de plantillas gratuitas.
- Plantilla interna de CorsoUX — en nuestro curso completo ofrecemos nuestro propio framework con ejemplos adaptados al mercado español.
Preguntas frecuentes (FAQ)
¿Es necesario sustituir las user personas por JTBD?
No, ambos frameworks son complementarios. Las personas describen quiénes son los usuarios (útil para marketing, diseño visual, alineación del equipo). Los JTBD explican por qué usan el producto (útil para decisiones de producto, features, estrategia). Los equipos senior usan ambos.
¿Cómo convenzo a mi equipo para usar JTBD?
Empieza con un caso piloto: elige una feature que estéis debatiendo y realiza 5 job interviews con usuarios reales. Presenta los resultados en una reunión de 30 minutos. El equipo verá la diferencia entre "decisiones basadas en opiniones internas" y "decisiones basadas en jobs reales de los usuarios". A partir de ahí, la adopción será orgánica.
¿JTBD funciona también para productos B2B?
Sí, con algunos ajustes. En B2B, los "jobs" suelen estar ligados a roles corporativos ("como manager de RRHH, cuando tengo que hacer el onboarding de un nuevo empleado, quiero evitar errores de configuración") y a menudo involucran a múltiples stakeholders con jobs ligeramente diferentes. El framework sigue siendo perfectamente aplicable.
¿Cuál es el mejor libro para empezar?
"Competing Against Luck" de Clayton Christensen es el clásico del framework. Para un enfoque más operativo, "Jobs to be Done Playbook" de Jim Kalbach es más práctico y aplicable. Ambos están en nuestra selección de libros de UX.
¿Cómo conecto JTBD con el roadmap de producto?
Cada feature del roadmap debería responder explícitamente a la pregunta "¿qué job estamos solucionando con esta feature?". Si un equipo de producto no sabe responder, probablemente la feature no tiene fundamento y puede ser despriorizada. Muchos equipos lo usan como un filtro: ninguna feature entra en el roadmap sin un job statement asociado.
Próximos pasos
Jobs to Be Done es uno de los frameworks más citados pero menos aplicados correctamente. Los diseñadores que saben realizar job interviews, escribir job statements sólidos y usarlos para guiar decisiones de producto están entre los más demandados en empresas con cultura product-led en 2026.
El curso completo de Diseño UX de CorsoUX incluye un módulo sobre JTBD con ejercicios prácticos: análisis de casos reales, entrevistas simuladas y talleres de escritura de job statements. Saldrás con una capacidad para leer productos a través de la lente JTBD que pocos profesionales junior en España y LATAM tienen.
Para profundizar:
- Design Thinking: las 5 fases — donde JTBD se integra en la fase de Empatizar
- Guía de user research — las técnicas de entrevista aplicables también a JTBD
- User Persona: guía práctica — el complemento natural de JTBD
- Customer Journey Map — visualiza cómo el job se desarrolla en el tiempo
