Jobs to Be Done: qué contrata realmente el cliente
El framework que redefine la propuesta de valor: no vendés un producto, vendés el progreso que el cliente necesita hacer en su vida.
Qué es Jobs to be Done y por qué importa
El framework Jobs to be Done parte de una premisa transformadora: las personas no compran productos — contratan soluciones para hacer un progreso específico en sus vidas. Un gerente que contrata un CRM no quiere un software; quiere visibilidad sobre el pipeline para tomar decisiones sin depender de la intuición del equipo comercial.
El enfoque clásico de marketing empieza por el producto: features, especificaciones, beneficios derivados. JTBD invierte la dirección: empieza por la situación del cliente, identifica el progreso que necesita y evalúa qué soluciones compiten por resolver ese job — incluyendo alternativas que no son competidores directos. Un spreadsheet compite con un CRM, con una pizarra y con la memoria del vendedor. Todos resuelven el mismo job: saber en qué estado está cada oportunidad.
Esta inversión tiene implicancias directas sobre cómo diseñás la propuesta de valor. En lugar de articular qué hacés y por qué sos mejor que la competencia, articulás qué progreso habilitás y por qué sos la mejor forma de lograrlo.
02El origen: del milkshake al framework
El caso fundacional de JTBD es el del milkshake de McDonald's, documentado por Clayton Christensen en Competing Against Luck (cap. 1). McDonald's quería vender más milkshakes. Hicieron investigación de mercado clásica: preguntaron a los clientes si querían más chocolate, más espeso, más barato. Implementaron los cambios. Las ventas no se movieron.
Christensen tomó otro camino: observar qué hacían los clientes en lugar de preguntarles qué querían. El 40% de los milkshakes se vendían antes de las 8:30 de la mañana, a personas solas. El job no era "quiero algo dulce" sino "necesito algo que haga tolerable un viaje de 40 minutos y me mantenga lleno hasta las 11". Los competidores no eran los postres de Burger King sino las bananas, los bagels y el aburrimiento del viaje. La segmentación demográfica no explicaba la compra. La segmentación por job sí.
De ese insight nacieron dos décadas de desarrollo. Christensen formalizó el concepto en The Innovator's Solution (cap. 3). Anthony Ulwick lo sistematizó como Outcome-Driven Innovation en What Customers Want. Bob Moesta lo llevó al terreno de ventas con Demand-Side Sales 101. Alan Klement lo reinterpretó desde la psicología en When Coffee and Kale Compete. El núcleo se mantiene: el cliente no compra un producto, contrata progreso.
03Tipos de jobs: funcional, emocional y social
No todos los jobs operan en el mismo plano. Christensen los clasifica en tres dimensiones que actúan simultáneamente en cada decisión de compra. Entender esta distinción cambia lo que le prometés al consumidor y cómo lo comunicás.
Job funcional
Es la tarea práctica que la persona necesita completar. Transferir dinero, gestionar un proyecto, encontrar un proveedor de branding. Es la dimensión más obvia y donde la mayoría de las propuestas se concentran. El problema: rara vez es suficiente. Dos landing pages que resuelven el mismo job funcional compiten por precio si no hay diferenciación en las otras dimensiones.
Job emocional
Es cómo quiere sentirse la persona durante y después de completar el job. Segura, profesional, tranquila, en control, creativa. Un contador no contrata un software de gestión solo para registrar asientos (funcional) sino para sentir que tiene todo bajo control cuando el directorio pregunta (emocional). La identidad de marca opera directamente sobre esta dimensión: una marca que transmite confianza reduce la ansiedad del job emocional antes de que el cliente use el producto.
Job social
Es cómo quiere ser percibida la persona por otros. Competente ante su equipo, innovadora ante la industria. Este job explica por qué un CEO contrata una consultora de estrategia reconocida en lugar de un freelancer igual de capaz: la decisión se justifica socialmente. Es particularmente fuerte en decisiones B2B con múltiples stakeholders.
Christensen subraya en el cap. 2 de Competing Against Luck que las tres dimensiones están activas en toda decisión, aunque con intensidades diferentes. Un modelo de negocio SaaS para pymes puede tener un job funcional dominante ("necesito facturar sin errores") pero el job emocional ("no quiero que AFIP me clausure") es lo que dispara la urgencia. Diseñar solo para lo funcional produce productos competentes que no generan preferencia.
04Las cuatro fuerzas del progreso
Bob Moesta y Chris Spiek desarrollaron el modelo de las cuatro fuerzas para explicar por qué las personas cambian (o no) de solución. Este modelo es central para entender la conversión: no basta con tener una oferta superior — las fuerzas que frenan el cambio pueden ser más potentes que las que lo impulsan.
Lo que empuja al cliente lejos de su solución actual. Frustración, ineficiencia, problemas recurrentes. "Estoy harto de perder 3 horas por semana con este proceso manual."
Lo que atrae al cliente hacia una solución nueva. La promesa de mejora, la visión de cómo sería su vida con el cambio. "Imaginate si todo eso fuera automático."
La comodidad de la solución actual, aunque sea imperfecta. "Ya sé cómo funciona, tengo todo configurado, cambiar sería un lío." La inercia es el competidor más fuerte en cualquier mercado.
Incertidumbre sobre la nueva solución. "¿Y si no funciona? ¿Y si pierdo datos? ¿Y si el equipo no lo adopta?" Cada feature nueva es también una fuente potencial de ansiedad.
El cambio ocurre cuando push + pull > hábito + ansiedad. No alcanza con mostrar lo bueno que es tu producto (pull). Necesitás también activar la insatisfacción con lo actual (push) y reducir las fricciones de cambio (ansiedad). Una estrategia de conversión y CRO que ignora las fuerzas de frenado trabaja con la mitad de la ecuación. El onboarding existe para reducir ansiedad post-compra; los testimonios funcionan porque otro cliente ya cruzó el puente — reducen ansiedad y amplifican pull simultáneamente.
Trabajamos con una empresa tecnológica que creía que la contrataban por desarrollo o por capacidades técnicas, pero en realidad muchas empresas la buscaban por algo más profundo: necesitaban bajar la complejidad, avanzar con más seguridad y sentirse acompañadas por un socio que entendiera el negocio. Cuando esa verdad apareció en la comunicación, la conversión de propuestas subió de 25% a 37%.
Lisandro IserteKlement profundiza en When Coffee and Kale Compete (cap. 4): el verdadero competidor no es el producto rival sino la no-decisión. Las fuerzas de frenado ganan por default cuando las de impulso no son suficientemente concretas. Por eso propuestas vagas como "mejorá tu productividad" no convierten: no activan push específico ni reducen ansiedad concreta.
05JTBD vs. personas: qué resuelve cada uno
Una confusión recurrente es tratar JTBD como reemplazo de las buyer personas. No lo es. Son lentes complementarias que iluminan aspectos diferentes del mismo mercado.
La buyer persona describe quién compra: rol, demografía, contexto organizacional, motivaciones, frustraciones. Es útil para definir tono, copywriting, canales de distribución y estrategia de contenido. Responde la pregunta: ¿a quién le hablamos?
JTBD describe qué busca lograr esa persona: el progreso deseado, las circunstancias que lo disparan, las fuerzas que operan en la decisión. Es útil para diseñar la propuesta, el MVP, el pricing y la priorización de features vs. beneficios. Responde la pregunta: ¿qué les prometemos?
El cruce es donde la estrategia se vuelve potente. Un mismo job ("necesito reportar resultados al directorio sin quedarme hasta las 22") puede cruzar múltiples personas: el CFO de una mediana, el controller de una multinacional, el dueño de una pyme. Los tres tienen el mismo job funcional pero contextos y journeys de compra diferentes. La persona dice cómo llegar a ellos; el job dice qué prometerles.
Ulwick sistematizó esto en What Customers Want (cap. 5) con los "outcome statements": formulaciones precisas del resultado deseado, medibles e independientes de la solución. "Minimizar el tiempo para producir un reporte financiero mensual con menos del 2% de errores" es un outcome statement. "Quiero un dashboard bonito" no lo es. Las KPIs que medís en analítica deberían reflejar qué tan bien resolvés el job, no solo cuánto vendés.
06Cómo descubrir jobs: la entrevista de switching
El método más robusto para descubrir jobs es la entrevista de switching. Moesta la formalizó en Demand-Side Sales 101 (cap. 4-6): no le preguntás al cliente qué quiere sino qué hizo. Reconstruís la timeline completa del cambio desde el primer pensamiento hasta la decisión final.
Los cinco momentos de la timeline
Primer pensamiento: la persona reconoce una insatisfacción. "Estábamos perdiendo prospectos porque nadie hacía seguimiento." Suele preceder la compra por semanas o meses.
Evento disparador: algo concreto convierte la insatisfacción en búsqueda activa. Un lead importante que se perdió, un reporte con errores ante el directorio. Sin evento disparador, la inercia gana.
Búsqueda activa: la persona evalúa alternativas. Acá la estrategia de contenido, SEO y AEO captura demanda. El cliente busca soluciones al job, no features de tu producto.
Evaluación: compara opciones incluyendo no hacer nada. La diferenciación y evidencia tiene que superar la inercia. Los benchmarks y casos operan como reductores de ansiedad.
Decisión y compra: las fuerzas de impulso superan a las de frenado. La tasa de conversión mide cuántas personas llegan acá; las fuerzas de progreso explican por qué las demás no llegaron.
Lo poderoso de esta técnica frente a las encuestas es que captura comportamiento real, no intenciones declaradas. Las personas racionalizan post-hoc. La entrevista narrativa revela las fuerzas que realmente operaron — conectando con el diagnóstico cualitativo: los datos cualitativos bien recolectados son más reveladores que las métricas cuantitativas mal interpretadas.
07De job a propuesta de valor
Descubrir el job es la mitad del trabajo. La otra mitad es traducirlo en una propuesta con componentes claros. Osterwalder conecta ambos mundos en Value Proposition Design (cap. 1-2) con el Value Proposition Canvas: un lado mapea el perfil del cliente (jobs, pains, gains) y el otro la propuesta (productos, pain relievers, gain creators).
La traducción sigue una secuencia que no conviene saltear:
Primero, articulá el job principal en una frase que cualquier persona del equipo pueda repetir. "Nuestro cliente necesita [progreso] cuando está en [circunstancia] porque [motivación]." Si no podés completar esa frase con especificidad, no tenés claridad suficiente. El posicionamiento de marca debería reflejar este job — si la marca promete algo diferente de lo que el cliente contrata, ninguna campaña de awareness cierra la brecha.
Segundo, mapeá outcomes específicos. Ulwick propone convertir cada aspecto del job en un resultado medible: "Minimizar el tiempo necesario para saber en qué estado está cada deal." Cada outcome es un criterio contra el cual el cliente evalúa tu solución — y contra el cual tu equipo de diseño de producto prioriza features.
Tercero, identificá dónde falla la oferta actual. Los outcomes con mayor insatisfacción e importancia son las oportunidades de valor percibido más altas. Ulwick llama a esto "over-served" y "under-served": si el mercado está satisfecho con la velocidad pero frustrado con la precisión, invertí en precisión.
Cuarto, conectá el job con la marca. El job existe en un mercado con alternativas, dentro de un territorio de marca que define de qué tenés permiso de hablar. Una propuesta que resuelve un job real pero no es coherente con la identidad de marca genera confusión. Y la confusión es un impuesto invisible sobre la conversión.
JTBD no es solo un framework de mercado — es un framework de oferta. El go-to-market más efectivo es el que está alineado con un job específico para un segmento específico, no el que intenta cubrir todos los jobs posibles para todos los segmentos posibles.
08Errores frecuentes al aplicar JTBD
Confundir job con feature request
"Los clientes quieren un dashboard en tiempo real" no es un job — es una solución. El job sería "necesito saber al instante si una métrica clave se desvía para intervenir antes de que escale". Cuando definís el job como solución, cerrás el espacio de innovación.
Formular jobs demasiado amplios
"Quiero hacer crecer mi negocio" es un job tan amplio que no genera ningún insight accionable. Los jobs útiles tienen contexto y circunstancia. "Cuando recibo el reporte mensual de churn y veo que subió, necesito identificar rápidamente qué segmento se está yendo y por qué." Ese nivel de especificidad orienta el diseño de producto, la comunicación y hasta la estructura del funnel.
Ignorar las fuerzas de frenado
Equipos que entienden JTBD pero solo trabajan el push y el pull — mostrando lo malo de la situación actual y lo bueno de la nueva — sin atacar el hábito y la ansiedad. El resultado: prospectos que dicen "genial, me encanta" y después no compran. La retención empieza antes de la compra: si la experiencia de switching es traumática, el cliente ni empieza.
Usar JTBD como ejercicio teórico
Equipos que hacen un workshop, producen un documento bonito con jobs y fuerzas, y lo archivan. JTBD funciona cuando los jobs se convierten en criterios de decisión: qué features priorizar en el roadmap, qué mensajes testear, qué objetivos definir para el próximo OKR. Si no cambia decisiones, fue turismo intelectual.
Asumir un solo job por producto
Un producto puede resolver múltiples jobs para múltiples personas. Slack resuelve "coordinarme sin reuniones innecesarias" y "sentirme conectado aunque trabaje remoto". Ignorar la multiplicidad lleva a comunicar un solo job y perder a quienes te contratan por los otros — directamente conectado con la arquitectura de marca.
Cuándo usar JTBD y cuándo no
JTBD es particularmente poderoso cuando estás diseñando o rediseñando una propuesta de valor, cuando las tasas de conversión son bajas a pesar de tener tráfico calificado, cuando necesitás entender por qué la gente no compra, y cuando estás lanzando un producto nuevo y necesitás validar que resuelve un job real — lo que Christensen conecta con la lógica de lean startup en The Innovator's Solution.
Es menos útil cuando el job ya está bien entendido y el cuello de botella es de ejecución. Si sabés qué job resolvés, el problema puede estar en la adquisición orgánica, en el tracking o en la experimentación de mensajes.
La pregunta más productiva no es "¿debería usar JTBD?" sino "¿entiendo qué progreso contrata mi cliente?". Si la respuesta te sale en términos de tu producto ("contratan nuestro software de automatización") y no en términos de su vida ("necesitan liberar 10 horas semanales de tareas repetitivas para dedicarlas a estrategia"), el framework tiene algo para enseñarte. Y la North Star Metric de tu negocio debería reflejar qué tan bien estás resolviendo ese progreso.
Preguntas frecuentes sobre Jobs to be Done
¿Cuál es la diferencia entre un job funcional y un job emocional?
El job funcional es la tarea práctica: transferir dinero, organizar un viaje, gestionar un proyecto. El emocional es cómo quiere sentirse la persona al hacerlo: segura, profesional, en control. Christensen los separa analíticamente pero advierte que en la decisión real operan juntos. Diseñar solo para el funcional produce productos competentes que no generan preferencia.
¿Jobs to be Done reemplaza a las buyer personas?
No las reemplaza — las complementa. La persona describe quién compra; el job describe qué busca lograr. El cruce es lo que hace potente a la segmentación: la persona te dice cómo llegar al cliente, el job te dice qué prometerle. Un mismo job puede cruzar múltiples personas y una misma persona puede tener múltiples jobs activos.
¿Cómo descubro los jobs de mis clientes?
El método más robusto es la entrevista de switching: hablar con personas que recientemente cambiaron de solución. Moesta la formalizó como técnica narrativa que reconstruye la timeline completa desde el primer pensamiento hasta la compra. No preguntás qué quieren sino qué hicieron y por qué. Las encuestas no funcionan bien acá porque el cliente racionaliza post-hoc.